![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 16 years ago
Closed 14 years ago
#13351 closed defect (bug) (fixed)
Auto-generated Password Nag
| Reported by: | battis | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.5 |
| Component: | Administration | Version: | |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: |
Description
Whenever I log in, I am warned that "You’re using the auto-generated password for your account. Would you like to change it to something you’ll remember easier?" -- even after having changed my password (and clicked the link to "No thanks, do not remind me again")
This appears in WordPress 3.0-beta2-14550
Attachments (1)
Change History (6)
#1
@
16 years ago
- Component General → Administration
- Keywords reporter-feedback added
- Milestone Unassigned → 3.0
#2
@
16 years ago
- Milestone 3.0
- Resolution → worksforme
- Status new → closed
Just tested this, Both changing the users password and clicking the dismiss option appears to be working correctly for me.
If you experience this on a clean install, please re-open with any specifics on the environment/configuration of WordPress you are using.
#3
@
14 years ago
- Resolution worksforme
- Status closed → reopened
- Version 3.0 → 3.4.1
Just had this happen twice with two fresh installs from trunk (3.5-alpha-21499) on a local XAMPP box.
Here's the install process I followed both times:
- create a new directory inside my server path
- checkout http://core.svn.wordpress.org/trunk
- create a new DB
- edit wp-config.php
- 5-minute install (more like 5 seconds these days!)
- default user ('admin')
- get the auto-generated pwd message. Copy the pwd
- log in with auto-generated pwd
- get the nag
- click the nag to go to profile
- change the password
- this logs you out
- log in with the new password
- nag is still there.
#4
@
14 years ago
- Keywords has-patch added; reporter-feedback removed
- Milestone → 3.5
- Version 3.4.1
The latest bug was introduced in [21376].
Now that get_userdata() returns existing data for current user, default_password_nag_edit_user() compares the old password to itself and fails to delete the default_password_nag option:
http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/user.php?rev=21496#L334
wp_generate_auth_cookie() (called via wp_update_user()) also receives the old data, which causes it to create cookies for the old password and leads to logout:
http://core.trac.wordpress.org/browser/trunk/wp-includes/pluggable.php#L581
13351.patch replaces get_userdata() with new WP_User() in those two places. An alternative would probably be to check if $_POST (or a specific key) is empty in get_user_by().
Was this installed on SVN trunk a few weeks ago? I believe there was a bug for a few revisions which result in this.
Does this occur on a new installation of the latest trunk?