This section discusses the security and performance of web sessions.
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 type | Default value |
|---|---|
|
Admin Web App |
1440 minutes (24 hours) |
|
User Web App |
60 minutes (1 hour) |
Table 17.5. 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 property | Description |
|---|---|
|
web-login.admin.session-timeout-mins |
Inactivity timeout for the Admin Web App |
|
web-login.user.session-timeout-mins |
Inactivity timeout for the User Web App |
Table 17.6. 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.
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.
A WatchDog within a Web App continuously monitors browser performance and restores server connections if necessary. Optionally, a message can be displayed to draw attention to connectivity or performance issues.
| Configuration property | Description |
|---|---|
|
webapp.watchdog.interval-secs |
The interval in seconds after which the Web App
WatchDog is supposed to report. Default:
Note: The WatchDog is implemented as a JavaScript timer configured to emit a signal (callback) at fixed intervals. In practice the callback regularity is subject to the browser’s rendering and scripting pipeline. When a timer’s callback is scheduled, it’s placed in a queue. If other, higher-priority tasks are being performed, the timer callback waits, causing the WatchDog report to be delayed. The delay is an indication of performance or connectivity issues. |
|
webapp.watchdog.allowed-delay-secs |
The maximum allowed delay (in seconds) for WatchDog
reports. If the maximum is exceeded, connectivity is
checked and restored if needed. Default:
|
|
webapp.watchdog.message.enable |
Set to |
Table 17.7. Web App WatchDog Configuration Properties
Web App WatchDog is implemented in User Web App.