Timeout issues
There's a confusing interaction between the local session timeouts implemented by UcamWebauth application agents (such as mod_ucam_webauth) and the timeout applied to the 'Log in' feature provided by the central server (see Raven 'login options'). The following may help explain what's going on.
The first time someone get redirected to a UcamWebauth authentication server during a particular browser session most people choose to 'log in'. This establishes a (by default) 10 hour session with the authentication server during which further authentications can (normally) occur without the need to re-enter a userid and password. People can chose not to log in, or to alter the session length, both by default and on a session-by-session basis, but most people don't.
When a UcamWebauth authentication server sends a positive authentication response message back to a webserver it includes a note of the time that the session ON THE AUTHENTICATION SERVER will terminate. Application agents (like mod_ucam_webauth) are supposed to use this to apply an upper limit to the length of any local session they chose to run, but they are entitled to set their own lower limit.
The idea was that, if you were accessing something from a particularly dodgy internet cafe you could reduce your server session time limit to something you considered safe and your session on the authentication server and all sessions established by application agents as a result would terminate within that time.
mod_ucam_webauth uses the AAMaxSessionLife parameter to fix its upper limit, and this defaults to 2 hours since this seemed like a reasonably default for many applications. But it's only a default and you can override it - indeed for interactive applications involving POSTs I think you should up it to something like 10 hours.
