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.