Last modified: 2014-08-31 04:35:10 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 T54570, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 52570 - When user makes new password, the user is stopped by error: "incorrect password", even when the password is correct
When user makes new password, the user is stopped by error: "incorrect passwo...
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
All All
: High critical with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2013-08-06 03:20 UTC by jeffwang16
Modified: 2014-08-31 04:35 UTC (History)
3 users (show)

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


Description jeffwang16 2013-08-06 03:20:34 UTC
I made a new account for a client. He got an emailed password. Well, for some odd reason he is unable to change his password. He puts in the same, correct "old" password and he cannot manage to change the password. He gets an error: "Incorrect password", and he gets redirected back to the UserLogin page yet the URL still indicates ChangePassword.

This shouldn't be an issue with caching, is it? I am using SQLite on this installation.

Jeffrey Wang
MyWikis - premium wiki hosting
Comment 1 Andre Klapper 2013-08-06 13:08:08 UTC

(In reply to comment #0)
> Well, for some odd reason he is unable to change his password.

Which exact MediaWiki version is this about? Did you already ask on ?
Comment 2 jeffwang16 2013-08-06 13:29:47 UTC
Oi, didn't I already put 1.21.1 above?
Comment 3 Platonides 2013-08-06 13:36:03 UTC
Is that rejected accepted for login?
Comment 4 jeffwang16 2013-08-06 14:20:07 UTC
Eh? The user never could log in.
Comment 5 Andre Klapper 2013-08-06 15:09:55 UTC
The steps are not clear to me and it would be helpful to have a step-by-step explanation in order to reproduce.
For example, how to get a URL indicating "ChangePassword"? I am only aware of Special:PasswordReset. Plus I'd really like to know on which exact URL the user tries to change the password, instead of paraphrasing it. :)
Comment 6 jeffwang16 2013-08-06 15:35:33 UTC
1. Set up your wiki
2. Go to UserLogin/signup
3. Check the "send password to account".

The user who had a password sent to his account, let's call him "Bob", gets his temporary password.

1. He logs in with temp pass
2. He is brought to pass reset with standard message about the password being a temporary one.
3. No matter what value is put in the "old password" input, the password is regarded as "incorrect", even when carried over by the browser. The URL is still PasswordReset but shows UserLogin.
Comment 7 jeffwang16 2013-08-07 04:11:07 UTC
Actually, some new information:

* Same issue with MySQL
* We have compression settings on
* Here is our config that could've broken this:

$wgMainCacheType = CACHE_MEMCACHED;
$wgMemCachedServers = array ( '' );
#$wgMainCacheType = CACHE_ACCEL;
$wgResourceLoaderMaxage = array(
'versioned' => array(
// Squid/Varnish but also any other public proxy cache between the client and MediaWiki
'server' => 30 * 24 * 60 * 60, // 30 days
// On the client side (e.g. in the browser cache).
'client' => 30 * 24 * 60 * 60, // 30 days
'unversioned' => array(
'server' => 60 * 60, // 60 minutes
'client' => 60 * 60, // 60 minutes

$wgMiserMode = true;
$wgCompressRevisions = true;
$wgJobRunRate = 0.01;
$wgUseFileCache = true;
$wgFileCacheDirectory = "/home/###/common/cacheland2/$wgSitename";
$wgShowIPinHeader = false;
$wgDisableOutputCompression = true;
$wgUseGzip = true;
$wgEnableSidebarCache = true;
$wgDisableCounters = true;

Regardless if I should turn these settings off, this bug still needs to be fixed.
Comment 8 Andre Klapper 2013-08-08 07:17:12 UTC
Could you confirm I get it correctly that 
* this is reproducible,
* more than one user, and
* more than one wiki
are affected by this?

Is there a test account that could be used to experience the problem?
Comment 9 jeffwang16 2013-08-09 11:51:12 UTC
This is reproducible, and as far as I know, it affects both MySQL and SQLite. So, could that count towards "more than one wiki"? This does affect more than one user. If you would like, I can set you up with a test account on your wikimedia email. Just to be clear, the first admin account can log in, but all other users trying to log in with their email are stopped.
Comment 10 Andre Klapper 2014-01-09 11:29:29 UTC
jeffwang16: I'm sorry that I did not follow up on this. 

Is this still a problem you're facing? Is the ConfirmAccount extension installed? 
I recommend to also post the problem on as it has a broader audience.
Comment 11 jeffwang16 2014-01-11 21:50:23 UTC
I've already posted a post that went unnoticed and is probably dead by now. I will not be reviving it and no, the ConfirmAccount should not be installed. This is a problem and this is a wiki farm configuration, using a GlobalSettings.php in a folder not accessible via port 80.

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