Max Semenik wrote:
Instead of randomly increasing the cookies lifetime, I think that we should be renewing the cookies if the session has more than eg. 24 hours. That way, you would never need to login again if you browsed the wiki at least once in the last month.
That would require some effort, and will add another cookie that stores expiry time. A simple increase in time will be a fine solution until a complex scheme is implemented (do we want it at all? more cookies=more bandwidth). Additionally, there's still no good reason to keep expiry time short anyway.
Nope. It's just another field in the session storing when was it last set. If it wasn't today, update it and overwrite the cookie with the new expiry. For frequent users, renewing at something like $wgCookieExpiration would work fine, but would fail for the guy which uses the wiki twice a month, and the central day is precisely the day before it starts being renewed.
Personally, I don't find annoying having to log in once a month. It's the CentralAuth third party cookies (+ firefox behavior) what makes them expire.
I don't use FF, can you elaborate?
I have it configured to remove cookies at end of session (except for a few domains, like wikipedia.org). If I log in via wikipedia.org, it is persistent and all is good. If I log in via a non-whitelisted domain, the third party wikipedia.org cookie gets downgraded to a session cookie.