DongHyeonkaandClaude Opus 5
6c310c93b7
Neither client had a backchannel logout URL and the BFF has no oidcLogout configuration, so the three candidate paths all answer 302, which is the authentication redirect rather than a handler. Setting the URL on the identity provider alone changed nothing: with a live session, logging the user out emptied the Keycloak side and left the Redis session untouched. Reachability is not the blocker here, since a Keycloak pod fetches the app's public URL with a 200, but that is a property of this tailnet split-DNS lab and is the assumption most likely to fail in production, where it fails silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
370 B
Plaintext
16 lines
370 B
Plaintext
=== IdP 세션은 실제로 끊겼는가 ===
|
|
keycloak-patterns 세션: 0
|
|
|
|
=== ★ Keycloak 파드가 app1.hyeonworks.com 에 닿는가 ===
|
|
DNS 해석:
|
|
Address: 100.83.212.4
|
|
|
|
Non-authoritative answer:
|
|
|
|
HTTPS 도달:
|
|
HTTP 200 (0 이면 못 닿음)
|
|
|
|
=== Keycloak 로그 전체에서 backchannel 흔적 ===
|
|
keycloak-0: 0 줄
|
|
keycloak-1: 0 줄
|