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
