mirror of
https://github.com/discourse/discourse.git
synced 2026-08-06 06:24:48 +08:00
6b348f8f6aThis PR binds the shared session key to the session's `UserAuthToken` so it can no longer be replayed after the session is revoked. When the `long_polling_base_url` site setting points to an external origin, the auth cookie is not sent with message_bus requests, so each authenticated page render mints a shared session key: a random token that Discourse stores in Redis pointing at the user's id, embeds in the page, and the client replays on the `X-Shared-Session-Key` header. That Redis entry is given a 7-day TTL. On each request the key was resolved to its user id and returned before the suspended/active check ran, so a captured key kept authenticating for the full 7 days of its TTL. Logout, suspension, password change, and token revocation never touched the Redis entry, so none of them stopped it. Key changes: * Store the key as `shared_session_user_auth_token_id:<key> -> token.id`, building the Redis key name in one place (`Auth::DefaultCurrentUserProvider.shared_session_redis_key`). Legacy `shared_session_key_*` entries are never read, so every pre-deploy key fails closed with no migration; clients re-mint on their next page load. * Resolve the user through the bound token, applying the same suspended/active and `maximum_session_age` checks as cookie auth, so the key revokes and expires with the session instead of outliving it on the Redis TTL. * Mint against the token's effective user so admin impersonation keeps live updates; the key stays the admin's and reverts to them when impersonation ends. * Rely on token destruction for revocation on every path rather than deleting the Redis entry, since a gone token already makes its key fail closed on lookup; orphaned entries expire on the 7-day TTL. |
||
|---|---|---|
| .. | ||
| application_helper_spec.rb | ||
| email_helper_spec.rb | ||
| embed_helper_spec.rb | ||
| redis_snapshot_helper.rb | ||
| topics_helper_spec.rb | ||
| user_notifications_helper_spec.rb | ||
