When an entry point specifies MW_NO_SESSION, actually enforce that by
having both SessionManager and PHP's session handling (session_start()
and friends) throw exceptions.
If an entry point needs the old behavior of using PHP's default session
handling (as defined in php.ini), it should define
MW_NO_SESSION_HANDLER instead of or in addition to MW_NO_SESSION.
This also makes PHPSessionHandler be installed in CLI mode, where it
wasn't installed before.
Bug: T127233
Change-Id: I2a3db06ee8e44a044096c57a819b5fd5e51c5c5c
47973faa7c used a static string for ip-all/subnet-all limits,
instead of generating a key unique to each wiki.
Change-Id: Ie8013dc959fdeba92ecd463550e3d98d83276004
Autocreation needs to check if the current IP is blocked from account
creation.
There are two ways we could go here: treat $wgUser as logged-out, or
assume it will eventually be the user name specified by the session.
This patch chooses the former, by the logic that at this early point in
the setup process we don't have a logged-in user determined yet so no
username can really be considered to match the logged-in user.
Bug: T124367
Change-Id: I631bec85291b57f07c378cf6554a8f06cf3fb00c
To avoid having to have SessionManager try to reset sessions on every
request, we set the user_token to a special value. When that value is
present, User::getToken() returns a different value every time (so
existing checks will fail) and User::setToken() refuses to alter it.
Bug: T124414
Change-Id: Ie4c84ce993e40a081288cf5a543f8ba99f98806a
This allows for quickly invalidating everyone's session all at once by
changing a single value.
As a side effect, setting this also stops the user_token field from
the database from being served to the user as a cookie.
This mitigates but doesn't completely solve T49490, as it allows for
invalidating all existing sessions and token-cookies but does not help
if the user_token field in the database was leaked.
Bug: T49490
Change-Id: I9d316a6bbb36278d138f39a89125ebb8cc71b28f
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
It looks like this used to actually be used
since Ie60e20162fd833e64d81763a6aa1dc3faf2162f3
but since the global wgActivityUpdatesUseJobQueue
seems to have been removed from the code.
Thus this stuff is doing nothing and
things are always DEFERRED.
Change-Id: I08cb6051f52e0f0402542d8326f03f115bb00943
Similar to T124414, we should always load user_token from the row even
if user_email is unset.
Also, I notice that maintenance/tables.sql defines the column as
"binary(32)", which is going to append ASCII NUL bytes to the default
empty-string. And before that it was "char(32)", which will append
spaces. So trim both of those off when reading the field so the
following check for === '' actually works.
The latter doesn't seem to affect *most* WMF wikis, since they have the
column defined as "varbinary(32)" for some reason. But there are a few
with "binary(32)", I have no idea why.
Change-Id: I50a813bb530639275628d9560c79a773676aa36d
User keeps most of its token-related methods because anon edit tokens
are special. Login and createaccount tokens are completely moved.
Change-Id: I524218fab7e2d78fd24482ad364428e98dc48bdf
These apply to all ping-limitable users, unlike ip and subnet that apply only
to anons and non-autoconfirmed users. However, if an autoconfirmed user is in
a group with less restrictive limits, then those are ignored.
This is necessary to move the account creation throttle into the ping limiter.
Bug: T50373
Change-Id: Ifc70a605bb8848070bdf2af8f2c3f80f68dcc085
Always load user_touched from the row if present, don't gate it on
user_email being non-null.
Bug: T124414
Change-Id: I68fcbb560ddfa349b83126298534161971a88871
This avoids infinite loops when trying to load other User objects, and
should still preserve the intent of the timestamp (that being as an
invalidation date for client-side caching).
Bug: T124143
Change-Id: Ie304cc3839fdc36a1cb2895e26f7700f4b725159
This removes the userright 'proxyunbannable' from core, because it has
no uses. It is never checked for users with 'ipblock-exempt', yet all
usergroups with 'proxyunbannable' also have 'ipblock-exempt'.
Bug: T75414
Change-Id: I1e4f6ca439c0274af89f3280fbc519df2b68312c
Bot passwords are something like OAuth-lite, or Google's application
passwords: the bot can use API action=login to log in with the special
username and password, and will then be allowed to use the API with a
restricted set of rights.
This is intended to provide an easy migration path for legacy bots and
for bots on wikis without OAuth, since AuthManager is going to greatly
complicate non-interactive authentication. If OAuth is available, an
owner-only consumer would be a better choice.
Bug: T121113
Change-Id: Iaa4015e00edbfbfaedcc8b2d27a2d3fd25009159
Depends-On: I7e15331efb162275c4116bcae61f19d6b884cbe3
This also adds code to User to allow SessionProviders to apply the grant
restrictions without needing to hook UserGetRights.
Change-Id: Ida2b686157aab7c8240d6a7a5a5046374ef86d52
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
The isAllowed() function of the User class checks $wgUseRCPatrol and
$wgUseNPPatrol in case the action is 'patrol' or 'autopatrol'.
Considering we have the useRCPatrol and such functions, it shouldn't.
getUserPermissionsErrors of the Title class doesn't and extensions may
use patrol regardless of core config. If we don't remove it, we would
have to also check the new $wgUseFilePatrol.
Change-Id: I671a6b3aa3bd1dc274f2f8e61fb739235ced198c
This allows to patrol file uploads, both new files and new file
versions, from the description page, provided $wgUseFilePatrol
is set to true. Special:NewFiles can be filtered to hide patrolled
files.
Bug: T11501
Change-Id: If71af58719a4461f12d125455b7bef07164525ca
There is no point in using hash_equals for the return value if we
do a normal comparison before.
Bug: T119309
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
Change-Id: Ia44ec5ed492105b27d0fddd845d58d27a29dc072
* This does the same thing ApiOptions does to avoid these errors.
A new getInstanceForUpdate() method is now in the User class to
simplify this pattern.
* Avoid overriding $user in ApiOptions for code readability.
* Fixed IDEA errors around Preferences::getFormObject() return type.
Bug: T95839
Change-Id: If2385b7486c043bd70d7031ff35e37dfb079a4d2
Use the correct timezone when setting the expiry timestamp in the email
confirmation.
Using Language::userDateAndTime to avoid indirect use of $wgUser, so it
is always the timezone used of the user the message gets send for.
Bug: T29158
Change-Id: Ieb74b72a4255d9d652f828d1879882dff4b45379
Anything that wants to be "central" right now has to depend on
CentralAuth, and then either can't work without CentralAuth or has to
branch all over the place based on whether CentralAuth is present. Most
of the time all it really needs is a mapping from local users to central
user IDs and back or the ability to query whether the local user is
attached on some other wiki, so let's make an interface for that in
core.
See I52aa0460 for an example implementation (CentralAuth), and Ibd192e29
for an example use (OAuth).
Bug: T111302
Change-Id: I49568358ec35fdfd0b9e53e441adabded5c7b80f
