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.
This just lets you enter the database by hand in LocalSettings.php, for
testing. Now other people can actually test ExternalAuth without having
a vBulletin license. 23 lines not counting whitespace/comments/closing
braces, and took me ~20 minutes to write.
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.
