Session Management and Heartbeat

Overview

Your integration may require you to implement a session timeout as part of the security compliance requirements. Let’s say for example that you are required to revoke the user’s session if you detect inactivity for over 15 minutes. While the user is within the context of your own application(s), this is easy to ascertain and enforce. Mouse movements, keystrokes, actions, can all be detected and used to reset an “inactivity timer”. However, when the user is working within another tab in the ConceptShare proofing workspace for example, their actions are not detected by your activity monitors.

This can lead to the user working for an hour within the ConceptShare context, finally trying to commit their work back into your solution, only then seeing failures to save work, being informed that they’ve been kicked out of the system for some time, and much of their work remains uncommitted and lost.

In order to address this issue, ConceptShare provides a “heartbeat” mechanism to allow your solution to be notified when a user is active or inactive, and in order to provide a mechanism for your solution to timeout a user session even within ConceptShare.

Highlights

• ConceptShare can be configured to send a “heartbeat” to a specified REST end-point
• Anytime a user is interacting with ConceptShare, we will send active heartbeats
• If you send back a 200 OK code, we will continue the session
• If you send back a 401 Unauthorized response, we will terminate the session
• If you send back a 50X response, we will retry sending heartbeats
• If the user stops interacting with ConceptShare, we will send sleeping heartbeats
• You shouldn’t reset your inactivity monitors for sleeping heartbeats; these can be useful to still verify connectivity, or update any pass-through parameters
• When the user resumes activity, we resume sending active heartbeats again

Happy Path

If the heartbeats come within acceptable intervals (from our earlier example of 15 minute timeouts) let’s say every few seconds up to every few minutes, then your heartbeat endpoint will simply respond with a 200 OK message and reset its own inactivity time each time it receives one of our active heartbeats

Session Timeout

If the activity heartbeats don’t come for the duration of a timeout period, the next time you receive a heartbeat (the next time the user does anything within ConceptShare such as move a mouse, or hit a button), respond to the heartbeat with a 401 response. When we receive a 401 code, we will timeout the session within ConceptShare.

Retry Path

If we get any kind of 500 (ex. 500, 501 …) response while attempting to send heartbeats to your end-point, we will initially assume this to be a transient error and use a standard retry model to attempt to reestablish connectivity. If the retry attempts all fail, the fault is no longer transient, and we will disable heartbeat functionality