* This gets lag information that is useful when
the calling code is about to run queries that
will have their results cached.
* This is now used in place of trxTimestamp() for
WANObjectCache set() and getWithSetCallback().
* The WAN cache will use a low TTL if the lag is
too high to avoid caching stale data for weeks.
* Bumped MAX_COMMIT_DELAY as nothing enforces it.
Bug: T113204
Change-Id: I2a95b4088cff42d6e980351555f81a4b13519e24
We have this nice class for unit testing cookie-setting, but the
cookie-setting method ignores all the parameters! Fix that. Also provide
accessors to check the entire set of cookie data, and the set cookies as
a whole.
While this does change the semantics of FauxRequest::getcookie() in that
the name now needs to be prefixed, no extension in Gerrit uses this
method so we should be fine.
Also clean up the case of the setCookie and getCookie methods while
we're at it. Since PHP method names are case-insensitive, this doesn't
even break compatibility with extensions.
Change-Id: Ib44a074bf9796bc0b470d557e39465792f399d30
Within the UPDATE query, if user_editcount IS NULL, user_editcount+1 will
also be NULL, and the change becomes a no-op. So in MySQL, the number of
affected rows would be zero, which is the number of rows that actually
changed.
However, other DBMSs (e.g. PostgreSQL, SQLite) do count no-op changes,
meaning the code would not initialize user_editcount if it were NULL.
Explicitly checking for NULL should ensure consistent behavior across
database types.
Also, if the CLIENT_FOUND_ROWS flag is set when connecting to MySQL, the
server returns "Rows matched:" instead of "Changed:" as the affected row
count. This change would be necessary if MediaWiki, like Drupal, is
changed to use that flag <https://www.drupal.org/node/805858>.
Change-Id: Idac160bae56adc5c5d17f8558c55d87000019741
* This can avoid some stale write race conditions
* Made use of this option in a few key places
* HOLDOFF_TTL was also bumped
Change-Id: I83505a59cce0119e456191c3100f7d97bc86bdbf
* This works by adding a refresh mode to clearSharedCache()
when we want to purge the cache in case it might stale to
avoid further CAS errors. Because an exception will be
thrown, the usual DB callback will not get fired, so avoid
using commit hooks when doing these cache purges.
* Also lowered the tombstone TTL for such purges, since no
data actually changed.
Bug: T114023
Change-Id: Iaad87b4ed24733dac40bc9607d3c97c940710087
* They now issue the delete() write before COMMIT of
the relevant DB (or immediately if no trx is active)
* This can avoid some stale write race conditions
* Updated the WAN cache delete() docs
Change-Id: Id54887976051120b76528070d5f2ceb357d57897
When the array syntax is used for the DNS blacklist, PHP throws a notice about array to string
conversion. This change ensures that the correct string name is used regardless of what type of
blacklist entry is used.
Change-Id: I2511a8320474a02d8f321d04f005bb9d18fb15b3
This allows extensions (e.g. Echo) to detect who made the change without
relying upon $wgUser. It also allows for differentiation between
autopromotion entries which will pass in `false` as the performer.
Change-Id: Idebd78b54dcea1bdc84c83f402e87b240ab4ade1
* LocalUserCreated: Replaces AuthPlugin::initUser()
* UserGroupsChanged: Replaces AuthPlugin::updateExternalDBGroups()
** The similar UserRights hook is deprecated, mainly to get rid of the
passing of $user by reference.
* UserIsHidden: Replaces AuthPluginUser::isHidden()
* UserIsLocked: Replaces AuthPluginUser::isLocked()
* UserLoggedIn: Replaces AuthPlugin::updateUser()
Also, AuthPlugin::updateExternalDB() is deprecated in favor of the
existing UserSaveSettings hook.
Also, 'ResetSessionID' has been removed. Nothing uses it, I don't know
why I even added it in the first place.
Also, replacing the User object passed to AuthPlugin::initUser() and
AuthPlugin::updateUser() will now raise a warning.
Change-Id: If7474cfb26a29b11c2e78147069419ca3b1cba95
It is a minor cleanup operation. I replaced a comparison of user 'mId'
with a corresponding 'User::equals()' call.
Change-Id: I89dea55789f343e794429c38934c263168ef608d
* This got created if unset on API or GUI preferences access,
which leads to writes on GET requests. Try to avoid that
deriving it from user_token, unless overriden. This also
means that changing the password always resets the key,
which is how these things work on most sites anyway.
* The whole getTokenFromOption() method is deprecated, and
this functionality is already in OAuth.
Bug: T92357
Change-Id: I96c0d6f6e535e67545049f01205430249eea8da0
* Hint that mariadb can avoid scanning already NULL rows since
we want to set them all to NULL. This lets the index with the
timestamp be used, which avoids logs of scanning for users with
many rows. For non-parallel replication, this also avoids slave
lag in particular.
Bug: T107923
Change-Id: I8cded5476ef6adb2f8fea57239afd6e9b2a49708
* This can help guard against stale reads if the user was
created or changed a second ago.
Bug: T105896
Change-Id: Ib2a59762cd8f4a4b7ad86d0700f186bee1d5b2d1
$replyto and $contentType should now be passed as an array of $options.
This will make it easier to add more options in the future without
having a long list of optional parameters.
Change-Id: I2c38bb438bd01e0ed2552024a40311f3e8e2dc08
* Also only issue DELETE if notifications exist. Previously,
this would issue a DELETE for all self talk page views.
Bug: T92007
Change-Id: Ifef11c9e5175d68d9615e59e2ed7de2f2c57bde1
Allow callers to specify why they are checking a passwords validity, so
some checks can be modified. Only check the default policy on creation,
since the account doesn't exist it's not a member of any groups.
Bug: T104615
Change-Id: I56b66002562aaa1493d94a90309bc8e4ae3841c8
Does not work as it will also log failed login attempts due
to a wrong password.
This reverts commit 9a97a7530f.
Change-Id: I6abd19da4e6939315a7fe6f7debe5227b68d38a7
To be able to identify any users who are unable to log in when switching
from allowing local authentication to strict.
Change-Id: I2ebdccdad9c7794d1c1b13db6a646a43bc770c4e
* READ_LOCKING is a composite field, so it can yeild 00, 01,
10, or 11 for the relevant two bits. Only one of them should
pass the check to avoid locking and snapshot breaking queries
for no reason.
Change-Id: Ief04ac20c7639fcf79443a3ee39a471542a59551
* This helps if multiple account creation attempts were made in a row
and the slave selected was lagged (either too much for Chronology
Protector or the user did not resend the cookies to link the session).
* The locking also better handles concurrent attempt to make another
account, especially with CentralAuth trying to make external accounts.
This assumes that the rate of concurrent account creations with close
names is low enough given trx speed to avoid gap locking issues. This
will need to be confirmed with low error log rates to be sure.
* The User::idFromName() method now includes a $flags parameter.
Bug: T104615
Change-Id: I8385526a19efc528a016ad2bbf376b377138966b
* This gives more visibility and the error rate is not
extreme (and mostly affects certain users due to
usage patterns).
Change-Id: I3eae28a584e4db8ae40ae80087a97c416b3bd3e8
* This still allows If-Modified-Since logic but does not
need to broadcast initialization values just because a
key fell out of cache. The value can differ between DCs
anyway via skew, this just lets them drift more. Actual
purge events are still broadcasted, which is what matters.
* The User class has now been simplified given this change.
* Added more general comments to getCheckKeyTime().
Change-Id: Ic1f4bbb1947e0d1dd47499c9e9dc86991c30580c
* This covers CentralAuthHooks::onUserLoadFromSession()
among other cases (OAuth user loading, ect).
Bug: T92357
Change-Id: I9c90027d8852ff8c1d626c03b5dbd765b95b0ce1
* Add the $wgExtendedLoginCookies configuration variable, which defines
the set of login cookies that can have their lifetime configured
independently
* Add the $wgExtendedLoginCookieExpiration configuration variable, which
dictates when the extended lifetime login cookies expire
* Default $wgExtendedLoginCookieExpiration to null so that the current
behaviour is unaffected
Bug: T68699
Change-Id: I0cc24524e4d7d9d1d21c9fa8a28c7c76b677b96c
* By default, users will load from the slave unless
the thread did a recent DB write. This is to handle
changes within a request.
* ChronologyProtector should avoid staleness in common
cases, and the CAS check on user_touched is a final
barrier to block stale user object updates.
* Note that passwords are not cached, so they hit the
DB when ever needed. Passwords now load from slaves
when possible, instead of the master.
* This should get the code closer to handling user
login and logged in users when the master is down.
* Fixed loadFromId() when READ_LOCKING is used.
* Also addressed TODO comment in load().
Bug: T92357
Change-Id: I0a8bdab720c19fe3fc2381799ae2e90ff09bb4cf
Make password policies defined in a configurable policy, which is
defined by group. A user's password policy will be the maximum of
each group policy that the user belongs to.
Bug: T94774
Change-Id: Iad8e49ffcffed38df6293db0ef31a227d3962003
