DAY 07작업 7일째

배포한 어드민의 로그인까지 연결했다

공통 인증 뒤의 Worker 연결을 나누고 하위 경로 OAuth 오류를 고쳐 실제 초안함까지 들어갔다.

서버가 켜져 있어도 들어갈 수는 없었다

어드민도 서버에 배포했다. 방문자가 읽는 블로그는 정적 사이트로 두고, 글을 관리하는 어드민은 Cloudflare Access 뒤에 뒀다. 주소는 앞으로 만들 다른 어드민과 나눠 쓰도록 backstage.<도메인>/blog/처럼 경로로 나눴다.

그런데 인증을 마쳐도 “접근 권한이 없어요.”라는 문구만 나왔다. 어드민 프로세스와 터널은 정상이고 상태 확인 요청에도 응답하는데, 초안함에는 들어갈 수 없었다.

권한보다 먼저 목적지를 확인했다

처음에는 Access의 이메일 허용 정책을 의심했다. 확인해 보니 이메일은 정확했고, 인증 로그에도 허용으로 남아 있었다. 거부 문구를 코드에서 찾아보니 같은 도메인을 쓰던 다른 어드민의 응답이었다.

공통 Access 인증
  ├─ /blog/ 아래 → 터널 → 블로그 어드민
  └─ 나머지 경로 → 기존 어드민 Worker

다음 배포에서 도메인 전체를 다시 연결하지 않도록 배포 설정과 사전 검사도 맞췄다. 이 변경 뒤에야 GitHub 로그인 버튼이 나타났다.

돌아오는 주소에서 경로 하나가 빠졌다

GitHub에서 인증하고 돌아오자 이번에는 로그인 확인에 실패했다.

로그인 요청에는 /blog/auth/callback을 보냈지만, 인증 코드를 토큰으로 바꿀 때는 /auth/callback을 보내고 있었다. 도메인만 담은 값과 하위 경로까지 담은 값을 섞어 쓴 것이다. GitHub는 두 주소가 다르면 거절한다.

- redirect_uri: `${config.publicUrl}/auth/callback`,
+ redirect_uri: `${config.appUrl}/auth/callback`,

테스트에서 쓰는 가짜 GitHub는 돌아올 주소를 검사하지 않아서 이 문제가 드러나지 않았다. 가짜 GitHub도 코드를 발급할 때 받은 주소와 바꿀 때 받은 주소가 다르면 거절하도록 고쳤다.

초안함에 들어가서 확인했다

로그인을 마친 블로그 어드민의 초안함
수정 후 실제로 로그인해 기존 초안 6개가 보이는 것까지 확인했다. 프로젝트 이름을 바꾸기 전 화면이다

서버에 수정본을 반영하고 새 로그인 요청으로 초안함까지 들어갔다. 인증하지 않은 요청은 계속 Access 로그인으로 보내지는 것도 확인했다.

기록 #08 · 2026.10.04