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
The addGroup and removeGroup functions in User were reloading the cached
mRights, but not calling the UserGetRights hook that is supposed to
allow for extensions to modify the rights list. Instead, let's just null
the cache so it will be reloaded next time something calls
$user->getRights().
Note we still call $this->getEffectiveGroups( true ), though, to trigger
that to recache.
Change-Id: I81784917303b639bc7c22c726e9cbdb0d191e674
This enables plugins to add/remove groups in an external authentication
service when a group is added via the MediaWiki interface without relying
on the related Hooks. Relying on the Hook would mean that a plugin cannot
use User::addGroup or User::delGroup to add/remove groups comming FROM
the authentication service, as these functions would call the hook and
then redundantly add these groups to the auth-service again.
Change-Id: Ia04d5bb30831a89dfc66128e3c335bbe07f724b6
Since it is easier to interpret in VCL. The read side code strangely
does not need to be updated, and MW will continue to work with
cookies sent before this change, because wfTimestamp() automatically
detects the timestamp format.
Change-Id: I8c661b735b1de8e295d5d713a5ca959ee99e274e
It has long been recognized that using the 'protect' right to control
the ability to edit sysop-protected pages is troublesome. r31247 fixed
this by adding an 'editprotected' right, but for some reason in r32164
this was changed to bypass protection completely instead of fixing the
bug identified in r31462.
This patch goes back to do it the right way: editprotected no longer
bypasses all protection, and it is used instead of 'protect' for
controlling access to sysop-protected pages. For good measure, the same
is done with autoconfirmed protection (semiprotection): a new
editsemiprotected right is created instead of overloading the
existing autoconfirmed right.
This also fixes bug 27152 by making editprotected no longer special.
Bug: 13137
Bug: 27152
Change-Id: I6bf650a3fbdab8589ae6945c8c916eafd949e41c
These are needed for OAuth grants.
Note that we don't bother with a 'viewmyoptions' right, since the
majority will be determinable from just observing the interface.
Note that the fact of having a confirmed email address cannot be
reliably hidden, and if the user has 'sendemail' they may be able to
determine the real name and email address by sending an email to another
account that they control.
Change-Id: I3f03dd010020e8d43cc2d3bca7b3ef7196d1c548
These are needed for OAuth grants.
Note that, even if 'editmywatchlist' is not granted, various actions
will still allow for adding but not removing of pages.
Change-Id: Ie33446a228dd6ed0114730935c1bf65667f5ce01
* Parameter type hint should be a variable type or a class
name. Types Null, Bool, Boolean, Int, Integer, String do
not exist and are invalid values. Changed to their PHP
type names (basically just lowercase).
* Made inline comments consistently use "//" instead of "#".
* Removed various odd spurious spaces sequences in @param
lines. They are sometimes used to pretty-align multi-line
descriptions. Though I think that is silly, I've left those
alone. I've only removed the spaces where it seems arbitrary
and not aligning with anything. Last I checked the common
convention for multi-line descriptions is to simply continue
on the next line with one extra space as indention.
* Swapped "$var Type" in cases where the surrounding @param's
already use "Type $var".
Change-Id: I6b315e308271194815879c509d3ac6aeb409851b
The User::getDefaultOptions() has to set up the 'language' and 'variant'
language. That was done using two calls of $wgContLang->getCode().
This patch reduce it to one call.
Change-Id: I0a30f2541e35c115d1cda72ce40d5e3dcd405c5b
This is required for auth plugins to be able to send customized
email confirmation and migration emails. For example, we need to
send emails from CentralAuth that will both confirm the email
address and then run through Special:MergeAccount attempting to
attach as many local accounts as possible.
Change-Id: If281aa6219e5a0b80252b0deac7ee0c4f74c3d58
- 'subnet' will aggregate limits for a /64 subnet on IPv6
- Updated DefaultSettings.php to mention this
- Only call WebRequest::getIP() when it will really be used
Change-Id: Ia96800df5fb498a79e2c0527baee2392cd4623c7
* $wgHtml5 = false; is now ignored completely.
* $wgDocType and $wgDTD have been removed.
* $wgXhtmlDefaultNamespace is now ignored.
* XHTML5 will be output if $wgMimeType is set to an XML mime type (according to HTML5's rules).
* For backwards compatibility with extensions $wgHtml5 and $wgXhtmlDefaultNamespace are set
in Setup.php but depending on them is deprecated.
Change-Id: Iad9634e2ee420b5a3bbffe550421fde4fa1819b0
This hook allows extensions to disable or modify the new messages
alert ('orange bar of doom') while still allowing the user_newtalk
table to be updated.
The wgUserNewMsgRevisionId JS global allows gadgets and extensions
to create their own new message alerts on the client side.
I also threw in a few comment updates for good measure!
See also Echo change I3f35a56b which utilizes this.
Bug: 47962
Change-Id: I2105bdd2bcd5b27f6f36ec8d8fa7fa99d60a2d82
$userLimit was used inline in the message, causing an "array to string conversion"
notice and a mangled log entry.
Change-Id: I8c5199f1bf01b56e955d8d15c48061b5301b1745
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
This was an experimental authentication system intoduced a couple
of years ago with a pretty narrow use-case. It's been pretty much
ignored since introduction, and makes login more complicated than
it needs to be.
I didn't drop the external_user table on the off-chance someone
out there actually has data in it, but they should use AuthPlugin
for their external authentication needs.
Change-Id: I794338dbb75961ee033d41fa44bb7aa22e54f447
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3faa9c3e8107c6e46cdf21f8c18adda1f42890d7
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3e38b94d10600a60d2d4857de54307f34c4662c4
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
* Ran spell-checker over code comments in /includes/
* A few spellchecking fixes for wfDebug() calls
Found one very strange (NOOP?) line in Linker.php - see "TODO: BUG?"
Change-Id: Ibb86b51073b980eda9ecce2cf0b8dd33f058adbf
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
* The DB column has garbage padding as the default value, which
was intented to just be "". Since the the insert functions cast
the value to a string, inserting a user without creating a token
causes garbage to be inserted. The logic to automatically fix
empty tokens does not trigger. This fixes createNew() to set the
token and makes sure that addToDatabase() does.
Change-Id: I3529fe8afbc62bac37063217d5aa0179a4a6e169
* This is much more useful if it can be passed to new Date. As a side
effect, this means straight arithmetic comparisons can be done.
* Add a method for this to mediawiki.user (getRegistrationDate).
* Improve docs on server User::getRegistration method by documenting possibility that data is null.
Change-Id: Id7ae0faa930433876939b73d47fc294975e14fb1
* Do not allow working on Special:EditWatchlist
* Do not reset all notification markers
* Do not delete expired restrictions
Change-Id: I7a990c0a80b9c7a6340465dd082a110dafea8f14
Remove $wgUseDynamicDates and everything related to it.
I left DateFormatter::reformat() alone, since it might possibly be
used elsewhere, and to be honest I'm afraid to touch it.
Change-Id: I609db8471c14e5e5946916f085d2ee5b96204d81
Changed third parameter of PingLimiter hook to a
reference since that's what all the docs say and because
extensions need to be able to override the result of
the ping limiting.
Change-Id: Ia8e9d3c4de9a6f298a00949007cad53021ab782c
This allows to display the "password sent by e-mail." string in the user's language
since it's now in the action text rather than always in content language due to the
fact it was hardcoded in the log's comment.
Insertion of log entries for the new users log is now acomplished using the
ManualLogEntry class rather than the old LogPage one.
Removed 'newuserlog-byemail' message since it's no longer used (also checked
extensions in Wikimedia's Git repo).
IRC notifications will use the same message for 'create2' and 'byemail' for backward
compatibility. The only difference is that 'byemail' entries will no longer have
"password sent by email." in the comment.
Change-Id: Icdf1d714259d054cf8c256faf894c533be0dc73c
This happens when an anonymous user wants to create an account for himself through
the API. This is due to the fact that User::addNewUserLogEntry() was always using
$wgUser as performer, but the API does not replace $wgUser by the newly created user
object when the peformer is an anonymous user.
Changed User::addNewUserLogEntry() to directly take the log action as first parameter,
rather than a boolean value saying whether the password was sent by e-mail or not,
and force the performer to be the user itself in the log action is "create". This
avoids such problems in that case, no matter the value of $wgUser, and it makes this
parameter much more readable that the old one. Backward compatibility is maintained.
Creating an user and sending its password by e-mail will still log the performer's
IP address in the log if this is made by an anonymous user.
Finally the second parameter of the AddNewAccount is now correct when creating an
account from the API, it was always false previously.
Change-Id: I188ecf420b85e9d1dab6fb933ed50d5f58532109
Added the "resetkinds" option to action=options, so that when the
"reset" option is set, the user can control which kinds of options
are reset, rather than having to do all or none.
Also added documentation to the "change" parameter, since passing
it option keys without any "=value" after it will result in resetting
that specific option to its default value.
Change-Id: Id5bc1fffa0d487c0f152b79115205d2722f380d3
Before change I98df55f2 it was possible to set arbitrary preferences (ie.
with anything as the key) using the action=options API. That change
removed this ability by enforcing full validation of the preferences, also
introducing several regressions which were fixed by follow-ups.
Per the discussion on bug 40124, this changeset aims to restore this
ability, but in a slightly restricted way: arbitrary preferences' names
must start with userjs- prefix, to avoid any possibility of conflicting
with new MediaWiki versions or extensions.
The contents of these preferences is not escaped, sanitized nor validated
in any way; script authors are expected to sanitize them themselves to
prevent XSS attacks and other security vulnerabilities.
This commit also adds the User::getOptionsKinds() method (to determine
whether given preference keys are used by MediaWiki itself or an extension,
intended to be used via the API, or entirely unknown) and enhances the
User::resetOptions() method to allow for resetting only preferences of
chosen kinds.
These changes allow for fixing of Special:Preferences not to clear those
additional fields when saving user settings.
Change-Id: I5f9ba5b0dfe7c2ea5458d836f03429cf6d93969d
CentralAuth calls User::loadFromId() directly after calling setId().
This avoid having to load the object two times in this case.
Change-Id: Iade37631a9346dff45e18acfa078af37c1fbbfab
* migrateUserGroup.php: Call User::invalidateCache
* While at it, also fix the issue where User::clearInstanceCache
did not clear cache for User::getGroups.
Although it does clear the caches of methods used to calculate
other group-related lists (such as User::getEffectiveGroups),
the one for the query from user_groups was still cached in
$this->mGroups.
Presumably this was forgotten when this pattern was introduced
as the instance cache precedes the user_group table.
Change-Id: I22abdba00f8ccf587a3d7696e57970ed4653afc8
Eclipse and phpstorm where showing 'User' as return type before, which causes me to not check for false somewhere and thus fatals happening :)
Change-Id: Ibd5b5598f05e6b08481ad65060c7cae18762dc4e
I've fixed several PHP notices and the problem that rights returned
by User::getRights() might have duplicates if altered by a hook
(same for User::getEffectiveGroups).
Change-Id: Id92af387d8c09414076bac40e83052cd6f913f42
The link to the user contributions on Special:ListUsers weren't red
as the needed parameter for this wasn't set in the call to
Linker::userToolLinks and User::getEditCount returned strings while
it was supposed to return integers.
Change-Id: I8d5faaedefec02d309e3e9c2da80f135b44fa5f1
The bug has actually already been fixed, so this
patch just removes extraneous function calls and code in
User::getOption() and User::setOption(). It also adds
unit tests for user options (including a test for the
case provided in the bug report).
Change-Id: Idd8af9cf1a26a4adbde3ca71dde64539ecd0a207
Caching the result of User::getDefaultOptions as it always returns
the same data, despite for unit tests, which can't use the cached
values as they do evil things with variables being constant in normal
operation.
Change-Id: I02d557006d2f879e7ce510a5e47fa1543baab8a6
Made action=query&list=users use User::getRights() if
usprop rights given. This not only removes redundant
code, but makes it execute the UserGetRights hook, so
that this now includes rights given by Extensions (eg.
CentralAuth does that).
Patch Set 2: Modified the User class to be able to
inject further data into User::newFromRow() and using
that to inject the groups taken out of one SQL query
(for performance reasons). Furthermore I've split up
the query in ApiQueryUsers.php into one for user data
and one for the groups, to only have one row for each
user.
After all the perfomance of this should now be ok, not
extremly good, but bearable (though I couldn't test it
deeply, as I don't have much data in my CentralAuth
environment).
Change-Id: Ie5b2924abb82ac254c77e1d04cc4d5b308962dad
* Has to keep actual messages for IRC notification
* Catch really old log entries with no parameters and use an
appropriate message in that case to not always display erroneous
"X changed group membership for Y from (none) to (none)".
Change-Id: Ie188bc6fcdf672fe31f0f389a158aab6256031fa
(bug 41198) If clearInstanceCache() is to clear cached user data apart
from the data from the user table, as addToDatabase() expects, then
$this->mOptionsLoaded needs to be set to false. Clearing $this->mOptions
may reduce memory usage a bit, but is not sufficient.
Change-Id: I6912415dc154d06f62839a1ee777c2c3747253d6
User::edits() lets you fetch a cached number of edits from a slave database.
in case the field is not yet filed, we initialize if by hitting the `revision`
table and saving the result in user_editcount.
User::incEditCount() updates the edit countr and also does a lazy
initialization, if needed.
As both methods use the same $dbw->update() statement for this, I've
created a new, protected initEditCount() function which can take care of that.
Change-Id: If111270a84d4278bc4ea14d32ae602069f7c276f
Moved the logic from the old static User::edits() into
User::getEditCount() and deprecated User::edits() as it's
not following the class hierarchy.
Change-Id: Id2b939ffb903accb8f4dc132a6ac6b6576f81beb
Currently, if a user with Accept-Language: zh-tw header accesses a zh site,
the page contents are served in zh-tw variant, but the interface language
is zh (falling back to zh-hans) so the user is seeing interface messages
in zh(-hans) unless a &variant= is manually set (originally variant set in
URL is checked by getDefaultVariant).
There were debates that serving different languages based on headers from
the same URL breaks cache, but currently contents are served in different
variants based on headers and it works. So I assume this is not an issue.
PS2-4: HTTP header settings shouldn't affect user preference settings of
logged-in users.
PS5-6: Move code loading variant settings for anonymous requests from
User::getDefaultOptions() to User::loadOptions() to avoid pollution of
defaults. A visual bug of this is that if I have variant set to zh and
load index.php?title=Special:Preferences&variant=zh-cn, the dropdown is
shown as zh-cn because I was using the default value and now it thinks the
default value is zh-cn instead of zh.
PS7-8: Rebase to add dependency and tweak commit summary etc.
PS9: Remove the argument added to getDefaultVariant, which was intended to
keep B/C of getDefaultVariant (not to check headers by default).
Change-Id: Ie600ab24294a1add804875e921c32febe6ed645f
Created a new method User::groupHasPermission and check also
$wgRevokePermissions for the given right
Change-Id: I41edb091fa35c8c68b6f95cc5fd208ea99418cdb
Fix the DB error which comes from User::addToDatabase() if it is called
when the user already exists. This is the most common DB error we log at
WMF in normal operation, perhaps because of double clicks on the "create
account" button, or perhaps due to CentralAuth autocreation when
multiple pages on another wiki are opened in the browser simultaneously,
as the bug reporter suggests.
See the doc comment for the interface rationale. Patched
Special:Userlogin to be aware of the new return value. Most extension
callers will continue to work, I will patch a couple that need it in
subsequent commits.
Change-Id: I1f6ef5e6319bfe692fb82a3fa50dc66c9fde8f15
(After a question in r26457): Let User::clearInstanceCache
clear out the cached edit count as well, as a user session
can be open for a long time.
Change-Id: I4444f352e3b5df7b24f37668a5f1fbf9d64d6978
Rather than have separate calls to User::loadDefaults()
every time User::loadFromSession() fails, there is now just
one call in User::load() if loadFromSession() returns false.
This fixes the case where a UserLoadFromSession hook aborts
loading from session, leaving the User object uninitialized.
Change-Id: I8d1a114d7ec361b27b260791f742c473a1497f26
Signed-off-by: Tyler Anthony Romeo <tylerromeo@gmail.com>
* Added parameter to login link so that wpStickHTTPS
is set to true by default when the user is coming
from HTTPS.
* Added redirect in Special:Userlogin so that when
$wgSecureLogin is enabled it automatically redirects
to HTTPS.
* Adjusted User::setCookies() to add a parameter for
forcing secure/insecure cookies, and then added the
appropriate argument to Special:Userlogin so that
cookies are set appropriately.
Change-Id: I17ac68014840daa47bfd4768e978e9ff2edb00db
Sets a cookie on user login (removed on logout) if wpStickHTTPS
was checked, which causes the browser to get a redirect if they
visit the HTTP version of the site.
Change-Id: I60f44a1062a93d15198edae6674bb3310a148b2d
Allow AuthPlugin to determine if user passwords should be stored
locally.
* Released as part of 1.20wmf10, 1.19.2, 1.18.5
Change-Id: Ie41bed7ecf5390f8815128c227bae371880a6058
Last round of easy replacements. About 30 uses in core remain (outside of HISTORY
and GlobalFunctions::wfMsg*). I'll work with IAlex and Nikerabbit to work towards
getting rid of those, too.
Updated method documentation in a few places.
Change-Id: I2491c006b62a9cc183230e31a0bd96c91e5b6142
now it is shown and selectable on api (list=allusers&aurights=) and
Special:GlobalGroupPermissions (from CentralAuth)
Change-Id: I9464109c2d1648e5668e545b9c7109ced656f4d7
Follow up bug 5057, now it is shown and selectable on api
(list=allusers&aurights=) and Special:GlobalGroupPermissions
(from CentralAuth)
Change-Id: Ic7c57c8b29a385ad9c1ad8328ee08af758e3a4f7
Follow up bug 30636, now it should be shown and selectable on api
(list=allusers&aurights=) and Special:GlobalGroupPermissions (from
CentralAuth)
Change-Id: Id09d144f523c1ed687bd766945dbf9281e1d38c6
Follow up bug 13137, now it should be shown and selectable on
Special:GlobalGroupPermissions (of CentralAuth)
Change-Id: Iebdf0454ff3636585983b07eab3d2387f404498f
The 'beta' project uses DNS blacklist lookup to automatically block open
proxy and active spammers. This patch simply creates the new
'dnsblacklist' debug group so we can easily log the lookup result.
Change-Id: Idfc9fb2d3db4a0bb5387c76fdef07bf9e74eeff4
Previously, $wgDisableAnonTalk was only used as a visual
hack in includes/Linker.php. Now, if the variable is set,
no queries will be made to user_newtalk at all.
Change-Id: Id5521abbec7f05f2de7230f9f0316176abc7f215
Signed-off-by: parent5446 <tylerromeo@gmail.com>
This change adds a new permission ('deletelogentry') which is required to be able
to delete log entries.
It does not affect who can see deleted content.
Change-Id: I6b69919a1bdc502becc1ae4ac9169b8b0e85bfdc
Using User::getDefaultOption() in User::setOption() sets preferences like
'language' to the right default value, whereas using $wgDefaultOptions
sets the language to null because language is not part of $wgDefaultUserOptions,
but it is part of return value of User::getDefaultOption().
This only makes problems when reusing the same user object, because when
a new user object is created, the value of 'language' is correct.
Change-Id: I43a32c66fc3997a4f842c63af374e84d234602b2
When inserting XML elements inline <such as this one>, doxygen chokes
about it not being known. Simply enclosing the tag in double quotes
prevents doxygen from emitting a warning.
Also enclosed a few invalid functions calls such as \. and double quoted
the HTML entities such as &foobar;
Change-Id: I4019637145e683c2bec3d17b2fd98b0c50a932f1
* The problem is that Title::userIsWatching() relies on $wgUser,
which is not suitable on every case. Instead User::isWatched()
requires both an User and a Title object.
* Replaced all core calls from the former to the latter
* Added a cache in User for the WatchedItem instances so we do not
need to do a database request every time something want to know
whether a page is watched or not, which can happen several times
per request.
Change-Id: Ifa9c55b7ffb487ce6893c74df233eedc7654dc5e
Also pluralize properly.
"You have a new message from another user (last change)"
if only one unseen revision, or
"You have new messages [from another user|from N users|]
(last changes)" if there are several unseen revisions.
Contains a fix in Title::countAuthorsBetween() adding options to include
(one or both of) the delimiting revisions in the count.
Change-Id: I8870111802085d0bd188cb508c4f4b852985634d
I have created an API module for changing the preferences.
It allows resetting preferences (reset argument) and bulk changes
of preferences (change argument) in a format:
name1=value1|name2=value2
The change argument has a limitation imposed by the current API
implementation as it cannot accept | in values. There is
available a pair of arguments optionname and optionvalue, the
latter accepts values with |.
I have created optionstoken parameter in meta=userinfo to provide
a token. There is already preferencestoken there, but I would
like to have a consistent naming.
Change-Id: I0d6c654a7354ba77e65e338423952a6a78c1150f
If your salted password end up being completely numeric when
represented in hexadecimal (less than 1 password per 10 millions),
it is also possible to login by providing another password that only
matches the first 9 bytes (instead of the full 16 ones) if it turns out
to also be completely numeric with your assigned salt (which is completely unknown).
The odds of finding an equivalent password with such characteristics, over a double md5
with an unknown salt, are really low. Even if the attacker broke into the servers and
robbed the salts, making use of this property would require a preimage attack of a partial
md5 (2^18) with the output of another md5 hash, for which a full preimage would still be
needed. Breaking the hashes using conventional attacks would be easier, so this is not
a critical update.
Change-Id: I8d1153fb91ca6507bd1df91e9953561f74f12ef6
* Block::parseTarget() first called trim() on its parameter which was converting objects into string, thus making the checks for object and null useless; now trim() is called after these checks.
* User::getBlockedStatus() was passing $this->getName() to Block::newFromTargert() which in turn was passed to Block::parseTarget() where a new User object was created.
Instead of this, the User object is directly passed to Block::newFromTargert(), which avoids creating a new object for the same user.
Change-Id: Iffea21d4f53e8692072749264f7486c22b6be5fd
The error is "PHP Strict Standards: Creating default object from empty value in includes/User.php on line 2142"; the problem was that I forgot to renamed an instance of that variable while refactoring the code.
Change-Id: I4e32311693708ec5a0227d60f7818b374fccd4cc
* Much more easier to find it in the User class than in Preferences and it's general enough to be in that class.
* Rewrote the function for better readbility
* It now always return a Status object so that it's easier to interpret its result.
* Update the only caller in core (in Special:ChangeEmail) and moved the PrefsEmailAdit hook there
Change-Id: I55939bb5295e73594c3fdf7287dddbc16a233ce4
- MWCryptRand: A new api for generating cryptographic randomness for security tokens. Uses whatever cryptographic source is available and if not falls back to using random state and clock drift.
- wfRandomString - A simple non-cryptographic pesudo-random string generation function to replace wfGenerateToken which was written pretending to be secure when it's really not.
- Core updates to use MWCryptRand in various places:
-- user_token generation (to do this we stop generating user_token implicitly and only generate it when needed to avoid depleting the system's entropy pool by reading random data we'll never use)
-- email confirmation token generation
-- password salt generation
-- temporary password generation
-- Generation of the automatic watchlist token
-- login and create user tokens
-- session ids when php's entropy sources are not set
-- the installer when generating wgSecretKey and the upgrade key
* Made WatchedItem select wl_notificationtimestamp instead of "1"
* Added loading mechanism, accessor to wl_notificationtimestamp and method to reset that timestamp
This allows the entire user_token column to be regenerated after a leak by running `UPDATE user SET user_token = NULL;` and letting the user_tokens be regenerated as users try to log back in.
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from TalkpageView::show in /www/w/extensions/LiquidThreads/pages/TalkpageView.php at line 251] in /www/w/includes/GlobalFunctions.php on line 3520
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from MessageTable::contents in /www/w/extensions/Translate/utils/MessageTable.php at line 98] in /www/w/includes/GlobalFunctions.php on line 3520
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from TranslationHelpers::ajaxEditLink in /www/w/extensions/Translate/utils/TranslationHelpers.php at line 1186] in /www/w/includes/GlobalFunctions.php on line 3520
PHP Notice: Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from ThreadPermalinkView::getSubtitle in /www/w/extensions/LiquidThreads/pages/ThreadPermalinkView.php at line 153] in /www/w/includes/GlobalFunctions.php on line 3520
and maybe more
This is the wrong configuration format for such a feature, and the wrong interface. We already have certain per-namespace permissions in the Title class, and we didn't need to add extra formal parameters to a whole lot of User methods in order to get them. The feature should be implemented wholly in Title, and the concept of user rights should remain relatively simple and easy to understand, and independent of its many applications, i.e. a user either has a right or doesn't. Rights are just a tool for developing access policies; the complexity should be in the caller.
The revert was mostly done by hand, since there were a lot of conflicts. I tried to preserve the gist of conflicting changes in r102187 and r102873. The test changes are not simple reverts, rather I just edited out the per-namespace tests. I reverted the followups r92589 and r104310.
email address is removed
In Preferences::trySetUserEmail no point trying to reset the users email if it's the same
Same for User::setEmail
After setting the email though, invalidate email auth tokens
Add a UserDisplayName hook to allow extensions to give custom display names for users.
Add a $wgRealNameInInterface to use the real name of a user as the display name.
To start of the first use of the display name functionality tweak SkinTemplate to declare the userdisplayname and use it inside of personal_urls.
Added run of ConvertUserOptions maintenance script into update.php before dropping the column
Removed usages of user_options in code
Marked User::decodeOptions() deprecated as of 1.19.
Made ConvertUserOptions drop out early if the user_options field doesn't exist
Made ConvertUserOptions update user_options to '' after migration of user options to mOptions
It's necessary for User::loadFromRow() to set $this->mGroups to null, same as the calling code in User::loadFromDatabase(), so that they will be loaded dynamically when User::newFromRow() is called.
No bugs found that are caused by this but it couldn't hurt to have working accessors. Tested from eval.php.
