Session Duration - Clarification


#1

I’m just looking to clarify a couple of things regarding session duration and expiration.

There appears to be a couple methodologies for adjusting this parameter:

  1. Adjusting the session.gc_lifetime in php.ini as detailed here:
  1. Pass a duration value in the login request body as detailed here:

Assuming a discrepancy I’m just trying to ascertain which value would be favoured?

Does the DSP use PHP for session garbage collection or implement it’s own solution? Would setting the php.ini value to 0 and using an override in the login request be the way to go?

Thanks


#2

Hey Antony, I’m not sure. Lee should be able to answer shortly.


#3

@antonyjsmith Yes, the DSP uses standard PHP session garbage collection currently. The gc_maxlifetime settings in the php.ini do control the “duration” or max lifetime of the session and can be modified on you own DSP installs. Garbage collection of the sessions is dependent on the probabilty settings as well (Note that Debian-based, i.e. Ubuntu, installs typically disable PHP garbage collection and opt for a cron job to clean up stale session files.), so actually when the sessions are cleared may not be exactly (more likely greater than) the value set in gc_maxlifetime. This value is an integer, so the potential (may allow larger, though we haven’t tested anything larger) max is 65535, or about 18 hrs. You could set session.gc_probability = 0 to totally disable session cleanup, then set a cron job (edit /etc/cron.d/php5 on Ubuntu) to clear them at the desired time.

The “session expiration” about using the duration field in login requests, explains a browser behavior that we inherited from the Yii framework. Essentially, the duration field > 0 will cause an additional cookie to be set holding some session info that is later used to “automatically log back in” after a session has expired. It works great if your app is running in the browser with cookie support, otherwise the client has to track these additional cookies (what the forum response was intending to show). I have had limited success using this from the client.

We are currently reworking session management in 2.0 and plan on providing more options for these scenarios.


Best Way to handle Session Expiration
#4

Thanks Lee, that’s very useful feedback.