-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/4/2011 3:58 PM, Platonides wrote: 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. 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. 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. $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. 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: 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/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/2011 12:18 PM, Platonides wrote: 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. 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.) 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/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2011 5:50 PM, Platonides wrote: 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. 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. 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/