ryan.lane wrote:

Can we get rid of checkPassword() in User.php altogether, or at the very least
move most of the password checking to a default authentication plugin? Also, it
would be nice if there were an optional argument for "domain" in the
authenticate() method.

I'm having problems thinking of a good way to code in my LDAP authentication
plugin without it knowing which domain to authenticate against. I could code in
a workaround hack, but it would be as dirty as my first implementation (which I
truly dislike). Also since processLogin() in SpecialUserLogin.php is using both
$user->checkPassword and the authentication plugin, I don't really see any clean
way that I could code this in (since i'm going to have to pass the domain to
both the plugin and $user-checkPassword or the User class).

john.varghese wrote:

I also noticed that $user->checkPassword is called ONLY when the correct
password is supplied. If I were to try to login with an incorrect password, it
shows me the msg for 'wrongpassword'. In that flow checkPassword is not called
at all. Only after I provide the correct password, checkPassword will be
called. At this time it seems to be superfluous, because somewhere earlier, I
have been authenticated already.

Also "global $wgAuth;" is declared twice in processLogin. It works fine with
just one declaration as well.

brosner wrote:

I wrote a custom auth plugin to authenticate users from an external database. I
have it setup to create a local account for that user since one is required to
store their preferences on the wiki. I also allow the users to change their
password on the wiki and it gets updated in the external database. This all
works, however, due to the encryption the password gets created with a time
based salt. This boots the user out of the forum software where the database is
being used.

The User::setPassword() call is made inside LoginForm::initUser() which really
should not call the $wgAuth->setPassword() call when just creating the user
account locally, but only when they change their password from the preferences
page. Or at least some way of determining when to update externally.

Auth plugin systems have been in active use for a couple years. IIRC password handling (mentioned in comment 3 above) has been changed since to work a bit better. If there are any current issues with the interface, file them as new bugs.