Page MenuHomePhabricator

When user makes new password, the user is stopped by error: "incorrect password", even when the password is correct
Closed, DeclinedPublic


Author: jeffwang16

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

Version: 1.21.x
Severity: critical



Related Objects

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:54 AM
bzimport set Reference to bz52570.
bzimport added a subscriber: Unknown Object (MLST).


(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 ?

jeffwang16 wrote:

Oi, didn't I already put 1.21.1 above?

Is that rejected accepted for login?

jeffwang16 wrote:

Eh? The user never could log in.

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. :)

jeffwang16 wrote:

  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.

jeffwang16 wrote:

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.

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?

jeffwang16 wrote:

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.

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.

jeffwang16 wrote:

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.

I'm sorry that this never received attention and that we did not manage to find exact steps to reproduce the problem. If this is still an issue I'd recommend again to try the Support Desk on and maybe also the mediawiki-l mailing list.

Aklapper changed the task status from Open to Stalled.Sep 1 2015, 12:42 PM
Aklapper lowered the priority of this task from High to Low.
Aklapper set Security to None.

I believe that happens to me today and yesterday in 1.31.0-wmf.7 (rMW03448d825f6e)
18:09, 7 November 2017.
Perhaps because I chose the same password?

With another password, I can login fine.

Does anybody know if this is still a problem in a recent supported version (currently MediaWiki version 1.31 or higher)?

Unfortunately closing this Phabricator task as no further information has been provided. If this specific issue still happens, please set the status of this task back to "Open" via the Add Action...Change Status dropdown. Thanks!