Last modified: 2010-05-15 15:33:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 892 - Authentication plugin interface
Authentication plugin interface
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.4.x
All All
: Normal normal with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 814 828
  Show dependency treegraph
 
Reported: 2004-11-16 05:41 UTC by Brion Vibber
Modified: 2010-05-15 15:33 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2004-11-16 05:41:01 UTC
I've checked in the beginnings of an authentication plugin interface; will 
need some more tweaking probably.
Comment 1 Ryan Lane 2004-12-21 19:54:36 UTC
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).
Comment 2 John Varghese 2006-03-09 23:59:45 UTC
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.
Comment 3 Brian Rosner 2007-03-11 05:08:35 UTC
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.
Comment 4 Brion Vibber 2008-12-30 02:45:31 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links