Last modified: 2014-04-09 06:12:30 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 2027 - Create AuthPlugin methods to capture every aspect of MW user object
Create AuthPlugin methods to capture every aspect of MW user object
Status: NEW
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-04-30 13:31 UTC by Carlton Brown
Modified: 2014-04-09 06:12 UTC (History)
3 users (show)

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


Description Carlton Brown 2005-04-30 13:31:40 UTC
At the present time, AuthPlugin's user validity checks are limited to testing 
whether the user exists, and testing whether the username and password combination 
is valid.  However, a MediaWiki user has other relevant states that can be mapped 
to the external authenticator - mBlockedBy, mBlockedReason, mRights.   

If the AuthPlugin:initUser method is used to set these attributes, the blocked user 
condition is set too late to be effective.  If these external checks are placed in 
AuthPlugin:authenticate(), only the "incorrect password" error is displayed to the 
user, even if the real cause was that the user was blocked.   

At a minimum, the change could include adding an AuthPlugin:isBlocked method which 
callers could use to set a "blocked" message.   

This does raise the question of whether to autocreate a user that is either banned 
or has special privileges.  I would probably say create the blocked user but 
disregard the special privileges.  Sysop promotion should be a rare circumstance 
with enough security consequences that it should be manual.
Comment 1 Quim Gil 2013-04-08 17:08:33 UTC
Daniel, could you help assess the current relevance of this old & uncommented enhancement request? Or maybe you know the right people to CC here. Thank you.
Comment 2 Daniel Friesen 2013-04-08 20:28:21 UTC
Well, we havent changed AuthPlugin much so it's probably still valid. Our auth plugin system isn't the most flexible.

Don't know who to cc.
Comment 3 Quim Gil 2014-04-09 06:12:30 UTC
Setting to Lowest to reflect the fact that nobody is working or planning to work on this.

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