Change Details

"User:Amanda bee" can't login to any Wikimedia project. They reported the issue on #wikimedia-tech. They can login to a newly registered account "User:Amanda test". Summary of the problem: https://en.wikipedia.org/wiki/User:Amanda_test#Here.27s_the_deal IRC conversation so far: https://wm-bot.wmflabs.org/logs/%23wikimedia-tech/20170629.txt

We've had two recent reports of users being able to log in, but then finding themselves logged out either immediately on being redirected back from the login form or on the next page view after. Checking the logs, I see each successful login reports "Set global password for '${USER}'", which most likely indicates that [[https://phabricator.wikimedia.org/diffusion/ECAU/browse/master/includes/CentralAuthUser.php;2b25ad94c1f2d63066279c38b921b63874aab067$1898|the PasswordFactory::needsUpdate() check]] returned true. In the case of Amanda bee, when I looked at the database and the data in the WAN cache, however, the password seemed to be up to date. I asked the user to attempt another login, and it stuck. In the case of the other user, the database and the WAN cache still have an outdated password hash at this time despite 11 "Set global password" messages logged on June 21. **Speculation:** I wonder whether @aaron's recent changes to make various CentralAuth things happen post-send and checks to happen on non-master instances are related. In particular, the call to CentralAuthUser::setPassword() is going to reset the auth token, which would explain the users finding themselves logged out when visiting a new page (since it's post-send, it can't send the user new cookies for the new token like it should; perhaps we should pass false for setPassword's $resetAuthToken parameter there?). Apparently the attempt to actually updated the password hash is somehow failing or being overwritten by some other deferred thing. In Amanda bee's case, I suspect the attempt to log in on csbwiktionary (where no local account existed) managed to bypass whatever was preventing the password hash update from remaining. That attempt still got its session wiped out, but the following attempt succeeded since no hash upgrade was required anymore. The original report is below. I haven't named the other user here because I don't know the privacy policy with respect to OTRS reports. ---- "User:Amanda bee" can't login to any Wikimedia project. They reported the issue on #wikimedia-tech. They can login to a newly registered account "User:Amanda test". Summary of the problem: https://en.wikipedia.org/wiki/User:Amanda_test#Here.27s_the_deal IRC conversation so far: https://wm-bot.wmflabs.org/logs/%23wikimedia-tech/20170629.txt

We've had two recent reports of users being able to log in, but then finding themselves logged out either immediately on being redirected back from the login form or on the next page view after. Checking the logs, I see each successful login reports "Set global password for '${USER}'", which most likely indicates that [[https://phabricator.wikimedia.org/diffusion/ECAU/browse/master/includes/CentralAuthUser.php;2b25ad94c1f2d63066279c38b921b63874aab067$1898|the PasswordFactory::needsUpdate() check]] returned true. In the case of Amanda bee, when I looked at the database and the data in the WAN cache, however, the password seemed to be up to date. I asked the user to attempt another login, and it stuck. In the case of the other user, the database and the WAN cache still have an outdated password hash at this time despite 11 "Set global password" messages logged on June 21. **Speculation:** I wonder whether @aaron's recent changes to make various CentralAuth things happen post-send and checks to happen on non-master instances are related. In particular, the call to CentralAuthUser::setPassword() is going to reset the auth token, which would explain the users finding themselves logged out when visiting a new page (since it's post-send, it can't send the user new cookies for the new token like it should; perhaps we should pass false for setPassword's $resetAuthToken parameter there?). Apparently the attempt to actually updated the password hash is somehow failing or being overwritten by some other deferred thing. In Amanda bee's case, I suspect the attempt to log in on csbwiktionary (where no local account existed) managed to bypass whatever was preventing the password hash update from remaining. That attempt still got its session wiped out, but the following attempt succeeded since no hash upgrade was required anymore. The original report is below. I haven't named the other user here because I don't know the privacy policy with respect to OTRS reports. ---- "User:Amanda bee" can't login to any Wikimedia project. They reported the issue on #wikimedia-tech. They can login to a newly registered account "User:Amanda test". Summary of the problem: https://en.wikipedia.org/wiki/User:Amanda_test#Here.27s_the_deal IRC conversation so far: https://wm-bot.wmflabs.org/logs/%23wikimedia-tech/20170629.txt