Hi,

(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 https://www.mediawiki.org/wiki/Project:Support_desk ?

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 ( 'BLAH.ec2.garantiadata.com:11211' );
#$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 https://www.mediawiki.org/wiki/Project:Support_desk 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 mediawiki.org and maybe also the mediawiki-l mailing list.

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