☰
Navigation :

SID Source

With the sid_source parameter available in the Session DB configuration, client system can be written to provide the necessary session ID information via either the URL, cookies, or both. This section details the considerations when dealing with each.

The default approach to session management is for Jarvis to store session ID’s in a HTTP cookie. This cookie is returned to the client with every successful request to Jarvis. This approach:

  1. Requires no specific support by client applications. Web browsers will transfer the cookie automatically with every request.
  2. Allows web-browser applications to have the same session across all open windows. E.g. this allows users to open many browser tabs/windows into the application, and all of these will use the same session ID.
  3. Allows users to, within the session timeout, re-access web based systems without retyping their username/password.

URL

This approach requires the session ID to be passed in a URL parameter (or HTTP POST parameter) on each request. Unlike cookie based systems, this approach requires explicit support by the client. This approach:

  1. Without explicit support in the application to manage and support it, each new window or tab opened for a web-based application will require the user to log back into the application. In many situations this is highly undesirable.
  2. Conversely, it does mean that web-based applications can be designed to allow a user to log in multiple times to the same system within the same browser – something the cookie based approach does not allow (as cookies are browser-wide, not per window or per tab).

This approach, available when sid_source is given as url,cookie, allows the best of both of the above approaches, but does require explicit support in the application. With this approach:

  1. Jarvis will first examine the URL for the SID parameter, and then try the cookie.
  2. The client system can by default use cookie based SIDs, and then switch to using URL based SIDs when necessary (e.g. when the user wants a secondary login to the application).
  3. One example of when this is useful is when most of the time users require only a single session, but for some users it is important to provide the ability to log in as multiple people. With cookie based SIDs users would need to use different browsers (or browser profiles) to get this, and with URL based SIDs users would lose the ability to have multiple tabs open to the same application.

Note: The URL & cookie based authentication method above, Jarvis will ensure that cookies are only used when the SID is retrieved from the cookie. This avoids URL based sessions trampling cookie based sessions.