#32589 closed task (blessed) (fixed)
New Password Change UI
Reported by: | markjaquith | Owned by: | markjaquith |
---|---|---|---|
Milestone: | 4.3 | Priority: | normal |
Severity: | normal | Version: | 4.3 |
Component: | Administration | Keywords: | has-patch ux-feedback |
Focuses: | Cc: |
Description
https://make.wordpress.org/core/2015/05/11/the-plan-for-passwords/
This is a tracking ticket for the new password changing UI, which I'm converting from a plugin into a patch.
Attachments (28)
Change History (97)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#5
@
9 years ago
Do we want to add this to the add new user page as well? Maybe we should just generate a pw and send them a link to set their own password. Another option is that if the password is set via the new UI we could still email that to them(although I do not want to send them a plain text password).
#6
@
9 years ago
32589.3.diff moves the focus to the end of the input. It also adds focus when the show/hide button is clicked.
#7
@
9 years ago
32589.4.diff adds the password UI to user-new.php. It also removes send password by email checkbox. I needed to edit the js a bit to make it work on both pages.
This ticket was mentioned in Slack in #core-passwords by mikehansenme. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
9 years ago
#15
@
9 years ago
Thumbs up for better security. Any plan for making two-factor auth with Google Authenticator a checkbox to activate, and build the function into WordPress Core?
#16
@
9 years ago
Has there been discussion on what to do with initial user password creation on install.php?
Seeing some weirdness there, assuming from some of these changes.
gif of issue: https://cloudup.com/ivtVbcTH_-E
#19
@
9 years ago
We should probably deprecate wp_get_password_hint()
if we don't want to keep it around.
#20
@
9 years ago
Forums comment - https://wordpress.org/support/topic/password-generator-only-on-load?replies=1&view=all
tl;dr - If you delete the password, there's no way to generate a new one.
- Go to your profile page.
- Click 'Generate new password'
- Delete the value.
Ooops. :D All you can do there is reload the page to get the generate button back.
This ticket was mentioned in Slack in #core-passwords by mikehansenme. View the logs.
9 years ago
#23
@
9 years ago
I was wondering if it would make sense to shorten the generated password a bit. Thinking of the psychology of the matter, if a user sees something like this: 0pN#i%dhaDcD0HIn3KiCgE$W I think s/he is much more probable to think "that's way too much", delete it, and enter a weak one.
Perhaps if the generated password was something like this: 0pN#i%de it would be less intimidating. This is still measured to be a strong password, perhaps this would increase the adoption rate of random passwords?
#24
follow-up:
↓ 26
@
9 years ago
Maybe we should just put a filter for the length so it can be changed.
#26
in reply to:
↑ 24
@
9 years ago
Replying to MikeHansenMe:
Maybe we should just put a filter for the length so it can be changed.
I don't think this would solve the issue since it would only make default passwords shorter if a plugin hooks into it, kind of defeating the purpose - although regardless - a filter may be useful.
I don't see how anyone not using a password manager would go with 0pN#i%dhaDcD0HIn3KiCgE$W, but KiCgE$W may be short enough to work.
#27
follow-up:
↓ 28
@
9 years ago
When suggesting a filter I was not saying we could not change the default to also be shorter. Just that if we make it shorter some people will want longer. One thing to consider also is that this shows on three screens at the moment but one is the install screen, which no plugins will be active. Uploading screenshots now.
#28
in reply to:
↑ 27
@
9 years ago
Replying to MikeHansenMe:
When suggesting a filter I was not saying we could not change the default to also be shorter. Just that if we make it shorter some people will want longer. One thing to consider also is that this shows on three screens at the moment but one is the install screen, which no plugins will be active. Uploading screenshots now.
Ah, fair enough, my mind must have been somewhere else :) Thank you :)
#29
@
9 years ago
- Keywords needs-screenshots removed
on mobile-2 and mobile-3 you can see the inputs go off the page. I am going to get a patch worked up to fix that but is should be an easy fix.
#30
@
9 years ago
There are a few more screenshots on this post: https://make.wordpress.org/core/2015/07/08/today-in-the-nightly-customize-in-the-toolbar-passwords-ui-list-tables-on-phones-dashicons/
I'm hoping to vizrec a few password flows on make/flow.
This ticket was mentioned in Slack in #core-passwords by mikehansenme. View the logs.
9 years ago
#32
@
9 years ago
I tested regeneratepw.patch and could not get it to work on my local copy of trunk. I will dive in some to see if I can locate the problem.
This ticket was mentioned in Slack in #core-passwords by mikehansenme. View the logs.
9 years ago
#39
@
9 years ago
In 32589.5.diff:
- Include dashicon css on install page, fixes missing icon issue
- add check for
WP_INSTALLING
inwp_rand
function, preventing some PHP warnings when transients used before db set up - tested patch, works well in initial testing
This ticket was mentioned in Slack in #core-passwords by mikehansenme. View the logs.
9 years ago
#43
@
9 years ago
- Keywords ux-feedback added
The installation flow with the new Passwords UI needs more work, specifically around not making an admin hit the lost password link right after installation.
Hiding the password behind a button may work when you create a new user, but when you first set up your site that step feels unnecessary and confusing.
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
9 years ago
#48
@
9 years ago
Hi Team,
I have been waiting a long time for an update on how passwords and registration is handled so thanks for getting to this.
My questions is how will these changes work with sites using themes and "subscriber" type accounts. Will those accounts be sent an activation link to complete the registration process?
Thanks. Hope to get a bit more clarification on the new process.
This ticket was mentioned in Slack in #core-passwords by boren. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by obenland. View the logs.
9 years ago
#52
@
9 years ago
A few thoughts here, with an imminent patch:
.pw-weak
and.pw_weak
appear to be used interchangeably on inputs betweenuser-new.php
,user-edit.php
andinstall.php
- The "Confirm weak password" labels wrap the checkbox and also include a
for
attribute. This needs to be one or the other, or else the<label>
isn't clickable. I recommend removing thefor
attribute in this case, since the mark-up is already wrapped, and it's already committed in one place. - The UX is lacking a "Cancel" button to "Hide" the generated password. What if I generate a password, but want to update my profile but not my password? Should I lose those changes?
- When leaving this page after having generated a password, there is no "Are you sure you want to leave?" style prompt to tell the user: "Hey, you generated a password but you didn't actually save it yet, even though you clicked a fancy button" interaction.
- There is no indication to the user that their password was actually changed, or if there are any repercussions. Did it log me out of my other sessions? Can I reuse my old password again?
#53
@
9 years ago
32589.8.patch includes the following fixes:
- Finishes
pw-weak
vs.pw_weak
cleanup started in r33246 - Adds a "Cancel" button to the right of the "Hide" button to allow a user to cancel the generated password change
- Introduces a
beforeunload
warning if the user started changing their password but never saved the page
It also strongly suggests separating out the "New Password" and "Sessions" table rows into a new table with a new heading, and recommends updating a few strings for what I feel is greatly improved clarity of what these functions do.
- Passwords and Sessions do not belong under the "About Yourself" section
- Change "Generate new password" to "Generate Password" -- you can't generate an old password, right?
- Change "Log Out of All Other Sessions" to "Sign-out Everywhere" -- what's a session? How did I get one? Do I need it? Why would I do this?
- Change hokey
label to "Sessions" -- what's a session? See left and below. Settings, fields, & descriptions follow a logical left/right/down flow, whereleft
defines the setting,right
is the setting to toggle, andbelow
is any additional description. Let's continue that paradigm in this area also, even though the buttons break it slightly
In my opinion and experience using this new, very awesome and welcome feature, these UX tweaks are absolutely necessary to making this a finished and shippable product. It also begins the long process of creating division between a user's "profile", their "options", & their "account" which I think has always been lacking in this screen.
Sorry for being so late to this ticket and with this feedback. If there are questions or revisions, please ping here or on Slack, and I'm happy to rush any fixes in to get these into trunk ASAP (if it's not too late in beta already.)
@
9 years ago
Same as 32589.9.patch but clarifies the description
string, and uses "Log-out" vs. "Sign-out" even though I'm bias the other direction
#55
follow-up:
↓ 56
@
9 years ago
Changes to visuals should be communicated visually with screenshots on this ticket and visual records on make/flow. Changes affecting our most important threshold flows should be accompanied by some visual oxygen.
https://make.wordpress.org/flow/tag/passwords/
Not everyone is a developer or energetic enough to patch a local dev environment just to get a peek at ui changes. Throw some screenshots on the ticket to accompany patches. Taking screenshots while testing is not too burdensome.
#56
in reply to:
↑ 55
@
9 years ago
Replying to ryan:
Not everyone is a developer or energetic enough to patch a local dev environment just to get a peek at ui changes. Throw some screenshots on the ticket to accompany patches. Taking screenshots while testing is not too burdensome.
I understand, and appreciate the nudge. I omitted them earlier to avoid inundating everyone's inbox with notifications, and felt my comments were descriptive enough & the code changes small enough to read in trac for anyone that was interested, not to be inconsiderate of anyone's preference for viewing suggestions.
I've now attached 3 screenshots of what the applied patch looks like when applied to trunk:
- 1 highlights string changes & the addition of the "Account Management" heading
- 2 highlights the new "Cancel" button after clicking the "Generate Password" button
- 3 highlights the string used when navigating away from the page after having generated a password without saving the changes
#57
@
9 years ago
I noticed there's a responsive gap, between 768
and 782
pixels of width, where the "Hide" button (and consequently my new "Cancel" button patched above) end up floating between the input box and the strength indicator. Screenshot imminent.
- Less than
768
and the "Hide" button becomes an eye dashicon in the textbox - Greater than
782
and the "Hide" button has enough room to fit to the right of the textbox
#59
@
9 years ago
@johnjamesjacoby There is a lot going on in your patch. It would probably be best to break out the changes to titles and sessions into new enhancement tickets and focus on the Password things for now.
If you separated out the pw-weak
changes too, I could get those in early and leave the introduction of a cancel button for @markjaquith to decide on.
#60
@
9 years ago
@obenland Will do ASAP. Even though they're enhancements, I think they're necessary for 4.3 which will mean getting them in before string freeze, hence my rushing through to patch them all at once.
#61
@
9 years ago
From the forums
However, in WordPress multisite, when a user signs up via wp-signup.php, then an activation e-mail is sent. After clicking the link in this e-mail, the user receives a second e-mail containing his password in plain text.
Do we have a separate ticket for this, or are we not tackling Multisite yet? I haven't sat and tested it all on Multisite yet, which is my bad too.
#63
@
9 years ago
I'm seeing an issue where using weak password is not working. I've created a screencast of this happening.
Basically, during installation supply a username, a weak password, confirm the use of a weak password, and click Install WordPress. When the screen refreshes, it shows a generated password and doesn't use the weak password I provided.
Screencast here: http://cl.ly/230g1u2W0R1Q
#64
@
9 years ago
With a hat tip to @mindctrl for noticing this one as well, we should get rid of this notice:
http://cl.ly/image/1Y3R0W2r2g0B because if you're using an autogenerated password, the link will take you to the password page to generate another random one that could be even harder. I think it should either be removed, or reworded to just say "change it" and drop the "easier to remember" since random is now the default.
#65
@
9 years ago
In addition to the above:
- Go to profile page
- Update password to something weak and confirm use of weak password
- Update profile
- Log out
- Try to log in with new password. Doesn't work.
- The old password still works instead.
#66
@
9 years ago
@mindctrl — there was a bug in the latest beta. fixed here: r33384. Try testing again in trunk.
Converted to a patch.