Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in capital.
Change-Id: If8c0cf4627fc62ff288d33658e327ae80548f5c5
Removed 'Remember my login' from Preferences, as it was unwanted. It adds
to the complexity of the user preferences
Bug: 52342
Co-Author: Tyler Romeo <tylerromeo@gmail.com>
Change-Id: I7c957e1e1aaecf47f7c47bc063b5d3b364644afc
Variants included 'in <version>', 'as of <version>' and just the
version number.
Some @deprecated annotations do not have the version number at all,
I want to hunt them down separately.
Change-Id: I8208c6097098f4735d4f51bc42254675f1f27f6d
- Added spaces after if/foreach/catch
- Added new line before end of file
- Added or removed spaces before/after parenthesis, comma
- Added spaces around string concat
Change-Id: I0590070f1b3542108e242730e8d9a3ba9831e94f
As part of https://www.mediawiki.org/wiki/Requests_for_comment/Passwords
This patch:
* Allows users to login with a password that does not meet the
requirements of User::isValidPassword(), including the minimum password
length.
* Adds a configuration flag that specifies if users should be sent to
the change password form when they login with a password that doesn't
meet the requirements of User::isValidPassword().
To test the UX as it will be on WMF wikis, set
$wgMinimalPasswordLength=6 in your LocalSettings.php.
Change-Id: Ib7b72005fea1c69073c0a33a68c0a0df0d6528d2
Refactor the password checks to return a status object, so the function
can handle the entire error message, or return multiple error messages.
This patchset aims to keep the functionality identical. A followup
patchset can further improve the functionality. E.g., although
getPasswordValidity stated it could return an array of messages, it
never did so except from the hook, so most callers expect and handle a
single string.
Change-Id: I87644486f5572dc067ebdbacd01fb39c67e5612a
* We do not care about gap locks here, just as in the case
with new users. Races should be rare and are simply FWW.
Change-Id: Ie483a2d5df501619acbd868bf894dfc6c911a753
$wgRateLimitLog is meant to log rate limiting occuring in MediaWiki. The
feature was introduced by e46d19e72d / r9202 in 2005. We might not
have wfDebugLog() at that time and we used error_log() with the global
pointing to a file. A later patch converted to file_put_contents().
On Wikimedia production the variable is set to a udp:// URL, I am not
sure file_put_contents() can write to it. Additionally the warning are
suppressed which I tend to hate.
Instead use the log bucket 'ratelimit'.
For backcompabitilibity purposes, if $wgRateLmitLog is still set:
attempt to set $wgDebugLogGroup['ratelimit'] with its value.
Change-Id: I86131c4a8053800afd9f41fa1906c998a88736c6
It seems like our token comparison would be vulnerable to timing
attacks. This will take constant time.
Bug: 61346
Change-Id: I2a9e89120f7092015495e638c6fa9f67adc9b84f
Add functionality to expire users' passwords:
* Adds column to the user table to keep a password expiration
* Adds $wgPasswordExpirationDays, which will force users to reset
their passwords after a set number of days. By default, this set
to false, so passwords never expire.
* Adds a default grace period of 7 days, where if the user's password
is expired, they can still login, but are encouraged to reset their
password.
* Adds hook 'LoginPasswordResetMessage' to update reset message, in
case an extension wants to vary the message on a particular reset
event.
* Adds hook 'ResetPasswordExpiration' to allow extensions to change
the expiration date when the user resets their password. E.g., if
an extension wants to vary the expiration based on the user's group.
If the user is in the grace period, they get a password reset form
added to the login successful page. If an extension prevents showing
the login successful page (like CentralAuth), it should be updated to
show a password change form during the grace period. After the grace
period, the user will not be able to login without changing their
password.
Also prevents a successful reset if the user is "changing" their
password to their existing password.
No passwords will expire by default. Sites will have to call
User->expirePassword() from their own maintenance script to trigger a
password reset for a user.
Bug: 54997
Change-Id: I92a9fc63b409b182b1d7b48781d73fc7216f8061
The hooks are not actually being called multiple times,
since getDefaultOptions caches its return value
(except while unit testing).
However, this change caused a regression due to different
handling of saved values (e.g. false no longer saves
when the default is true).
This reverts commit ff355e87e2.
Bug: 60653
Change-Id: Ibbd34dde5ec5fafbdf6097337cc0fa94614f0b85
Since we only want to save non default user options, we have to strip
out any user option that match the default ones. We did that by calling
User::getDefaultOption( 'some option name' ); on each of the option.
Since the User mOptions property is a merge of the default option, we
end up doing a lot of unneeded processing. The loop roughly looks like:
User::getDefaultOption()
User::getDefaultOptions()
Language->getCode()
SearchEngine::searchableNamespaces()
language->getNamespaces()
wfRunHooks('SearcheableNamespaces')
wfRunHooks('UserGetDefaultOptions')
For EACH of the mOptions.
Instead this patch does an array_diff to strip out from mObjects any
default option. We still skip options whose value is false or null.
Test provided to make sure we only save what we want.
Change-Id: Ie98d3a17edab74401ed32f759ba11f723b56e376
The sender name for system mailings can now be configured
locally by modifying the system message "emailsender". The
new default sender name is simply "{{SITENAME}}". Added to
release notes.
Also modify UserMailer to strip CR/LF linebreaks from header
values to prevent mail header injection now that the sender
name can be modified.
Bug: 32770
Change-Id: Ibfd28cd181365c8c0b5f3e8ffe8f5de8c89844a3
The Line continuation Coding conventions prefers the closing parenthesis
on the same line than the beginning curly braces. This is done for ifs
and functions.
Also move some boolean operator from the end of a line to the beginning
and changed some indentation to make the condition hopefully better
readable.
Change-Id: Id0437b06bde86eb5a75bc59eefa19e7edb624426
- Place commas correct
- Moved comments
- Add space after if/foreach/catch
- Reformat some conditions
- Removed trailing spaces/tabs
Change-Id: I40ccda72c418c4a33fcd675773cb08d971510cdb
The function is not used in core or in any extension in git,
and the PageRenderingHash hook in User::getPageRenderingHash
is not used in any extension. (note the hook still exists
in ParserOptions).
Change-Id: Ica27ce3828dd6551e21671ff723427d09c2dcadb
This allows the temporary password to be cleared. This methods now
behaves the same as User::setInternalPassword() with that value.
Bug: 57075
Change-Id: I2c446864c7eb591dcb64e5971bc9989950715d15
== Prelude ==
wl_notificationtimestamp controls sending the user e-mail
notifications about changes to pages, as well as showing the "updated
since last visit" markers on history pages, recent changes and
watchlist.
== The bug ==
Previously, on every view of a page, the notification timestamp was
cleared, regardless of whether the user as actually viewing the latest
revision. When viewing a diff, however, the timestamp was cleared only
if one of the revisions being compared was the latest one of its page.
The same behavior applied to talk page message indicators (which are
actually stored sepately to cater to anonymous users).
This was inconsistent and surprising when one was attempting to, say,
go through the 50 new posts to a discussion page in a peacemeal
fashion.
== The fix ==
If the revision being viewed is the latest (or can't be determined),
the timestamp is cleared as previously, as this is necessary to
reenable e-mail notifications for given user and page.
If the revision isn't the latest, the timestamp is updated to
revision's timestamp plus one second. This uses up to two simple
(selectField) indexed queries per page view, only fired when we
do not already know we're looking at the latest version.
Talk page indicator is updated to point at the next revision after the
one being viewed, or cleared if viewing the latest revision. The
UserClearNewTalkNotification hook gained $oldid as the second argument
(a backwards-compatible change). In Skin, we no longer ignore the
indicator being present if we're viewing the talk page, as it might
still be valid.
== The bonus ==
Comments and formatting was updated in a few places, including
tables.sql and Wiki.php.
The following functions gained a second, optional $oldid parameter
(holy indirection, Batman!):
* WikiPage#doViewUpdates()
* User#clearNotification()
* WatchedItem#resetNotificationTimestamp()
DifferenceEngine gained a public method mapDiffPrevNext() used
to parse the ids from URL parameters like oldid=12345&diff=prev,
factored out of loadRevisionIds(). A bug where the NewDifferenceEngine
hook would not be called in some cases, dating back to its
introduction in r45518, was fixed in the process.
Bug: 41759
Change-Id: I4144ba1987b8d7a7e8b24f4f067eedac2ae44459
There are certain preferences, such as realname and emailaddress, that
are handled specially in Special:Preferences and are not accessible by
User::getOptions or User::setOptions. But action=options was allowing
a 'dummy' version to be set in User::setOptions.
Change-Id: I4c1b3d8e1eae9520228d7b6da9c41ada80f7c387
PHP's __call magic method can't handle functions with reference
parameters correctly,[1] which means that we need to manually unstub
StubObjects before calling such a method. Or you could use call-time
pass by reference with call_user_func_array, which is rather backwards
and verbose.
This change adds a convenience function to do this, and applies it to
the two calls which brought it to my attention.
[1]: https://bugs.php.net/bug.php?id=40694,
https://bugs.php.net/bug.php?id=62455
Change-Id: I74a0c04bf358e164f753b82fbefbd6205d9b2451
Also removed some unnecessary ones. I think I've caught them all.
The spaceless version already appears in core ~300 times (after
accounting for false positives when grepping). Some consistency would
be nice.
Change-Id: I607655b5f4366e66dc78730d5fd2f57ed8776cae
* Follows-up b2e2b2e016.
* Minor clean up of surrounding documentation comments.
* Fixed missing keys for messages in WebInstallerPage
Change-Id: Iaa692064262f3c0e10cfa5e4b1ec8c86e5d02362
* Introduce a hook allowing automatic redirects to HTTPS to be
disabled on the basis of client IP address.
* Make User::requiresHTTPS() return false if the client IP is
blacklisted as such.
* On login, make the "stick HTTPS" option default to false if the
client IP address is blacklisted as such.
* Do not redirect anonymous requests to HTTPS.
* If $wgSecureLogin is enabled, link to the HTTPS login page *via*
the HTTP redirect, so that there is no need to vary the cache of
anonymous page view HTML on client IP address.
Change-Id: Iaa9dd2108431b8c35e05db4bfe78a629018a003c
Intended for situations where current user can't technically access the
site over a secure connection, e.g. due to a terribly obsolete browser or
WP Zero carrier that provides only insecure free access to the site.
Change-Id: I343985092c49a21fa347ca4dc0e5ec27774ad11d
Removed the wpStickHTTPS checkbox from the login form, and instead
just use the user's preferences along with whether they came from
HTTPS or not to determine if they should stay in HTTPS.
Bug: 29898
Bug: 52283
Change-Id: I69e9cb23b8d700e821b8a961c672958e4e19e4f8
Now with the introduction of page language, a site can have pages
in all languages, and different languages have different variants.
This patch allows users to set preferred variants for every page
they may see on the site.
Change-Id: Ie7e82bee0b1f8f902b38bb4a464cf0ebc4df4d89
Various bits of code are not using this because it doesn't support
various use cases, e.g. session cookies, httpOnly, custom paths, etc.
Refactor it to add all those options. Also add a hook so extensions can
override the setting of the cookie.
Change-Id: Ia0c424a48d9455a8574d91631cde0f00c9882288
Do not allow the user to change it directly; instead create a form
where they can reset it. (The token can still be changed via the API.)
The token is autogenerated whenever it is shown or otherwise used.
This really should have never used the preferences; however, trying to
change that now would be lots of work for very little gain, so this
keeps using that mechanism, adding a little abstraction over it.
It's not unconceivable that similar tokens could be used for other
pieces of data, like Echo's notifications; this enables that with one
new hook.
----
Things done here:
* Add getTokenFromOption() and resetTokenFromOption() methods to User,
abstracting out the get-and-generate-if-empty process of handling
tokens. Respect $wgHiddenPrefs (Watchlist didn't do that
previously).
* Create Special:ResetTokens, inspired by Special:Preferences and
Special:ChangeEmail, presenting the token resetting interface
(HTMLForm-based with CSRF protection).
* Create a new hook, SpecialResetTokensTokens, allowing extensions to
register tokens to be shown in the resetting form. Each token needs
information about the preference it corresponds to and a short
description (used for checkbox label).
* Hide the preference on Special:Preferences (use type=api to achieve
this), display a link to aforementioned special page instead. Move
info blurb to its own section at the bottom.
Bug: 21912
Change-Id: I0bdd2469972c4af81bfb480e9dde58cdd14c67a8
The docs comment says it returns an int but it often returned a string.
This led to casting this value into an integer in other parts of the
codebase and in extensions (grep MobileFrontend or Echo for EditCount).
Bug: 51633
Change-Id: I6fe5b26c24e674e8148c1fd278774b3fabe844c5
Extension unit tests depend on being able to change these
mid-request (that would never happen during normal usage).
Change-Id: Ic32da022cf774341631686e6345969acc1aa5055
User::groupHasPermission is used for various purposes, from checking
whether it makes sense to show a "hide logged-in users" on
Special:NewPages to showing different error messages in some places when
'user' or 'autoconfirmed' is allowed the action to avoiding unstubbing
$wgUser to check $wgUser->isAllowed( 'read' ) in the common case where
'read' permission is granted to everyone.
For the OAuth work, we need to be able to catch that last type of use
without interfering with the others. This change introduces
User::isEveryoneAllowed() to be used for that type of check, which both
makes sure the right granted to '*' isn't revoked from any group and
calls a hook to allow extensions to indicate that they might remove the
right.
Change-Id: Idfee1b4d0613aaf52e143164acd6022459415c49
