-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I know you guys are probably getting tired of seeing my name appear on this list by now, but I've run into yet another 1.18.0 upgrade issue. After lots of debugging over at the Bugzilla site, I finally found out my custom skin was the cause of most of my 500 server errors. I now have 1.18.0 running successfully, complete with my own custom skin (now properly derived from MonoBook rather than the hack job I did earlier).
Only... now I can't log in.
Every time I attempt to log in I receive the following cryptic error:
Login error <nocookiesforlogin>
I know for a fact that my username and password are correct, and this is my own site so I'm certainly not blocking my own cookies. I'm not using any of the $wgCookie* variables; those are all set to their default values. I've tried tweaking some of these, including setting $wgDisableCookieCheck = true, with no obvious change in the result.
The only thing I can possibly think of that might be affecting this is the fact that I use Apache mod_rewrite to force login requests to HTTPS mode so the password will be encrypted. The <form> tag does not include the protocol as part of the action value, so if I submit the form in HTTPS mode it *should* stay in HTTPS. However, as with everything else I've complained about, this worked without a hitch in 1.17.1 and below and stopped working with 1.18.0.
Any ideas? I want to make sure it's not something stupid I've done before filing a bug report.
- --
Jeff Darlington General Protection Fault http://www.gpf-comics.com/
On 03/12/11 02:06, Jeffrey T. Darlington wrote:
I know you guys are probably getting tired of seeing my name appear on this list by now, but I've run into yet another 1.18.0 upgrade issue. After lots of debugging over at the Bugzilla site, I finally found out my custom skin was the cause of most of my 500 server errors. I now have 1.18.0 running successfully, complete with my own custom skin (now properly derived from MonoBook rather than the hack job I did earlier).
Only... now I can't log in.
Every time I attempt to log in I receive the following cryptic error:
Login error
<nocookiesforlogin>
That's strange. Do you have the language files up to date? It's not finding nocookiesforlogin message, whose contents are "{{int:nocookieslogin}}" which would expand to "{{SITENAME}} uses cookies to log in users. You have cookies disabled. Please enable them and try again."
I know for a fact that my username and password are correct, and this is my own site so I'm certainly not blocking my own cookies.
Maybe you are not /trying/ to block your cookies, but that error message mean that when sending the data, it is not receiving the cookies that should be presented with the POST.
The only thing I can possibly think of that might be affecting this is the fact that I use Apache mod_rewrite to force login requests to HTTPS mode so the password will be encrypted.
Is it just a redirect on the first load of UserLogin (in which case the below comment probably doesn't apply), or is it doing something fancier?
The <form> tag does not include the protocol as part of the action value, so if I submit the form in HTTPS mode it *should* stay in HTTPS. However, as with everything else I've complained about, this worked without a hitch in 1.17.1 and below and stopped working with 1.18.0.
Any ideas? I want to make sure it's not something stupid I've done before filing a bug report.
Try manually going to the userlogin page in HTTPS and submitting from there. Does it work? If the cookie was originally set in http, it should still be present in https, though. The only setting that might matter is if you have $wgCookieSecure = true; mediawiki is sending secure cookies through http, and your browser is rejecting them.
Is your wiki available somewhere?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/4/2011 3:58 PM, Platonides wrote:
That's strange. Do you have the language files up to date?
I have no idea. I'm starting from a clean yet slightly tweaked copy of the 1.18.0 code (I have a custom skin derived from MonoBook), and I made sure to run maintenance/update.php to update my database during the upgrade. I've also run maintenance/rebuildLocalisationCache.php, which was requested when someone else was trying to debug my prior upgrade issues. Beyond these steps, I've never had to "update my language files" before.
Try manually going to the userlogin page in HTTPS and submitting from there. Does it work?
That's pretty much what I'm doing. I'm going to my wiki main page (which by default is in HTTP mode), then clicking on the "log in" link in the upper right corner. The browser sends its request in HTTP mode, my mod_rewrite rules bounce the URL to HTTPS mode, and I get the secure login form. Above the login form it states "You must have cookies enabled to log in to The Official GPF Wiki." Attempting to log in from here results in the error originally described.
I tried copying and pasting the URL into a separate tab in my browser with the same results.
As stated previously, this worked fine in 1.17 and stopped working with 1.18.0.
If the cookie was originally set in http, it should still be present in https, though.
I don't have any cookies currently set for the wiki; it's been long enough since my last login that those cookies have expired. However, because of the mod_rewrite rule, the previous cookies should have been set via HTTPS.
My observation in the past was that (in versions <= 1.17) MediaWiki seemed to stay in HTTPS mode after login, which was fine by me since I prefer keeping my logged in sessions secure. If I manually switched back to HTTP mode after login (i.e. I edited the address bar to switch the protocol back) it usually "forget" I was logged in, which would imply that the cookies were being set HTTPS-only. However, I can't even get that far now; now the cookies aren't being set at all. Looking at the request and response exchange in Firebug, it doesn't look like MediaWiki is even sending the Set-Cookie header.
I should also point out that I hacked my phpBB installation to also perform secure logins like this, yet to keep normal activity (browsing, posting, most non-admin, non-user control panel stuff) in HTTP. Never had a problem here. My custom subscription code across the site works fine as well, set while in HTTPS mode but readable via HTTP. And since everything seemed to work fine in 1.17 and it broke as soon as I updated to 1.18, I can't help but be suspicious that the new code may be at fault.
The only setting that might matter is if you have $wgCookieSecure = true; mediawiki is sending secure cookies through http, and your browser is rejecting them.
$wgCookieSecure is set to the default, false. The only time I've ever changed it was in trying to get the login to work post-update to 1.18.0, and it seems to have no effect on my success. It doesn't work either way.
Is your wiki available somewhere?
It's publicly available in read-only mode; I'm the only one with admin privileges, and nobody else has or can create a login. I've been planning on taking on a few volunteer wiki-wranglers, but I haven't started taking applications yet. You can take a look if you want, but since you won't be able to log in anyway I don't know if that will help.
http://www.gpf-comics.com/wiki/
On 12/2/2011 9:18 PM, Steve VanSlyck wrote:
Great site, Jeff. I smiled at your last sentence. I usually do something stoopid both before AND after filing a bug report.
Thanks. I always hate having to post requests to bug trackers and support mailing lists, as I always feel like I'm coming off about a 100 IQ points lower than reality. I've been on the other side of the software support fence and I hate having to try and debug anything remotely, because I hate having to treat someone looking for help like they don't know what they're talking about. It's like a corollary of Murphy's Law: If anything can be said to make you sound stupid, you *will* say it.
- --
Jeff Darlington General Protection Fault http://www.gpf-comics.com/
On 05/12/11 04:02, Jeffrey T. Darlington wrote:
On 12/4/2011 3:58 PM, Platonides wrote:
That's strange. Do you have the language files up to date?
I have no idea. I'm starting from a clean yet slightly tweaked copy of the 1.18.0 code (I have a custom skin derived from MonoBook), and I made sure to run maintenance/update.php to update my database during the upgrade. I've also run maintenance/rebuildLocalisationCache.php, which was requested when someone else was trying to debug my prior upgrade issues. Beyond these steps, I've never had to "update my language files" before.
I was thinking that instead of the languages/messages/MessagesEn.php shipped with MediaWiki 1.18 you could have there a copy of an older release.
You should have there on line 1074:
'nocookiesforlogin' => '{{int:nocookieslogin}}', # only translate this message to other languages if you have to change it
and in line 1072 (you also seem to miss this):
'nocookiesfornew' => 'The user account was not created, as we could not confirm its source. Ensure you have cookies enabled, reload this page and try again.',
The md5 of the file is:
59498d33f47acb0a25cb1eec986fad1d languages/messages/MessagesEn.php
Is your wiki available somewhere?
It's publicly available in read-only mode; I'm the only one with admin privileges, and nobody else has or can create a login. I've been planning on taking on a few volunteer wiki-wranglers, but I haven't started taking applications yet. You can take a look if you want, but since you won't be able to log in anyway I don't know if that will help.
Yes. I just wanted to confirm if it was sending the cookies. Unlike what you report, I do get a wikidb_session cookie (and it is indeed marked as secure, $wgCookieSecure is defaulting to true from the https access) Still, filling a random user & password, I get the same error you reported. Your setup _should_ work, these errors are usually related to php not being able to write in the session_path, but if you didn't touch php and it worked before... The rewrite rule shouldn't matter, either but I'd ask you to remove it, and check if that makes a difference (you don't even need to enter the right credentials, as nocookies has higher priority than badpassword).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/10/2011 12:18 PM, Platonides wrote:
I was thinking that instead of the languages/messages/MessagesEn.php shipped with MediaWiki 1.18 you could have there a copy of an older release. The md5 of the file is:
59498d33f47acb0a25cb1eec986fad1d languages/messages/MessagesEn.php
The MD5 hash matches my copy, and the two lines you quoted were present. Since I installed 1.18.0 into a clean directory, this makes sense.
Yes. I just wanted to confirm if it was sending the cookies. Unlike what you report, I do get a wikidb_session cookie (and it is indeed marked as secure, $wgCookieSecure is defaulting to true from the https access)
After digging a bit deeper, I'm getting the same behavior. I may have just been looking at the wrong line in the output, as I'm seeing the cookie being sent now.
Again, having the cookie secure isn't necessarily a problem; in fact, I rather like it that way, truth be told. (I'm all about encrypting session data.)
Still, filling a random user & password, I get the same error you reported. Your setup _should_ work, these errors are usually related to php not being able to write in the session_path...
Now that you mention it, I've had trouble with this in the past. I'm not sure if it's the occasional PHP upgrade, but sometimes I lose write permissions on the directory session.save_path is set to in php.ini. This often doesn't present a problem as none of my code and apparently none of the other third-party apps I have installed seem to use sessions. It's often MediaWiki where this first crops up.
I just went and checked on it, and the path seems to have 770 permissions, owned by root:apache. Unfortunately, I have Apache running under a non-standard group, meaning Apache shouldn't be able to write there. I just changed the group ownership to the group Apache is running under and, as you might guess, it suddenly works. I guess I'm just going to have to be more diligent when Fedora pushes out PHP updates and watch the permissions on that directory.
I'm still getting the "You must have cookies enabled to log in" message over the login prompt, however. This isn't necessarily a problem since I'm the only one with login access (at the moment), but it seems odd that it should still be showing. That is, unless it's a generic notification and it's always meant to be shown. I don't remember seeing it before, but maybe I just hadn't noticed it.
Thanks for the input.
- --
Jeff Darlington General Protection Fault http://www.gpf-comics.com/
On 11/12/11 21:30, Jeffrey T. Darlington wrote:
Again, having the cookie secure isn't necessarily a problem; in fact, I rather like it that way, truth be told. (I'm all about encrypting session data.)
Well done :) Not sure if it's an error of firefox (I can't find it), but I'm getting the login page marked as loading content insecurely on the first load (disappears if I reload).
Still, filling a random user & password, I get the same error you reported. Your setup _should_ work, these errors are usually related to php not being able to write in the session_path...
Now that you mention it, I've had trouble with this in the past. I'm not sure if it's the occasional PHP upgrade, but sometimes I lose write permissions on the directory session.save_path is set to in php.ini. This often doesn't present a problem as none of my code and apparently none of the other third-party apps I have installed seem to use sessions. It's often MediaWiki where this first crops up.
I just went and checked on it, and the path seems to have 770 permissions, owned by root:apache. Unfortunately, I have Apache running under a non-standard group, meaning Apache shouldn't be able to write there. I just changed the group ownership to the group Apache is running under and, as you might guess, it suddenly works. I guess I'm just going to have to be more diligent when Fedora pushes out PHP updates and watch the permissions on that directory.
I'm glad it sorted out. The timing matching the upgrade of MediaWiki from 1.17 to 1.18, and no mention of a php upgrade obscured it.
I'm still getting the "You must have cookies enabled to log in" message over the login prompt, however. This isn't necessarily a problem since I'm the only one with login access (at the moment), but it seems odd that it should still be showing. That is, unless it's a generic notification and it's always meant to be shown. I don't remember seeing it before, but maybe I just hadn't noticed it.
Yes, that phrase shown in normal text is expected to be always shown. You can change (remove) it by editing https://www.gpf-comics.com/wiki/MediaWiki:Loginprompt
Best regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/11/2011 5:50 PM, Platonides wrote:
Not sure if it's an error of firefox (I can't find it), but I'm getting the login page marked as loading content insecurely on the first load (disappears if I reload).
Were ads displayed on the page? My skin modifications insert ads, but they're not supposed to be displayed when the page is accessed via SSL. The redirect from HTTP to HTTPS could be causing my code to get confused. I didn't see this myself, but I run in a special mode that doesn't display ads for me (or any of my paid subscribers). Obviously, that's not a MediaWiki issue, but I'll take a look at it.
The timing matching the upgrade of MediaWiki from 1.17 to 1.18, and no mention of a php upgrade obscured it.
Well, I upgraded PHP some time ago, at least by several days, and I don't log into my wiki often enough as it is. That obscured it on my end as well. I didn't even think of that until you mentioned the session quirk, and that's what triggered my horribly faulty memory to recall that this has happened before.
I think with this I'm finally, completely, and successfully running MW 1.18.0. Well, I *was*... right up until I just jinxed myself.
Yes, that phrase shown in normal text is expected to be always shown. You can change (remove) it by editing https://www.gpf-comics.com/wiki/MediaWiki:Loginprompt
OK. I'm not worried about that so I won't touch it. The less I tweak things is probably better. :D
- --
Jeff Darlington General Protection Fault http://www.gpf-comics.com/
mediawiki-l@lists.wikimedia.org