Last modified: 2014-08-31 04:35:10 UTC
Hello, 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. Regards, Jeffrey Wang j@mywikis.com MyWikis - premium wiki hosting
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 ?
Oi, didn't I already put 1.21.1 above?
Is that rejected accepted for login?
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. :)
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.
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?
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.
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.
