DongHyeonkaandClaude Opus 5
e62bbb4df0
The authorized client repository is AuthenticatedPrincipalOAuth2AuthorizedClientRepository, keyed by principal with no session id in it, which is the mechanism behind the sharing problem Q1 and Q3 describe. Sharing a store does not fix a lookup key. Five problems on the way in: only build output was committed under bff/, a duplicate YAML key broke the image build and was invisible until the full log was captured, env placeholders without defaults broke the tests, actuator was behind the login redirect so a 200 was the login page, and the 117KB beans response failed through the proxy. Deploying two replicas made the login itself fail before any experiment started, because the authorization request lives in per-instance memory and the callback lands elsewhere. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.3 KiB
1.3 KiB
B-0 — BFF·Redis 배포와 자동구성 확인 증거
2026-09-04 14:20–14:50 KST
해설: docs/experiment-b0-bff-redis-deploy.md
| 파일 | 무엇을 보여주는가 |
|---|---|
01-deploy.txt |
배포 전 자원, Redis·BFF 롤아웃, 두 노드에 하나씩 배치됨 |
02-autoconfiguration.txt |
첫 조회 시도(파싱 실패)와 외부 진입점 HTTP 200 |
03-beans-analysis.txt |
B-0 의 답 — InMemoryOAuth2AuthorizedClientService, AuthenticatedPrincipalOAuth2AuthorizedClientRepository, Redis·Spring Session 없음 |
b0-bff-login-success-single-replica.png |
replica 1 에서 로그인 성공한 BFF 화면 |
b0-bff-token-boundary.png |
/bff/token-boundary — principal: labuser, accessTokenStoredOnServer: true, browserTokenCount: 0 |
핵심 세 줄
AuthenticatedPrincipalOAuth2AuthorizedClientRepository— 조회 키가 principal 이고 session ID 가 없다. Q1·Q3 문제의 기제가 이 빈 하나에 있다.- Redis 를 붙여도 그건 안 고쳐진다. 저장소 공유와 조회 키는 다른 문제다.
- replica 2개에서는 로그인 자체가 실패한다. 인가 코드 흐름의 왕복 두 번이 같은 인스턴스로 가야 하는데, 인가 요청이 인스턴스 메모리에 있다.