Last modified: 2011-04-07 22:02:55 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 T30328, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28328 - Hide Special:Resetpass for users if they don't have a valid password hash in db and no AuthPlugin is being used
Hide Special:Resetpass for users if they don't have a valid password hash in ...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
1.18.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-30 10:57 UTC by Liangent
Modified: 2011-04-07 22:02 UTC (History)
3 users (show)

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


Attachments

Description Liangent 2011-03-30 10:57:35 UTC
Maybe also give them a more friendly error message on log in.
Comment 1 Chad H. 2011-03-30 12:12:08 UTC
In what scenario would this happen?
Comment 2 Liangent 2011-03-30 12:26:15 UTC
(In reply to comment #1)
> In what scenario would this happen?

An extension creates users and doesn't assign them passwords, then log them in with ->setCookies() or something.
Comment 3 Andrew Garrett 2011-03-30 12:27:04 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > In what scenario would this happen?
> 
> An extension creates users and doesn't assign them passwords, then log them in
> with ->setCookies() or something.

I think that that extension should then be responsible for giving the user a way to authenticate.
Comment 4 Liangent 2011-03-30 12:32:30 UTC
(In reply to comment #3)
> I think that that extension should then be responsible for giving the user a
> way to authenticate.

But if user go to Special:Resetpass or Special:Userlogin they keep saying "incorrect password" even there can't be a "correct password".
Comment 5 Chad H. 2011-03-30 12:42:19 UTC
Creating a user without creating a password is the extension's fault. user_password should *not* be empty, unless you're using an AuthPlugin or similar.

Which extension is doing this?
Comment 6 p858snake 2011-03-30 13:14:37 UTC
I'm going to INVALID this, This is a issue with a extenstion compared to with MediaWiki. We don't even allow user accounts to be created without a password, the db is in NOT NULL mode for the password feild ([[User_table#Schema_summary]])
Comment 7 Liangent 2011-03-31 03:50:14 UTC
User::createNew says (in its doc) "- password The user's password. Password logins will be disabled if this is omitted.". So it's accepted that users with password login disabled exist, but this status is not reflected in Special:Resetpass and Special:Userlogin (and maybe Special:Preferences and Special:Specialpages because they give links to Special:Resetpass).
Comment 8 Brion Vibber 2011-04-07 22:02:55 UTC
In this case (no password set on creation, no auth plugin), the user has no way to log in until a password has been set -- so they can't go to Special:ResetPass etc.

The most common example of this case is user accounts created by another logged-in user, with a new password reset code sent via email. Until they log in with the reset code, they don't have a password and can't actually log in directly.


If your extension is customizing authentication in order to log people in via cookies, then it needs to implement the AuthPlugin interface -- it can then tell the system that passwords don't make sense by returning false for its allowPasswordChange method().

There may be a case where you could be logged in with no local password set, but there is some way to reset local passwords, but offhand not sure.

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


Navigation
Links