Page MenuHomePhabricator

Handle multiple session "traits" in AuthManager
Closed, ResolvedPublic


AuthManager includes a stack of session providers, one of which will be selected to provide the session object which will handle all interaction with the session in the current request. There might be multiple extensions which want to influence how the section object behaves, though (for example, CentralAuth wanting to change where the cookie is set and SecureSessions wanting to refuse authentication when the requests suddenly come from a different country), so inheritance in itself will not be sufficient.

Event Timeline

Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a subscriber: Tgr.
Anomie claimed this task.
Anomie added a subscriber: Anomie.

SessionManager takes care of this by adding hooks for SecureSessions to do its thing.

The potential concern that SecureSessions has no way to write its cookies isn't really a concern for SessionManager/AuthManager:

  • If the cookies are really relevant to the session, you can't count on cookies even being used for the session in a SessionManager/AuthManager world and you should probably be storing the data (or a key to your backend store) in the session instead.
  • If the cookies aren't actually relevant to the session, then set them on the WebResponse wherever it makes sense for you to do so. But keep in mind you could see one session's cookies despite the request belonging to a different session because e.g. the request at hand is using CentralAuthTokenSessionProvider (on a CORS request from a wiki where the browser is logged in under a different account) rather than CentralAuthSessionProvider.

I note Gergő had also complained about T111302 and T107707 in the context of this task, but those have their own tasks already and aren't really related to SessionManager/AuthManager.