[React, Docker, VITE] Keycloak이 프론트 코드에 어떻게 적용되는 걸까?

 

 

Keycloak을 사용하는데
필요한 기초 파일을 대부분 작성했다.
그러면 만든 파일을 어떻게 사용하는걸까?

 

 

 

 

 

[  이전 포스팅 - keycloak의 설정파일 작성하기  ]

 

[Keycloak, Docker, React] React에서 keycloak을 더 상세하게 다뤄보자.

 

 

 

 

1. PemissionSetting.jsx_ 관리자를 관리하는 페이지

• 이 페이지는 일반 admin을 관리하는 페이지로, super admin만 들어갈 수 있도록 하고 있다.
• 이 페이지에 들어가기 위해서 Keycloak으로 로그인을 해야한다.
• 사용자의 역할이 super admin인지 확인되어야 관리자 정보가 출력되도록 한다.
•  keycloak과 관련된 파일들 import하기

// Keycloak과 관련된 파일을 import 했다.
// authFetch는 Token을 헤더에 붙이는 역할을 했다.
import { authFetch } from "../../auth/authFetch.js";
// useAuth는 keycloak의 상태(로그인했는지, 누구인지)를 리액트 컴포넌트가 알 수 있게 한다.
import { useAuth } from "../../auth/AuthProvider.jsx";

 

• 사용자 정보를 가져오기 위해 auth 선언

export default function PermissionSetting() {
    // useAuth 사용하겠다!
    // useAuth는 AuthContext라는 데이터 저장소에 접근가능함
    const auth = useAuth();

 

 

 

Q. useAuth가 어떻게 AuthContext에 접근가능한가?

A. useAuth는 AuthProvider가 가져온 keycloak 정보들을 AuthContext에 집어넣었다. 그래서 useAuth는 그대로 꺼내 쓴다. AuthProvider의 코드를 살펴보면 더 쉽게 이해가능하다.

// AuthProvider 코드 일부
// AuthProvider가 keycloak 정보를 넣었다.(AuthContext)
return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;​

 

    // useAuth 코드 일부
    // useAuth가 들고온 정보를 가져간다.(AuthContext를 context로 가져옴)
    const context = useContext(AuthContext);
    return context;

 

 

• 관리자 페이지를 보여주기 위한 조건문

    useEffect(() => {
        // auth.loading은 키클록이 서버와 통신하면서 사용자가 누구인지 확인 중인 상태이다.
        // auth.loading은 로딩 중이 아닌지 묻는다. true -> 조회중 false -> 조회끝
        // auth.superAdmin은 키클록 토큰 안에 들어있는 Role 정보를 확인해서 이 사람이 최고관리자인지 판단한다.
        // keycloak이 확인을 한 뒤 그 결과가 최고 관리자일 때만 데이터를 불러오는 로직이다.
        if (!auth.loading && auth.superAdmin) {
            // 모두 true가 나오면 loadAmdins가 실행되어 관리자 데이터를 가져온다.
            loadAdmins();
        }
    }, [auth.loading, auth.superAdmin]); // 이 두 값이 변할때마다 로직 다시 체크하기

 

Q. !auth.loading을 쓴 이유가 뭘까? 그냥 auth.superAmdin만 검사하면 되는거 아닐까?

A. !auth.loading은 확실한 결과가 나올 때까지 화면을 보여주지 않고 기다리게 한다. 그니까 사용자가 로그인이 제대로 됐는지 완전히 확인이 끝나면 그 후에 로그인한 사용자가 superAdmin이 맞는지 확인하는 로직을 가진다. !auth.loading을 안적으면 사용자가 로그인이 되어있는 상태인데도 keycloak과 서버의 전달이 완벽하게 이뤄지지 않아서 isAuthenticated가 잠시 false일 수 있다. 그렇게되면 사용자는 로그인을 했음에도, 로그인 화면이 잠시 나타나는 현상이 발생할 수 있다.

 

 

• 각 기능들
  모두 authFetch를 사용한다.

 // 검색
 const handleSearch = async (keyword) => {
        try {
            // 서버 /api/amdins로 데이터를 달라고 할 때, 키클록이 발급해준 Bearer 토큰이 함께 날아간다.
            const response = await authFetch(`/api/admins/search?keyword=${encodeURIComponent(keyword)}`);

 // 삭제
 const handleDelete = async (id) => {
        if (!window.confirm("정말 삭제하시겠습니까?")) {
            return;
        }

        try {
            // ♦서버 /api/amdins로 데이터를 달라고 할 때, 키클록이 발급해준 Bearer 토큰이 함께 날아간다.
            const response = await authFetch(`/api/admins/${id}`, { method: "DELETE" });

 

 

 

---

 

 

 

2. CustomerTable.jsx_ 고객을 관리하는 페이지

• 이 페이지는 VIP 등급 이상의 고객을 관리하는 페이지다.
• 고객 관리 페이지는 조회 | 추가 | 수정 | 검색 | 삭제 기능이 있다.
• 관리자는 갖고 있는 권한의 기능만 사용할 수 있다.
  ex) A관리자는 조회 | 추가 | 수정 권한만 있으면, 검색 | 삭제는 불가능하다.
• PermissionSetting.jsx랑 똑같이 import하고 사용자 정보를 가져온다.

// AuthProvider를 통해 키클록 서버에서 받아온 사용자의 정보와 권한 리스트를 auth 변수에 둔다.
const auth = useAuth();

 

• auth 권한 체크

    // ex) 최고관리자 || 읽기관리권한 중 하나만 갖고 있으면 패스!
    // 둘 중 하나만 true여도 canRead엔 true가 들어간다.
    const canRead = auth.superAdmin || auth.customerRead;
    const canSearch = auth.superAdmin || auth.customerSearch;
    const canAdd = auth.superAdmin || auth.customerAdd;
    const canEdit = auth.superAdmin || auth.customerEdit;
    const canDelete = auth.superAdmin || auth.customerDelete;

 

• 각 기능들
  모두 authFetch를 사용한다.

  const loadCustomers = async () => {
        if (!canRead) return;
        try {
            // 데이터를 불러올 때(읽기 권한), authFetch로 토큰을 넣어서 보낸다. => 다른 동작도 마찬가지
            const res = await authFetch("/api/customers");
            if (res.ok) {
                const data = await res.json();
                dispatch({ type: "INIT", payload: data });
                setPage(1);
            }
        }