* Added function getPasswordValidity return error message on failure for the given unvalidated password input.
* Replaced isValidPassword() fn call to getPasswordValidity() in SpecialUserlogin.php
* hide some user settings if user is not allowed to send e-mail, but can receive e-mail
* update API 'cannot send e-mail' message
* FIXME: gives 'mailnologin'/'mailnologintext' as error. Error handling should be made more fine grained
. . . except not really. It works fine on Opera 9.6, except for the
slight detail that if you enter a password that's too short, Opera will
helpfully repeat your password back to you un-*ed when telling you it's
too short. Same in Opera 10.00 Beta 3. So the code is commented out,
and there are no functional changes. We'll need UA sniffing when the
code is uncommented. But I already wrote it, so may as well commit it
for future use.
This recycles the "passwordtooshort" message to provide the client-side
error message, using the title attribute on the input. Since the title
attribute might be displayed when the user hasn't actually entered an
invalid password, I've reworded it to not imply the user actually
entered an incorrect password, so it just states the requirement. (This
accords with the advice given in the HTML 5 spec.) I didn't make up a
new message name for that, because it's not a big deal if translations
do imply that the password is wrong, since that should theoretically be
the most common case anyway.
The number of edits doesn't correspond terribly well with "number of messages". Recommend leaving this for future when we actually have sensible message semantics.
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
* Tweak User::isValidPassword() and hook. Return a STRING msg key on failure, not false. Updated all callers to handle this
* Split too-short/match username errors for clarity
* Update docs, messages.
* Merge fix for bug from maintenance-work branch
* Remove the unused UserrightsChangeableGroups hook introduced in r39368 (1.14)
* Fix typo in Special:ListGroupRights introduced in r52083
* Prevent duplicate key display in Special:ListGroupRights (new behavior: if a permission is both assigned and revoked from a group, it only displays as revoked).
* Fix $wgRevokePermissions handling, it now runs after every group permission has been assigned in order to revoke the permission properly.
