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.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Anomie | T111305 Handle multiple session "traits" in AuthManager | |||
| Resolved | Anomie | T91699 Create AuthManager framework and core classes | |||
| Resolved | Joe | T97675 Custom session handler corrupted by session_destroy, "Failed to initialize storage module" | |||
| Resolved | Joe | T106483 Create new HHVM package for HHVM 3.6.5 + patches | |||
| Resolved | hashar | T106699 Upgrade HHVM related packages on Trusty Jenkins slaves | |||
| Resolved | bd808 | T95864 Mocking abstract objects fails on HHVM | |||
| Resolved | Anomie | T110274 Fix PHPUnit version incompatibility between AuthManager and Jenkins | |||
| Resolved | Krinkle | T99982 Upgrade PHPUnit to 4.0+ | |||
| Resolved | None | T90303 Fetch dependencies using composer instead of cloning mediawiki/vendor for non-wmf branches | |||
| Resolved | JanZerebecki | T106433 replace inline perl in builder wd-mw-composer-merged-install with a proper script | |||
| Resolved | Krinkle | T112895 Support installing composer require-dev packages together with mediawiki/vendor | |||
| Resolved | Tgr | T110628 Improve AuthManager documentation |
Event Timeline
Comment Actions
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.