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
Remex is pure PHP so there is no reason to use an external tidy any
more. Configuration variables and implementation classes were
deprecated in 1.32 or earlier. We've kept only $wgTidyConfig
which can be used for experimental features or debugging Remex.
Bug: T198214
Change-Id: I99d48f858d97b6e1d1e6cd76a42c960cc2c61f9f
Using domains means thats JobQueueDB has the right value to use for calls
like LoadBalancer::getConnection(). The full domain includes the schema in
the case of Postgres. This makes calls to getConnection() less awkward by
not relying on the fallback logic in reallyOpenConnection() for null schemas.
Make getWikiIdFromDomain/isCurrentWikiDomain account for the schema if it
is both defined and is not simply the generic "mediawiki" schema MediaWiki
uses by default. If all wikis use the default schema, the wiki IDs can get
by with DB/prefix alone, which various config and methods may be built around.
Otherwise, the config callbacks must account for schema and the config must
include it in various wiki domain ID lists to properly disambiguate wikis.
Also, clean up SiteConfiguration::siteFromDB() since it is not meant
to handle schemas unless the callback method was taylored to do so.
Finally, add more comments to DefaultSettings.php about already existing
limitations of wiki domain IDs and their components.
Change-Id: I8d94a650e5c99a19ee50551c5be9544318eb05b1
Unless an actuall write happens, avoid create log spam over things
like CentralAuthUser->getSafeReadDB().
Change-Id: I1cf43f4b1cdd12eb458458448f0f0ea328925b47
Previously, they were always displayed in defult language unless
forced explicitly in wikitext, e.g. [[File:Foo.svg|lang=ru]].
This change adds a feature flag that would enable always trying to
display in page language.
* If enabled, Parser will pass a new parameter - 'pagelang' - to
the media handler.
* SvgHandler uses page language when determining what language to
render the image in.
* 'pagelang' can always be overridden by 'lang'.
* If no translation in page language is available, the default
language (English) will be used for thumbnail URLs, to prevent
cluttering media storage and HTTP caches with useless copies.
Performance: this requires accessing image's metadata during parsing.
My testing indicates there were no code path where this wasn't the
case already, so no performance hit is expected, however we should
still keep an eye on page save performance.
Bug: T205040
Change-Id: I348840ef405e1370cc0c17d69051bce30153c9c0
This opens up a hole for administrators to load images from external resources,
potentially leaking user's private information to external servers (IP address,
User-Agent, etc.).
Change-Id: Ie780637b292493e664e4d54671a5bb81046106f4
Partial blocks logic will be used in multiple places. This
classes will group block restriction functionality to avoid
code duplication
Bug: T202036
Change-Id: I675316dddf272fd0d6172ecad3882160752bf780
The hooks that used to be called by this class will be removed in
I24d6fa963. The only reason to keep this class around is that
someone might have added it to $wgAuthManagerConfig so removing
it would trigger class lookup failures, so make sure any use
of the class triggers a deprecation warning.
Change-Id: I9755288eda7461ecf3dcd35de2081fbb3eb04ae3
These were introduced in MW 1.17 and are always true in production.
They were useful to allow folks to defer title conversion, but it's
been a long time now. We don't need to make this optional any more.
Change-Id: I65dcfe80dc3e1dfeb4d63924a8928655e012a20c
Add BCP 47 codes to $wgDummyLanguageCodes to ensure that
Language::factory() will return a valid MediaWiki-internal code if
given a BCP 47 alias. We will want to make $wgDummyLanguageCodes a
private property of LanguageCode eventually, but let's start with
removing it from user configuration.
Setting $wgDummyLanguageCodes in LocalSettings.php has been deprecated
since 1.29. Hard deprecate adding entries to $wgDummyLanguageCodes so
that we can eventually remove manual overrides from user
configuration.
This is a follow-up to 48ab87d0a3,
which described the various categories of codes, and
21ead7a98d, which added the correct
BCP 47 mappings.
Bug: T207433
Change-Id: I9f6dda3360f79ab65f6392f44c98926588d851c8
This header supports Squid in forward-proxy mode using HTTP/1.0
HTTP headers. It is not used in production.
Change-Id: I99646c9c5519bd55b3d4988306e379f89d413bdc
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
No longer used anywhere(?); we'd rather not have to explain the temporary
variable in the MediaWiki 1.32.0 release notes if we can instead just not ship
it.
Bug: T192620
Change-Id: Icfb82f228512ed45f1a27ce3e565fbc5fc09f39c
