@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.