CentralAuth needs 'User' as well for this to work. However, this
shows the exact cookie names are an implementation detail that should
not be exposed as a 'wg'.
Instead, use a function in the CookieSessionProvider. That way,
CentralAuth can override it properly without requiring users to change
$wg's.
I also added UserName. provideSessionInfo will fail to return
session info if UserID and UserName are both set and don't match.
Also, the UserID<->UserName mapping is public, so there is no
additional privacy issue. Thus, it seems we should expire them
the same time.
Bug: T68699
Change-Id: Ia3259846433980408f79d44f665e17e15670e8ee
This aspect of the pre-SessionManager Setup.php code had been
overlooked.
This also updates an inaccurate doc comment that I happened to notice.
Bug: T125313
Change-Id: Id49836086be837012b02885ce5384ae6a4ebc105
* Use PSR-3 templates and context where applicable
* Add log coverage for exceptional events
Bug: T125452
Change-Id: I8f96fa1c5766c739a21219abcae2dbb76de53e2a
The plan here is to take it out of 1.27.0-wmf.12 and put it back in
1.27.0-wmf.13.
Since BotPasswords depends on SessionManager, that's getting temporarily
removed too.
This reverts the following commits:
* 6acd424e0d SessionManager: Notify AuthPlugin before calling hooks
* 4d1ad32d8a Close a loophole in CookieSessionProvider
* fcdd643a46 SessionManager: Don't save non-persisted sessions to backend storage
* 058aec4c76 MessageCache: Don't get a ParserOptions for $wgUser before the end of Setup.php
* b5c0c03bb7 SessionManager: Save user name to metadata even if the user doesn't exist locally
* 13f2f09a19 SECURITY: Fix User::setToken() call on User::newSystemUser
* 305bc75b27 SessionManager: Don't generate user tokens when checking the tokens
* 7c4bd85d21 RequestContext::exportSession() should only export persisted session IDs
* 296ccfd4a9 SessionManager: Save 'persisted' flag in session metadata
* 94ba53f677 Move CSRF token handling into MediaWiki\Session\Session
* 46a565d6b0 Avoid false "added in both Session and $_SESSION" when value is null
* c00d0b5d94 Log backtrace for "User::loadFromSession called before the end of Setup.php"
* 4eeff5b559 Use $wgSecureCookie to decide whether to actually mark secure cookies as 'secure'
* 7491b52f70 Call session_cache_limiter() before starting a session
* 2c34aeea72 SessionManager: Abstract forceHTTPS cookie setting
* 9aa53627a5 Ignore auth cookies with value 'deleted'
* 43f904b51a SessionManager: Kill getPersistedSessionId()
* 50c5256352 SessionManager: Add SessionBackend::setProviderMetadata()
* f640d40315 SessionManager: Notify AuthPlugin when auto-creating accounts
* 70b05d1ac1 Add checks of $wgEnableBotPasswords in more places
* bfed32eb78 Do not raise a PHP warning when session write fails
* 722a7331ad Only check LoggedOut timestamp on the user loaded from session
* 4f5057b84b SessionManager: Change behavior of getSessionById()
* 66e82e614e Fix typo in [[MediaWiki:Botpasswords-editexisting/en]]
* f9fd9516d9 Add "bot passwords"
* d7716f1df0 Add missing argument for wfDebugLog
* a73c5b7395 Add SessionManager
Change-Id: I2389a8133e25ab929e9f27f41fa9a05df8147a50
There's a crazy-small chance that someone could have a logged-out
session (e.g. by logging out or visiting a page that creates a session
despite being logged out), then the session expires, then someone else
logs in and gets the same session ID (which is about a 1 in a
quindecillion chance), then the first person comes in and picks up the
second person's session.
To avoid that, if there's no UserID cookie set (or the cookie value is
0) then indicate that the SessionInfo is for a logged-out user.
No idea if this is actually what happened in T125283, but it's worth
fixing anyway.
Bug: T125283
Change-Id: I44096c69aa7bd285e4e2472959e8d892200c5f2c
The pre-SessionManager code did this, and the change in combination with
the API not honoring forceHTTPS led to T124252.
Bug: T124252
Change-Id: Ic6a79fbb30491040facd7c200b1f47d6b99ce637
There's no reason this should be only in CookieSessionProvider when
we're already handling deduplication in WebResponse.
Further, this fixes the bug in the existing CookieSessionProvider
implementation that a setCookie() followed by a clearCookie() wouldn't
actually clear the cookie.
This reverts commit 1ce684fcef.
Bug: T124252
Change-Id: I1098d054facacd59f03ebed7c747ec9ff6bf66e7
Depends-On: I61d14bf80fa7c857dec9cffb366dc3f84dbb4faf
Some API clients seem to be confused by cookie deletion.
Prevent cookie deletion on the first leg of the API login sequence
(for a client with an empty cookie jar) by only emitting deletion
headers for cookies which are set in the current request.
Bug: T124252
Change-Id: I180e094ea32f951e22adab2ec87d16e5de7cef97
'deleted' is the value PHP sets when it deletes a cookie (via the
Expires/Max-Age headers). Apparently some clients ignore the
expiration date and send 'deleted' back; these clients now cannot
login due to some slight changes in exactly when cookies are
set/deleted during the login process.
To keep those clients from breaking, ignore this special value.
Bug: T124252
Change-Id: Icd0e1bcd8efe0869da981352763d25e4f8075bf2
SessionManager is a general-purpose session management framework, rather
than the cookie-based sessions that PHP wants to provide us.
While fallback is provided for using $_SESSION and other PHP session
management functions, they should be avoided in favor of using
SessionManager directly.
For proof-of-concept extensions, see OAuth change Ib40b221 and
CentralAuth change I27ccabdb.
Bug: T111296
Change-Id: Ic1ffea74f3ccc8f93c8a23b795ecab6f06abca72
