Last modified: 2014-11-18 18:07:29 UTC
From time to time someone runs into the problem that his system clock is set more than a month in the future, rendering login cookies immediately invalid. This means that logging into MediaWiki is impossible - the logon seems to work, but on the next page load, he is logged out again. This is a very annoying bug as the system clock is not something one would typically check for login problems so usually the afflicted person is unable to use the wiki for days until the problem is located. It would be nice to include a timestamp in the successful login page, compare it to the system clock via javascript, and either show a warning or just extend the validity of the cookie if the system clock seems to be off. (Or at the very least change the "check if you have cookies enabled" text to include checking the system clock.)
RFCs 2109 and 2965 both seem to give cookie expiration in terms of max age, not expiration date: http://tools.ietf.org/html/rfc2109 http://tools.ietf.org/html/rfc2965 If we're serving Expires instead of Max-Age on cookies, that implies we're using "old" cookies, so maybe we should just switch to "new" ones? Dunno how this would be accomplished or if it has any drawbacks.
(In reply to comment #1) > RFCs 2109 and 2965 both seem to give cookie expiration in terms of max age, not > expiration date: http://tools.ietf.org/html/rfc2109 > http://tools.ietf.org/html/rfc2965 If we're serving Expires instead of Max-Age > on cookies, that implies we're using "old" cookies, so maybe we should just > switch to "new" ones? Dunno how this would be accomplished or if it has any > drawbacks. We use setcookie(). setcookie() uses Expires, it seems. +upstream?
Yeah, this is upstream, I guess. Is there any workaround we can use? Is there some reason to prefer Expires (e.g., reliability)?
I suppose we could construct our own cookies and send the headers... but reinventing the wheel sucks. I'd much rather see us push this back upstream. The PHP docs say that they're following the older Netscape cookie spec (http://curl.haxx.se/rfc/cookie_spec.html). Provided that all the major browsers are supporting RFCs 2109 and 2965--and I would assume so, they're 13 and 10 years old, respectively--I would think PHP could get with the 21st century as well ;-)
Pushing it upstream would be fine by me, if anyone is willing to do it, and upstream is willing to accept it. This is hardly urgent enough that we need to work around it ourselves if we can tell users to just upgrade. But pushing upstream is harder than working around it ourselves.
I would just push it upstream and track it. As annoying as it can be, this does not seem worth another special case in mediawiki.
See http://bugs.php.net/bug.php?id=23955
