Talk:Password reset

Ideas and comments

Regarding Jared's redesign proposal and general improvements we might make...

• Obviously the blocker for accepting the redesign is converting all of mediawiki.ui to conform to the Flow updated style. I doubt this is going to happen quickly, and we need to work out points of disagreement like the blue input area highlights.
•  Done Do we really need a cancel button? Since cancel would probably only clear the fields, this seems strange.
• I like the move to placeholders for sure. The labels we currently have take up more space and feel cluttered.
•  Done On the mailing list, we discussed combining the two fields in to one, labeled as "Username or email address". Users do not have to enter both: they can enter a username or an email, so it's confusing to have two fields. I really think this could improve usability, but there is potentially a technical hurdle in validating both email or username in a single field. Also note that if you're logged in, the form will autofill your current username. One alternative could be having a single field, with a required radio button to choose username or password. This we could potentially do without needing the rest of the redesign of the mediawiki.ui controls and vform style in place.

Steven Walling (WMF) • talk 01:48, 18 October 2013 (UTC) CC: Jaredzimmerman (WMF), S Page (WMF), Superm401

I'm also not sure how Cancel is meant to work, and I don't know any other forms on the site (or most other sites' reset forms for that matter) that have it. Re placeholders, we need to make sure it has very broad browser support, since login and signup are critical functionality. It doesn't have to look great in old browsers, but it has to work (and that includes seeing which field is which). gerrit:65871 is probably still relevant, though I haven't worked on it recently. Superm401 - Talk 03:49, 18 October 2013 (UTC)

I made the *quick* mock-up before i was aware we only needed one or the other (as I mentioned via email the text about only needing one of the other isn't obvious right away) so I think we can do a better job than what I made in 10 minutes just by applying agora control styles.

• Do we know the frequency of password resets by logged in users?
• Can we detect if the input is a valid email vs something else (lets assume a user name) i.e. can a user name be some.thing@something.abc.ab?
• Can we check both username and email and only ask if there is a dual match e.g. input matches both a user name and email address which is not the same account
• If we allow multiple accounts with the same email address, what do we currently do?
• How do we handle if a user name with no associated email address is entered?
• At what point do we validate the input? does the user have to submit the form before we attempt to validate the input, is this an actual tech limitation?
• Is there any security issues with prepopulating the form with the logged in users name?
• When a password reset email is sent does the users password actually reset unless action is taken from the email?

Jaredzimmerman (WMF) (talk) 06:03, 18 October 2013 (UTC)

@Jaredzimmerman (WMF): Yes, you can spot an e-mail address (ish) as a username can't have an "@" in it. Jdforrester (WMF) (talk) 17:47, 18 October 2013 (UTC)

Jdforrester: Err, "ish" indeed. There are plenty of pre-existing usernames that contain an "@"; for example, the English Wikipedia administrator w:en:user:@pple. My very rough count says that there are about 28,200 accounts on the English Wikipedia that contain an "@" and about 39,900 global accounts that contain an "@". --MZMcBride (talk) 18:37, 18 October 2013 (UTC)

One further quick note: if you limit usernames containing an "@" on the English Wikipedia to only users with more than 50 edits, the number drops to 186. --MZMcBride (talk) 18:41, 18 October 2013 (UTC)

@MZMcBride: Oh dear - "@" is meant to be a banned character for usernames. Did the code for that get added later? Jdforrester (WMF) (talk) 18:51, 18 October 2013 (UTC)

Jdforrester: From what I can tell, "@" was formally banned (in a hardcoded fashion) from usernames in rev:16658 (September 2006). The implementation was later changed to the global configuration variable $wgInvalidUsernameCharacters in rev:48765 (March 2009). --MZMcBride (talk) 18:58, 18 October 2013 (UTC)

@MZMcBride: Lovely. :-( Thanks for the investigative work; we may need to force those accounts to be renamed given that other code assumes "@" is an invalid username character. But that's rather a big change to force on (admittedly a small pool of) users, and is outwith the context of this page. Jdforrester (WMF) (talk) 19:06, 18 October 2013 (UTC)

┌─────────────────────────────────┘
@Jaredzimmerman (WMF): the second iteration looks good. To answer your questions not already addressed...

• Do we know the frequency of password resets by logged in users? No, I don't think so.
• Can we detect if the input is a valid email vs something else (lets assume a user name) i.e. can a user name be some.thing@something.abc.ab? Yes this is not hard I think
• Can we check both username and email and only ask if there is a dual match e.g. input matches both a user name and email address which is not the same account Answered above
• If we allow multiple accounts with the same email address, what do we currently do? I don't know, need to check.
• How do we handle if a user name with no associated email address is entered? It throws an error: "There is no email address recorded for user "WMF Test Account 049f00"."
• At what point do we validate the input? does the user have to submit the form before we attempt to validate the input, is this an actual tech limitation? Input is validated after submission. Since we don't have a clientside validation tool that's handy, I have no idea how hard it would be to build one. In this case, I think it's probably out of scope for now.
• Is there any security issues with prepopulating the form with the logged in users name? Not to my knowledge. This only happens when the user is already logged in and visits password reset.
• When a password reset email is sent does the users password actually reset unless action is taken from the email? Password reset emails you a temp password to use that works for seven days. It does not actually reset your password, and your old password will continue to work. This negates abusive use, where I enter in someone else's username to reset their password unbeknownst to them.

I think the style of error you provide works whether the validation is pre or post submission, BTW. Steven Walling (WMF) • talk 21:26, 18 October 2013 (UTC)

Action Items

• Create bug to extend user name validation to match user name or email

  Does this mean allowing them to enter the username and email in the same field? They can already reset based on either, just in different text fields. Superm401 - Talk 12:37, 23 October 2013 (UTC)

• Create bug to asynchronously validate prepost client-side user input

  Bug 56025 - "AJAX validation of username for password reset" - Validating email addresses would be a major privacy change (not in the scope of the bug). It would reveal whether a particular email has an account, which we probably don't want. Superm401 - Talk 00:20, 23 October 2013 (UTC)

• Contact users with usernames that are not valid based on current rules
  • Is this referring to potential usernames with an '@' sign (not sure if there are any)? Superm401 - Talk 00:20, 23 October 2013 (UTC)

    I now see from above that there are. Superm401 - Talk 00:24, 23 October 2013 (UTC)

  • Partner with Admins to fast-track user name changes
  • If all users will not change usernames to valid names amend bug to include validation for these user names
• Investigate current process for password reset when email matches multiple accounts

  It just sends you a list of all of them. Superm401 - Talk 00:20, 23 October 2013 (UTC)

• Create bug to send site-wide notification (echo?) to users without email associated with account 1 month after account creation (if no email exists on account) to remind them that their account will be unrecoverable if their password is forgotten. (wording TBD)

  Bug 56028 - Notification to users without a confirmed email a month after signup. Superm401 - Talk 00:20, 23 October 2013 (UTC)

• Create bug to add additional methods of account retrieval, e.g. SMS, security questions, secondary email, etc)
  • Contact Twilio (or similar) to see about SMS service donation or discount? Jaredzimmerman (WMF) (talk) 04:53, 21 October 2013 (UTC)

    We don't collect phone currently. We also don't want to depend on a proprietary outside intermediary, particularly for critical functionality like password reset. However, there may be a way we can do it directly, such as through the carriers' public SMS-to-email gateways. Superm401 - Talk 00:20, 23 October 2013 (UTC)

I added a couple bugs, and replied above. Superm401 - Talk 00:20, 23 October 2013 (UTC)

Requests for comment

This page discusses the past, present, and future of the password reset form. It feels very much like a requests for comment (RFC), unless you're... not seeking feedback? What's the purpose of this page, exactly? Who is its intended audience? I'm strongly reminded of a similar page in which the "unclear audience" problem was discussed, though I'm failing to remember which precise page that was. --MZMcBride (talk) 04:27, 18 October 2013 (UTC)

An RFC is about resolving design and architectural questions for MediaWiki as a whole. The page as clearly described is about documenting what we might like for Wikimedia projects, and we're not asking people to comment. We're just documenting what we're working on in our few spare hours, so that it doesn't drift away in email threads on the design mailing list. Steven Walling (WMF) • talk 06:55, 18 October 2013 (UTC)

"Seeking consensus has always been a key part of [...] MediaWiki." I don't see how you can appropriately propose design changes without seeking feedback. --MZMcBride (talk) 18:27, 18 October 2013 (UTC)

Email new pasword button

Not sure if this is the right place (probably could have filed the bug myself....) but anyways the Email new pasword button needs to be wider to accommodate translations (long text) in other languages like in ilowiki and eswiki--Lam-ang (talk) 16:46, 25 October 2013 (UTC)

@Lam-ang: Thanks for reporting this. The solutions can be increase the width of the button, or shorten the button text in those languages. I've filed bug 56194 so we can track this issue. Steven Walling (WMF) • talk 21:36, 25 October 2013 (UTC)

German mediawiki Version 1.22.6

This function does not work on my wiki at rockinberlin.de, which is a closed wiki. Does anyone have an example which variables are to be set in the LocalSettings.php to make this work?

Thanks for any hint

Th--[[User:Bmrberlin| Bernd M.]] (talk) 08:33, 24 November 2014 (UTC)