Session Expiration Handling

Our wiki is read-mostly. Only a small handful of users have edit access.

We do not want to have to log in again unless we have quit the browser and/or rebooted the computer!

According to /bin/configure:

For best performance, you can set ={Sessions}{ExpireAfter}= to a negative number, which will mean that Foswiki won't try to clean up expired sessions using CGI processes. Instead you should use a cron job to clean up expired sessions.

That only says that FW won't try to clean up expired sessions. It implies that sessions will still expire.

I tried setting {Sessions}{ExpireAfter} to 9999999 but RichMorin is getting the login request window now several times a day, so either 9999999 is too large or... something is wrong.

If I use a negative number, will that also prevent expiration of sessions? Will it allow us to log in and work and keep working for days without needing to log in again?

RichMorin is getting several "something suspicious has occurred" nastygrams every day; at least a few of these require him to log in (and retrieve the previous edit session). This is wrong...

-- VickiBrown - 09 Feb 2016

Check {Sessions}{ExpireCookiesAfter} as well. The browser simply may have decided that the cookie is outdated. It then asks for a new one which results in a new session object being created on the server.

That is:

The session object on the server is controlled by {Sessions}{ExpireAfter}
The cookie in the user's browser is controlled by {Sessions}{ExpireCookiesAfter}

You will need to log in again when either of them expired.

-- MichaelDaum - 09 Feb 2016