17.3. Web Sessions

17.3.1. Web Session Timeout

Web Sessions guard persistent authorized access to SavaPage. By default, all sessions expire after a certain period of inactivity. Each interaction with the Web App that results in a call to the SavaPage Web Server resets the inactivity timer. Explicitly logging out of any SavaPage Web App will immediately end the session. However, closing the browser window or tab won't: the session will be marked for removal after expiration. The actual removal of expired sessions is performed by a cyclic scavenge process. The cycle interval can be set in the server.properties file.

The default timeout periods for different login types are shown in the table below:

Login typeDefault value

Admin Web App

1440 minutes (24 hours)

User Web App

60 minutes (1 hour)

Table 17.3. Default Web Session Timeout Values

The timeout value (in minutes) can be changed using the configuration properties below. A value of 0 indicates that the session will never time out: the downside is that these sessions are not scavenged ever. A positive value will make sure that sessions are scavenged at some point in time.

Configuration propertyDescription


Inactivity timeout for the Admin Web App


Inactivity timeout for the User Web App

Table 17.4. Web Session Timeout Configuration Properties

See Section 4.11.14, “Config Editor” for information about changing configuration properties.

Changed inactivity timeout values take effect for new sessions.

When a session has expired in an open Web App, users are given a warning message, and must login again. When Authentication Tokens are used, users will see the message, but will be able to continue without the need to login.

Note that some pages periodically refresh the page (or data on the page), such as the Dashboard. A session will not time out if a browser is left on these pages, as it will be considered active.

17.3.2. Web Session Cookies

Session tracking cookies like SP_JSESSIONID and SP_BAYEUX_BROWSER are marked as HttpOnly. An HttpOnly cookie cannot be accessed by client-side APIs, such as JavaScript, and may therefore help mitigate certain kinds of cross-site scripting attacks.