AuthManager uses a status which is OK but not good for authentication
data which is discouraged but still accepted for authentication.
Users should not be allowed to change credentials into such invalid state.
This change brings the web logic and the AuthPlugin fallback in sync with
the API which already used the stricter check.
Change-Id: I4ff54fcc901f6fe11f15ed60fc1a3d8753de9f6c
Rewrite authentication-related special pages to use AuthManager.
All the changes mentioned below only take effect when
$wgDisableAuthManager is false.
LoginForm is rewritten to use HTMLForm and split into UserLogin
and CreateAccount; ChangePassword and PasswordReset are rewritten;
ChangeEmail and Preferences are updated. Four new special pages
are added to handle the new capabilities of AuthManager (linked
accounts, secondary authentication providers): LinkAccounts,
UnlinkAccounts, ChangeCredentials, RemoveCredentials.
The old form-based hooks (ChangePasswordForm, UserCreateForm,
UserLoginForm) are deprecated. A new, more generic hook is
available to alter the forms (AuthChangeFormFields);
form changes that involve new fields should be done via
$wgAuthManagerConfig.
UserLoginComplete is limited to web-based login; for more
generic functionality UserLoggedIn can be used instead.
Hooks that assume password-based login (PrefsPasswordAudit,
AbortChangePassword) are removed; the first functionality
is replaced by ChangeAuthenticationDataAudit, the second is
handled by AuthManager. LoginPasswordResetMessage is removed,
the functionality can be recreated via authentication providers.
There are several smaller backwards incompatible changes:
* Adding fields to the login/signup forms by manipulating the
template via the extraInput/extrafields parameters is not
supported anymore. Depending on the authn configuration the
login/signup process might be multistep and it would be
complicated to ensure that extensions can access the data
at the right moment. Instead, you can create an
AuthenticationProvider which can define its own fields and
process them when the authentication is over.
(There is B/C support for a transitional period that works with
the default login form, but might break with configurations that
require multiple steps or redirects.)
* Removed cookie redirect check. This was added in 2003 in 9ead07fe9
for the benefit of bots, but with MediaWiki having an API these days
there is little reason to keep it. Same for the wpSkipCookieCheck
flag (added in 2008 in 29c73e8265).
* Instead of embedding a password field on sensitive special pages
such as ChangeEmail, such pages rely on AuthManager for elevated
security (which typically involves requiring the user to log in again
unless their last login was more than a few minutes ago).
Accordingly, wgRequirePasswordforEmailChange is removed.
* Special:ChangePassword requires login now.
* Special:ResetPassword now sends a separate email to each user when called
with a shared email address.
* the Reason field had a message with 'prefsectiontip' class
which was sorta broken but used in extensions for formatting.
HTMLForm does not support that, so this commit turns it into a help message
which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884
Bug: T110277
Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c
Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.
Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
Adds a preference in the Watchlist section for watching uploaded files
for an account. Also works from API-based upload methods, so
UploadWizard and other tools should work fine.
Bug: T33313
Change-Id: If962e667de12b35904b2d1b2d9e99c26b588ec2a
Instead of setting $wgHiddenPrefs in Setup.php when $wgEnotifMinorEdits
is false, it is better to check the config in Preferences.php.
This makes it easier to found the config, why the preference is not
shown.
$wgHiddenPrefs should not be used in core itself
Change-Id: I7e1afd65c8924f18fdfa6cb5c9a47481b036b74f
This change adds a new method setAutocomplete to the class HTMLForm.
This method allows to set the HTML attribute autocomplete for the form.
This change uses this method to set autocomplete="off" for the preferences form.
Without autocomplete="off" the selections in the preferences get cached in
the browser. This can lead to wrong selected options when the settings get
changed on an other way, for example via API.
Bug: T131047
Change-Id: I2920383b5b8cfca3f1d546315f202985edf417d8
The session data gets set in the POST and gets deleted in the GET.
This change avoids changing the URL for the success message.
A reload of the page does not show the success message again.
The URL manipulation in mediawiki.special.preferences.js is superfluous.
Bug: T26700
Change-Id: I1c2b011e7a66b2b9379dd4a3fdcc6f978dd43b52
* 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
As @matmarex suggested I used the same colors for warning as in shared.css for .warningbox
Bug: T58611
Change-Id: Icba7787db4cc77ee793b9637c60b5977d28dc8cf
The biggest negative point (as far as I can tell) with the change mentioned in the follow-up
is, that a user needs at least 3 clicks to change an option, which before it required only
one click. This option adds a new preference for the watchlist (which can be enabled/disabled
using Special:Preferences) which, if enabled, loads a new, tiny module with a script, that
listens on all input and select fields in the header form of Special:Watchlist. Whenever one
of these elements get changed, the watchlist form will be submitted automatically.
The default for this option is false (disabled).
Follow up: I3bcd27596c21aa4
Bug: T50615
Bug: T119322
Change-Id: Icab1a5143df24a06f468165421d40db8fa57e73c
New styles modules that is always added, so that all JS specific styling
is guaranteed to load before first paint. Reworked the HTML to generate
the preftoc (hidden when user has no JS).
Set htmlform nolabel class to use !important, so that it doesn't get
overriden by the 20% width rule of labels.
Also requires changes to the skinstyles of Vector preferences, which
is an a separate patch (I59f0f45), and other skins.
Bug: T115692
Change-Id: I24d9b16ed6729fdf0d59adcc2f0ba16f4f621b44
This is part of a chain that reverts:
e412ff5ecc.
NOTE:
- The feature is disabled by default
- User settings default to hiding changes
- T109707 Touching a file on wikisource adds and
removes it from a category... Even when page
has no changes.... WTF? See linked issue,
marked as stalled with a possible way forward
for this patch.
@see https://gerrit.wikimedia.org/r/#/c/235467/
Changes since version 1:
- T109604 - Page names in comment are no longer
url encoded / have _'s
- T109638 & T110338 - Reserved username now used
when we can't determine a username for the change
(we could perhaps set the user and id to be blank
in the RC table, but who knows what this might do)
- T109688 - History links are now disabled in RC....
(could be fine for the introduction and worked
on more in the future)
- Categorization changes are now always patrolled
- Touching on T109672 in this change emails will never
be sent regarding categorization changes. (this
can of course be changed in a followup)
- Added $wgRCWatchCategoryMembership defaulting to true
for enabling / disabling the feature
- T109700 - for cases when no revision was retrieved
for a category change set the bot flag to true.
This means all changes caused by parser functions
& Lua will be marked as bot, as will changes that
cant find their revision due to slave lag..
Bug: T9148
Bug: T109604
Bug: T109638
Bug: T109688
Bug: T109700
Bug: T110338
Bug: T110340
Change-Id: I51c2c1254de862f24a26ef9dbbf027c6c83e9063
* 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
Message changed from "Threshold for stub link formatting bytes" to
"Threshold in bytes for stub link rendering (sample)".
Also convert it to a wikitext message (not raw HTML) and improve the "qqq"
documentation.
Bug: T107732
Change-Id: I493679073b9881c98a068dede2db00b391ab8353
The timezone list on Special:Preferences contains all time zones with a
localized region and also an option to use the system default value.
The message for this option gets the current server timezone as
parameter, but that parameter is not localized.
Refactor the timezone list processing into a new function and call it at
the beginning to do a lookup for the localized name and use it, if it
exists in the array.
Also changed from procedural style to object oriented style for the
DateTime processing.
Bug: T33516
Change-Id: I00e81324d0d16fbe6c9811480210ab6513461823
See https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/
Ignoring SVN stuff because svn.wikimedia.org's SSL certificate has expired, and
ignoring wgSharedUploadPath because T25122 wants to get rid of it.
Also a couple of BZ -> phab changes
Change-Id: I02fd23ac6c30a4a4c718e57d4dedbc693dd653c0
This uses the NP patrol check instead of the RC patrol check for the
preference option that allows to hide unpatrolled new pages by default.
And this checks use of RC patrol for the user instead of the config for
the watchlist option (so that users who cannot patrol don't have it).
Bug: T89716
Change-Id: I2895a96f8c21ade83b0174d0d02d1b7e00625737
This adds a new "Edit watchlist" section to Watchlist tab with links
to Special:EditWatchlist, EditWatchlist/raw and EditWatchlist/clear.
Bug: T26632
Change-Id: Id31fba4f7aadaa3e427becece3837a8d00b7718f
Pass the HTMLForm parent instance in the constructor so context
is available when parsing a message.
Change-Id: I532c0d95698cbcc57294b9bd2725f33838f393a9
As noted by Bartosz, System|60 is also valid (apparently also
ZoneInfo|something, but not sure what can go after ZoneInfo), and the
maxlength interferes with this.
Maybe eventually we could revisit and use input#pattern
(http://www.w3.org/TR/html51/forms.html#the-pattern-attribute). That
allows specifying a regex, which could have different length limits
depending whether it started with a number (AFAICT, the 6 length is valid
if it starts with a digit).
But for now, that is not urgent, and we need to fix the regression.
This reverts commit da470ce005.
Bug: 70405
Change-Id: Ib585c76688284dab78e85fb355785c06d0c3e353
Stop littering MediaWiki with globals, provide a common
api for generating them similar to how we do text input
attributes before things get out of control.
Adds
* submitButton
* linkButton
Change-Id: I61bb3c358f755ed9f2153d94b744c1a9da02c456
* Supported formats (controlled by filterTimezoneInput) are:
** -12:34/01:23. It says, "Max is +14:00 and min is -12:00", both
of which fit in 6 (if someone uses -24:00/+24:00, it's the same width
anyway).
** If it's not in that format, it's treated as a simple hour, which
means it should be from -12 to +14 (max 3).
Bug: 70405
Change-Id: I47ec2c07929069cb5243c306a1c502751e57a31b
Much like the similar warning on the edit page, it has been requested
that we display a warning if the user has made changes on
Special:Preferences and attempts to leave without saving.
This adapts the code from
resources/mediawiki.action/mediawiki.action.edit.editWarning.js to do
so.
Bug: 55966
Change-Id: Idb00f50ad8148cd80bd0af81b4cd06a0eb217d96
* Apply mw-ui-destructive to Special:Preferences/Reset
when $wgUseMediaWikiUIEverywhere is enabled
Introduces HTMLForm->setSubmitDestructive()
Bug: 65317
Change-Id: I1d6691dce3e7dab662bda9a718e16c5caee6c041
Having a radio field with no valid values makes MediaWiki sad and
causes exceptions.
Also make double-sure that the global default value is not invalid.
That causes exceptions too.
Change-Id: I90cc9e6f40303aa5771c265948a0be4a4ce2e42c
This change adds a preference in the 'watchlist' section to
automatically watchlist a page after rollbacking.
The setting is only visible, if the user has the 'rollback'-right.
I have removed the watch reverts function per advice by Vogone.
Bug: 4488
Change-Id: I3aa831c9c04d627684641af0ca5a332795c87062
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I783e4dbfe5f6f98b32b9a03ccf6439e13e132bcc
- Removed spaces after not operator (!)
- Removed spaces inside array index
- use tab as indent instead of spaces
- Add newline at end of file
- Removed spaces after casts
Change-Id: I9ba17c4385fcb43d38998d45f89cf42952bc791b
Currently it's an insanely tall list box. All the other settings on this
page use combo boxes, so we should be consistent.
After it was changed from 'selectorother' to 'select' in I88212703
and support for 'size' in HTMLSelectField was enabled in I7ac345e1,
the size defines the height of the select box instead of the width of
the text input field.
Bug: 68313
Change-Id: Id42a62e78fc2fee741bb02b88dc14cbb1b63635a
* Checkbox on own row below power search checkboxes per MatmaRex;
avoiding a mw-search-ns* id leaves it untouched by All/None JS.
* The option searcheverything is removed: a "shortcut" which is no
longer necessary now that options can be (un)selected at once
with All/None buttons on search page itself.
* Require a token for saving: no accidental preferences changes.
* Keep the searchoptions/advancedsearchoptions prefs section in case
something is using it (no known extension does though); options
are converted to "api" type so it's empty and hidden by default.
* Add minimal documentation for saveSettings() and friends
(@todo since 155ddf6de, 2009!).
Bug: 52817
Change-Id: I514cee835988600cc013658049e88a10b670e64a
