DongHyeonkaandClaude Opus 5
919547a025
B-7 stopped at "could not delete the server-side session". The reason it gave was right: the ticket carries the session id, the ticket is encrypted with the cookie secret, so after a rotation the proxy cannot work out which Redis key to remove. But that is a limitation of the proxy, not of Redis. Measured across two rotations: - The orphan does expire. TTL falls one second per second and is not refreshed by requests (the startup log says refresh:disabled, and --cookie-refresh is unset), so it dies exactly one hour after creation. - An operator can delete it. `redis-cli del` returned 1, dbsize went 2 to 1, and the live session answered /oauth2/userinfo with 200 immediately after. - But nothing in Redis says which key is the orphan. Same name prefix, same type, the same 3510 bytes, and the values are encrypted. - TTL is the only signal, and because it is never refreshed it is an exact function of creation time. Anything created before the rotation is an orphan. Derived creation time 11:30:26 against the AuthSuccess log line at 11:30:27 — one second out. The rule was then run and removed the orphan while leaving the live session. - They accumulate: the session that survived the first rotation became the orphan of the second. The caveat is recorded too: turning on --cookie-refresh breaks the derivation, and at that point flushing and forcing everyone to re-authenticate is the more honest option. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6 lines
276 B
YAML
6 lines
276 B
YAML
- generic [ref=f1e3]:
|
||
- generic [ref=f1e6]:
|
||
- heading "This page isn’t working" [level=1] [ref=f1e7]
|
||
- paragraph [ref=f1e8]: If the problem continues, contact the site owner.
|
||
- generic [ref=f1e9]: HTTP ERROR 401
|
||
- button "Reload" [ref=f1e12] [cursor=pointer] |