Managing Session Expiration

Skip to end of metadata
Go to start of metadata

Control Session Expiration

When a user logs in via Gigya, Gigya creates a login session for the user. For customers of Gigya's Social Login or RaaS, the session stays valid forever unless the user logs out (accounts.logout when using RaaS or socialize.logout without RaaS), or the cookie is deleted. 

Gigya gives you the option to change the default behavior and decide when to terminate a login session. 

Use the sessionExpiration parameter in the Global Configuration or the gigyaPlugins.sessionExpiration parameter in accounts.setPolicies (in RaaS), or sessionExpiration in showLoginUI/login (without RaaS) to set session expiration. 

This parameter defines the length of time that Gigya should keep the user's login session valid. It can be configured via Global Configuration, via an individual API call, or left empty. If no value is specified, the default values are 0 or -2, depending on whether your site uses RaaS or not (see below); Global configuration overrides the default, and setting the value via individual API calls override the global configuration. 

The expected values are:

  •  0 - Session expires when the browser closes. This is the default behavior when RaaS is enabled in your site. This behavior is dependent upon the browser's cookie handling procedures, i.e., Chrome keeps processes running in the background even after the browser is technically closed, this keeps the cookies valid until the background processes are terminated.

  • -1 - Session ends after a 60 second period; Gigya gives you the option of creating a cookie that is stored on the site visitor's client (browser), allowing the site to control the session length within this 60 second window, after which the session is terminated if no cookie is found. A typical use case is when the session could include sensitive data (such as credit card details), and the session should be short, with the option of restarting the duration when users perform actions. Useful if you always set the session expiration via individual API methods or with each request, such as when the site session is controlled by a CMS (e.g., Drupal). For additional information, see how to define a session expiration cookie.

  • -2 - Session is valid forever. This is the default behavior when RaaS is not enabled in your site. 

  • Any custom integer - Defines the number of seconds the session is active, e.g., 3600  (one hour). 

Notes: 

  • In a Single Sign-On (SSO) situation, if different sites in the group have different session expiration values, the user's session expiration is governed by the site they originally logged into. Visiting other sites in the same SSO group (that may have higher or lower session expiration values) does not create a new session and does not change the session expiration value of the user's current session.
  • You can use the verifyLoginInterval parameter of the Global Configuration object to periodically check if active sessions for logged-in users are still valid. Invalid sessions will automatically be logged out. When users log back in, they may need to pass additional fields that were not required before.

Defining a Session Expiration Cookie

If you want your server (or CMS) to control the Gigya session, you can use Dynamic Session Cookies. Dynamic Session Cookies enable your server to control the length of time a user remains logged into Gigya, based upon the Server's (CMS's) session length. Using Dynamic Session cookies places control of the session on the server/CMS.

You should generate a Dynamic Session cookie during each of your server responses, so that the expiration time is counted from the time of the latest user activity on the site. If the server interaction is not related to a call to a Gigya API, in order to ensure the expiration of the entire site group is synced correctly you should also make a call to gigya.syncGroupGltExp() which will sync the SSO session.

To enable Dynamic Sessions support for your site, the Gigya sessionExpiration property of your site's Policies must be set to -1.

If sessionExpiration is set to -2 (valid forever), session expiration cookies are disregarded. To end the session, call socialize.logout  ( accounts.logout  for RaaS) or delete the session cookie.

To use Session Expiration Cookies, your sessionExpiration must be set to -1 in your site's Policies.

 

The session expiration cookie must be located on your site's base domain (e.g., yoursite.com), and have the following structure:

Cookie Name

"gltexp_" + "INSERT-YOUR-APIKEY-HERE"

Replace "INSERT-YOUR-APIKEY-HERE" string with your Gigya API-Key, which can be obtained on the Dashboard page on the Gigya website.

Cookie Value

Use the SigUtils.getDynamicSessionSignature or SigUtils.getDynamicSessionSignatureUserSigned utility methods available in Gigya's Server Side SDKs, to generate the cookie value.

The structure of the cookie value depends on whether you are using the Partner secret or an App/User key and App/User secret combo. Click the relevant tab for details: 

 

Path

The location of the cookie should always be your site's base domain, i.e., path="/".
Make sure to use only your base domain (e.g., example.com), do not use a subdomain (i.e., news.example.com) or subfolders (i.e., example.com/sports).
The cookie should not have the session.cookie_httponly flag enabled, as the cookie needs to read by the WebSDK on the client's browser.

 

Dynamic Session Cookie Flow

 

Dynamic Session Flow in an SSO Group

 

FAQ

 Q: Is there a way to determine the Gigya session expiry time when a user logs-in?

A: While Gigya does set a client side cookie, the best way to poll for an active session is by calling the getAccountInfo API call, and processing the response (response.errorCode === 0) to find an active session. For info on Gigya cookies regarding session, please find a data table here: Advanced Cookie Reference

 Q: Is there way to change the cookie duration?

A: Yes, this is possible through the methods explained in Define A Session Expiration Cookie

 

 

 

  • No labels