나만 들어갈 수 있는 관리자 화면 준비하기

방문자 화면과 관리자 화면의 역할을 나눕니다

홈과 공개 글은 누구나 읽을 수 있어야 합니다. 반면 /admin 은 운영 설정을 바꾸고 글을 저장하는 화면이므로 내 계정만 접근할 수 있어야 합니다. /admin/api/state 는 관리 화면에 필요한 데이터를 가져오는 주소이고, 다른 /admin/api/ 경로는 저장과 상태 변경을 처리합니다. 화면 한 곳만 잠그고 데이터 요청을 열어 두면 보호가 끝난 것이 아닙니다. 예제는 관리 경로 전체에 같은 계정 확인을 적용합니다.

공개 화면에는 관리자 비밀번호 입력칸을 임의로 만들지 않습니다. 브라우저 코드에 정답을 써 두고 맞는지 비교하면 파일을 읽는 사람도 정답을 볼 수 있습니다. 관리자 주소를 길고 복잡하게 바꾸는 것도 로그인 확인을 대신하지 않습니다. 실제 권한은 서버가 판단해야 하며, 이번 예제는 이미 제공되는 Access 로그인과 서버 토큰 검사를 사용합니다. 직접 비밀번호 저장 기능을 처음부터 만드는 범위를 줄인 것입니다.

내 PC에서 /admin 이 바로 열렸던 이유는 .dev.vars 의 로컬 설정 때문입니다. 예제는 LOCAL_DEV가 true이면서 실제 접속 주소와 설정 주소가 localhost 또는 127.0.0.1인 경우만 이 연습 경로를 허용합니다. 원격 wrangler.jsonc는 LOCAL_DEV=false를 유지합니다. 값 하나를 바꾸면 어디서든 로그인 없이 열리는 구조로 만들지 않았지만, 원격 설정에서도 로컬 값을 그대로 복사하지 않는 습관이 필요합니다.

인증 설정에 넣을 값의 출처를 구분합니다

Cloudflare One에서 Access → Applications → Add an application → Self-hosted로 들어가 관리 경로를 보호합니다. 계정 화면에서 발급된 AUD를 그대로 복사하고 팀 도메인은 https:// 없이 넣습니다. 기본 주소를 바꾸어 접근해도 서버가 토큰을 검증하므로 값이 없으면 403으로 막힙니다. 사진 /media/ 경로는 글 공개 여부를 코드가 구분하므로 사이트 전체를 Access로 잠그지 않습니다.

지금 준비할 항목과 도메인 연결 후 할 일을 구분합니다

Access 보호를 완성하려면 실제로 사용할 도메인과 관리자 경로가 필요합니다. 아직 첫 배포 전인 이 회차에서는 허용할 이메일, 설정 위치, 확인 순서를 먼저 익힙니다. 9회차의 첫 배포에서는 관리자 접근이 403으로 잠긴 상태를 확인하고, 10회차에서 내 도메인을 연결한 뒤 같은 절차로 로그인 보호를 완성합니다. 순서상 아직 없는 주소를 억지로 입력해 설정을 끝내려 하지 않아도 됩니다.

관리자 이메일은 실제로 인증 메일을 받을 수 있고 내가 계속 관리할 계정으로 정합니다. 공유 계정을 쓰면 누가 설정을 바꿨는지 구분하기 어렵고 담당자가 바뀔 때 접근을 회수하기도 번거롭습니다. 계정 자체의 복구 수단과 추가 인증도 점검합니다. 이메일 주소를 안다고 관리자가 되는 것은 아니지만, 해당 이메일 계정의 보안이 관리자 접근과 연결된다는 점은 기억해야 합니다.

공식 설정 화면의 항목 이름은 언어나 서비스 개편에 따라 다르게 보일 수 있습니다. Cloudflare One에서 Access의 Applications 영역을 찾아 Self-hosted application을 추가하는 흐름을 기준으로 확인합니다. 화면 위치가 다르면 외부 블로그의 오래된 캡처를 그대로 따라 누르기보다 공식 안내의 애플리케이션 유형과 정책 항목을 비교하세요. 실제 내 계정에서 제공되는 인증 방법과 이용 조건도 함께 확인합니다.