The platform is divided into various independent services, which means there are a number of different types of session used for different purposes, each of which have a configurable idle timeout (the maximum time a session will remain valid between requests to the server).
HTTP Sessions
Default timeout: 1 hour.
Whenever a user performs an action that requires state to be persisted between requests to the server (eg logging in, adding an item to a shortlist), they are issued with a session token (HTTP cookie) that is passed on subsequent requests, so the server can retrieve/update the session's current state. These sessions are managed by the Site Session Store worker and the timeout can be set in the API Server config.
Auth Sessions
Default timeout: 1 hour.
Whenever a user attempts to log into your site, an auth session is created to store the state of their login attempt. This is used support providers that redirect a user to an authenticating third party before being returned to your site. The login page on your site loading, the redirect to the third party, and the return to your site, takes place within the auth session.
Auth sessions are typically very short-lived, they exist only for the duration of the authentication process (ie the journey from your site, to the third party, and back again), and are then expired. The timeout exists only to clear up abandoned authentication attempts. These sessions are managed by the Authentication worker and the timeout can be set in the API Server config.
Login Sessions
Default timeout: 20 minutes.
Once a user has successfully logged in, your site creates a login session to store the logged in user. A login session is actually just data stored within an HTTP session (see above), however it has it's own timeout (which should be shorter than the HTTP session timeout) so that it can be expired earlier than the HTTP session. This means that if logged in user were idle for longer than the login timeout (but shorter than the HTTP session timeout), when they next tried to load a page the site is able to show them a "Your login session has timed out" message. If the HTTP session had also expired the site would not know that the user was previously logged in and so couldn't show such a message.
Because a login session can provide a user access to secured/sensitive data, the timeout should be as low as practical - in line with current OWASP guidance. The default is 20 minutes. Login session timeouts can also be set in the Authentication template article extras.
Form Sessions
Default timeout: 1 hour.
When a user navigates to one of your forms, a form session is created that will store the submitted-so-far state of the form. These sessions are managed by the Forms Service worker and the timeout is configured in the API Server config.
Timeout Notifications
When a user's session is about to expire the site will display a timeout notification. The behaviour of the login timeout notification can be changed via the Authentication template. The form session notification cannot be customised. The default behaviour is described below.
When is it displayed?
The notification will be displayed when a session has been idle for a period of time, two minutes before the session is due to expire. That means a form session will have to have been idle for 58 minutes, a login session for 18 minutes, before the notification is displayed.
What counts as idle?
Any key press, mouse click, or mouse movement will keep a session alive, restarting the idle timer.
What happens when a session times out?
When the counter in the timeout notification reaches zero the session expires and the expired session message is displayed.
Logins will be redirected to the login article. If the user logs back in, they'll be taken back to the page they were on when the session expired.
When a form session expires the form reloads.
Share this page
