Ensuring the new value is at least as high as 1 second higher
than the current value is sufficient.
The main code paths using this are checkAndSetTouched (for user group
changes) and saveSettings(), both of which use makeUpdateConditions() which
ensures we bail out if something else already wrote to it in the mean time.
As such, there is no longer a need to make sure our time is higher than
something another server may have written, given that is no longer something
we support.
This variable was introduced in 2005 (MW 1.4) with r9403 (1d12276bcb),
and factored out as newTouchedTimestamp() in 2007 (MW 1.8)
with r16772 (c1094ba987).
Change-Id: I940fb0dd125286a4a348c11e2c8d197f9288a75d
This seems to have been intended as optimization for SiteStore,
but was never used as far as I can tell. Instead, SiteStore is
already cached via LocalServerCache (APC).
Keep the FileBasedSiteLookup class for one release cycle in case
third parties not indexed by MediaWiki Codesearch are using it.
== History
* 2013: Report of high memcached usage by Wikibase via SiteStore.
* 2014: Lazy-load the data in Wikibase (d3f2e99cb6).
* 2014: Implement the file-based cache (via T47532 and 90f6efc360).
* 2015: Use local-server cache (APC), per T58602.
The file-based code was never used. The related task marked
invalid (T47532).
Change-Id: I8e2d9edcf3880149f824cc3de37793ca57435b49
Password policy checks that fail and have `suggestChangeOnLogin` set to true will
prompt for a password change on login.
Below are some rules that apply to this setting in different scenarios:
- If only one policy fails and has `suggestChangeOnLogin = false`, a password change will
not be requested
- If more than one policy fails and one or more have `suggestChangeOnLogin` set to true`,
a password change will be requested
- If `forceChange` is present in any of the failing policies, `suggestChangeOnLogin` value
will be ignored and password change will be enforced
- if $wgInvalidPasswordReset is set to false `suggestChangeOnLogin` is ignored
IMPORTANT**
Before this patch, suggesting a password change was the default behavior (depending on
$wgInvalidPasswordReset), which means that the necessary changes to $wgPasswordPolicy
need to be in place before this patch is merged and gets to production.
Bug: T211621
Change-Id: I7a4a0a06273fa4e8bd0da3dac54cf5a1b78bb3fd
This change s adds 'revert' as a separate log action for file reverts, as it
allows special formatting of log entries and revisions in UI and filtering
for file reverts specifically.
Even though there are no log entries with this log action right now, it does
seem that this was intended as some point, as there are corresponding
test cases in UploadLogFormatterTest, and is listed in
$wgLogActionsHandlers and https://www.mediawiki.org/wiki/API:Logevents
as well. Furthermore, the i18n message 'logentry-upload-revert' already
existed before this change.
Because this functionality can not be provided by tags, the 'mw-undo' tag
is not suited for this use case. However, it could be added additionally to
all log entries with this log action..
Bug: T60209
Change-Id: Ie1ccd8053dc5de58b2297a8460219f0233aab968
Follow-up to I28c31fc4ea.
Also improves what policy values are considered disabled, documents
how to extend core checks/flags and adds a structure test for it.
Bug: T118774
Change-Id: I66bf396e8e8a8c310a47ba337abe9070e7e83ff6
When the option is enabled, the first non-icon
thumbnail encountered has a "high" importance.
Bug: T216499
Change-Id: I8d3c1b3e2d136ba16bd7de4809ee3ca63ab462fe
* Remove 'channels' field references from config/setup
* Remove 'relayer'/'channels' field reference in unit tests
* Remove unused DEFAULT_PURGE_CHANNEL class constant
* Also remove long-since bogus 'pool' field references
Follow-up to 4753b0a4ed
Change-Id: If6670ff4e1dccc8ae253a08b46d205601da10024
So far, everything we had was vulnerable to newest advances in
GPU cracking and timing side-channel attacks. Argon2 was designed
specifically to address these problems.
Unfortunately, PHP support is lagging, with some builds missing
Argon2id or even Argon2i.
Change-Id: Ifdf648f5d8a734a663e630286724a6d0a87c7510
This removes most of the pre-CommentStore text columns, and the
$wgCommentTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_comment remains in the code, as on Wikimedia wikis the revision
table is too large to alter at this time. A future change will combine
that with the removal of rev_user_text, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
CommentStore's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process.
Bug: T166733
Change-Id: I1479c73774e01ead1490adf6128f820c09bce9d4
By default this option will be enabled in core, however, the option will
be overriden by a separate commit to mediawiki-config where it will be
disabled for all wikis for now.
Bug: T215019
Change-Id: I73f060fc954abb6ec02238b16c8598dd6ebd4ae4
Adds a way to set an array of options for a password policy. Currently
there is one option, 'forceChange', which forces the user to change
their password (if it fails the given check) before logging in.
Bug: T118774
Change-Id: I28c31fc4eae08c3ac44eff3a05f5e785ce4b9e01
* Remove PasswordNotInLargeBlacklist => false, it's a no-op
* Deduplicate PasswordCannotMatchUsername
* Remove PasswordCannotBePopular. There is no point in using both
PasswordCannotBePopular (top 10K passwords from SecLists) and
PasswordNotInLargeBlacklist (top 100K passwords from SecLists),
and the CDB lookup is probably not that cheap.
Change-Id: I868846931988b88f06800e42861e82e2bb0bc427
Unused, the return format does not seem useful.
Also improve the documentation of $wgPasswordPolicy
and PasswordPolicyChecks.
Change-Id: Ic01e80cfefc4cfb0eee1eccc6a66942f692278a0
Minimum password length is now 10 by default on privileged
groups (bureaucrat, sysop, interface-admin), and bots.
Bug: T208246
Change-Id: I373c5c6865b90cdc5c4848266c5996dd190f6001
No changes for sitewide blocks when "Prevent user... edit own talk page"
is checked. On partial blocks, this option will be disabled and ignored. All users
will be allowed to edit their own talk page unless a page restriction
for their page is in place.
New rules will be implemented for Namespace restrictions in a different
patch when Namespace blocking is ready.
Bug: T210475
Change-Id: I096edf2887441bccd59f09bf0eceb3988b36db1e
These new classes provide a mechanism for defining the
behavior of slots, like the content models it supports.
This acts as an extension point for extensions that need
to define custom slots, like the MediaInfo extension
for the SDC project.
Bug: T194046
Change-Id: Ia20c98eee819293199e541be75b5521f6413bc2f
WRITE_NEW mode seems to be working well on Wikimedia sites. Let's change
the default to MIGRATION_NEW so existing installs and Wikimedia CI will
start using the new code rather than the old.
This also fixes some unit tests that were broken with MIGRATION_NEW, and
updates some that were forcing MIGRATION_OLD to force MIGRATION_NEW
instead.
Bug: T166733
Change-Id: I7bf4ad0105dd1f6cc49eba3ddcb7a51badcd5ed3
Depends-On: I30f7cdcc3875f3f7af116c1e41e88f62ab9e91d0
Monitoring block notices is behind $wgEnableBlockNoticeStats config
flag which is set to false by default.
The reason behind this metric is to get an idea on how
frequently blocked users attempt to edit a page. Similar tracking
is being added to MobileFrontend and VisualEditor.
Bug: T201718
Change-Id: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
Note that we will still be re-parsing either the old or the new
revision. Keeping the rendered version of the old revision cached
for a bit would be nice, but ParserCache currently does not
support this.
Bug: T205369
Change-Id: I86d26e494924eec24e7b1fb32c424ac1284be478
Editing one's own user JS is a dangerous grant that should only
be given to very highly trusted app. The same is probably true
of CSS as well, even if it's less dangerous.
Editing user JSON, on the other hand, is entirely harmless as long
as the consumers of the JSON are coded reasonably, so grouping it
with JS/CSS editing into a single grant is unhelpful. Make it part
of the editmyoptions grant instead.
This extends an existing grant, which is not great, both in terms
of clarity of the grant (even though user preferences and user JSON
have a very similar role, this grouping is not intuitive) and
user experience with existing access tokens (which seem to grant
the new right but actually don't). It still seems better than
further inflating the number of grant options, though.
Bug: T206438
Change-Id: I14482093f7ce05250398feabbb4d17c0461c04c3
