AuthManager::autoCreateUser() causes createAndPromote.php to give error
"Automatic account creation is not allowed." when
$wgGroupPermissions['*']['createaccount']=false is set. Anonymous user
checks should be skipped for maintenance scripts.
Change-Id: Ib61889a758e542abe991707d8b7853a25cfed8e9
So far, our key derivation code assumed that it has control over
the salt used by the derivation routines, however I want to add Argon2
support and it doesn't work this way: password_hash() generates the
salt itself, and the only way to verify a password is by using
password_verify(). Current way the things are done doesn't support it
because it relies on the result of password hashing with parameters we
provide to be deterministic.
Therefore, I'm deprecating Password::equals(), as well as whole concept
of comparing Password objects - it's used only in tests anyway. It's
getting replaced with verify() that only accepts password strings.
Uses of old function are fixed with exception of a few calls in tests
that will be addressed in my Argon2 patch.
Change-Id: I2b2be9a422ee0f773490eac316ad81505c3f8571
Use AuthManager::autoCreateUser when creating a new user via
createAndPromote.php so that configured AuthManager providers have
a chance to perform validations and extra actions beyond local account
creation.
Bug: T212689
Change-Id: I4972507bbaf65bb542934c281c37bd8a5c7a26b7
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
Authentication audit logs should indicate whether a login is via the
normal password or a bot password (and which one). For failed logins
it could be included in the error message, and it usually is, but
for successful ones there is no message, so we'll send the app ID as
a new AuthManagerLoginAuthenticateAudit parameter.
Bug: T194338
Change-Id: I8aab48177b81a8e80dae118e6476a8f6a32089f1
Depends-On: Id482d2e2205960a0facd334e456d3a23bcad0ece
Updated unit tests as well for AuthManagerTest::testContinueAccountCreation()
and AuthManagerTest::testContinueAccountLink().
Change-Id: I96363e34688517796c2812cb3f483e1bfa26be6b
$user->getId() returns an int and it's strict on this,
so the check here should be an identical check as "=="
does unnecessary coercion. So "===" will be faster and
improves on speed/performance.
Change-Id: I28a4e86ab339f10251df8846b8d951b673fe4f9e
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
Instead of having basically every caller do:
$pf = new PasswordFactory();
$pf->init( RequestContext::getMain()->getConfig() );
Just create a single PasswordFactory via MediaWikiServices and pass that
around. Things that want to use their own config can still pass settings
via the new constructor.
This will eventually let us remove the init() function, removing the
only hard dependency upon MediaWiki, to make it easier to librarize
(T89742).
Change-Id: I0fc7520dc023b11a7fa66083eff7b88ebfe49c7b
There's a difference between addition of credentials, which doesn't
need to invaliate BotPasswords, and changing or removal of credentials,
which does.
It seems most straightforward for the caller of
AuthManager::changeAuthenticationData() to know which is intended, so
let's add a flag there.
Bug: T199809
Change-Id: Ib8405734e605b94f3f0b66596ad95784cb365e4f
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
`$a <=> $b` returns `-1` if `$a` is lesser, `1` if `$b` is lesser,
and `0` if they are equal, which are exactly the values 'sort()'
callbacks are supposed to return.
It also enables the neat idiom `$a[x] <=> $b[x] ?: $a[y] <=> $b[y]`
to sort arrays of objects first by 'x', and by 'y' if they are equal.
* Replace a common pattern like `return $a < $b ? -1 : 1` with the
new operator (and similar patterns with the variables, the numbers
or the comparison inverted). Some of the uses were previously not
correctly handling the variables being equal; this is now
automatically fixed.
* Also replace `return $a - $b`, which is equivalent to `return
$a <=> $b` if both variables are integers but less intuitive.
* (Do not replace `return strcmp( $a, $b )`. It is also equivalent
when both variables are strings, but if any of the variables is not,
'strcmp()' converts it to a string before comparison, which could
give different results than '<=>', so changing this would require
careful review and isn't worth it.)
* Also replace `return $a > $b`, which presumably sort of works most
of the time (returns `1` if `$b` is lesser, and `0` if they are
equal or `$a` is lesser) but is erroneous.
Change-Id: I19a3d2fc8fcdb208c10330bd7a42c4e05d7f5cf3
Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
These comments do not add anything. I argue they are worse than having
no comments, because I have to read them first to understand they
actually don't explain anything. Removing them makes room for actual
improvements in the future (if needed).
Change-Id: Iee70aad681b3385e9af282d5581c10addbb91ac4
This is meant for private wikis where the list of users may
be secret. It is only meant to prevent trivial enumeration
of usernames. It is not designed to prevent enumeration
via timing attacks.
Bug: T134100
Change-Id: I7afaa955a4b393ef00b11e420709bd62b84fbc71
If a user being auto-created is blocked from account creation without a
reason given, CheckBlocksPrimaryAuthProvider is triggering a
"User::loadFromSession called before the end of Setup.php" log message
when trying to fill in a reason using 'blockednoreason'.
In this situation, use the content language instead.
Bug: T124367
Change-Id: Id94c919cdba5e4218b709ba8ac9d0fa17f0c3f8e
UserGroupsChanged is called in Special:UserRights with seven args
The caller in User.php only has five
Change-Id: I221da323c79bb8da0113533d01b429249d15e7de
Before this commit, the reason set in the global $wgReadOnly was differently handled
on different special pages. While on most of them, like Special:Upload, the reason
is allowed to have HTML, which can be used in Wikitext, too, Special:CreateAccount
always outputted an escaped version of this reason.
Most special pages uses the ReadOnlyError exception to print a read-only error,
however, AuthManager uses Status objects to communicate between the backend and the
frontend. Therefore the same message and parameters were wrapped in a Status object
and, in the frontend, directly passed to the constructor of ErrorPageError. Unfortunately,
Status::getMessage() escapes the parameters of a message, which is the reason, why the
wiki is read-only. To bypass this restriction, AuthManager now creates a Message object
directly, does not escape the reason, and uses the resulting object to create a Status
object from.
Now the reason is not escaped on Special:CreateAccount anymore, like on most other
special pages.
The read-only message on the protection form is, also before this commit, not escaped and
already displayed correctly, as the read-only is checked in the constructor of the
protection form already and, if the Wiki is read only, handled as a permission error and
already displayed correctly. This commit fixes the behavior of WikiPage in case of it's used
somewhere else, subclassed or if the check in the frontend will be removed and the Status of
WikiPage will be used.
Bug: T157036
Change-Id: Idbfe556fcb90f8bda8fae9d728ca9dee5ea02f67
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
