Last modified: 2014-04-09 06:12:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4027, the corresponding Phabricator task for complete and up-to-date bug report information.
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)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  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: ---


Attachments

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.


Navigation
Links