Now is the whole class name, not a suffix. This allows you to do things
like $wgExternalAuthType::someStaticMethod() instead of having to fiddle
with temporary variables.
This will obviously break anything that has $wgExternalAuthType already
configured, so if that's anyone but me, make sure to fix your configs.
This is still experimental.
* ExternalUser::getLocalUser() from r56683
* Documentation and style tweaks for HTMLForm from r56682
* HTMLForm::add{HiddenField|(Pre|Post|Header)Text|Button}() functions, from 56782 and r56896.
Frontend stuff will wait until after 1.16 is branched.
* Login doesn't attach to session properly, so can't stay logged in!
* Password field shown in plaintext!
If it just DOESN'T WORK please keep it on a work branch, don't put it in trunk!
Reverted:
r56682
r56683
r56684
r56686
r56688
r56696
r56699
r56702
r56703
r56704
r56782
r56896
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.
