Control Session Expiration
When a user logs in via Gigya, Gigya creates a login session for the user. The session stays valid forever unless the user logs out (and a call is made to accounts.logout or socialize.logout ), 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 WebSDK Configuration or the gigyaPlugins.sessionExpiration parameter in accounts.setPolicies (in RaaS), or sessionExpiration in showLoginUI/login (without RaaS) to set session expiration.
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. This value is not supported when using our Mobile SDKs, and the session will behave as if set to -2.
-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.
This setting is not supported on Safari.
-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).
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.
- Dynamic sessions (sessionExpiration of -1) is not supported on Safari.
The session expiration cookie must be located on your site's base domain (e.g., yoursite.com), and have the following structure:
Replace "INSERT-YOUR-APIKEY-HERE" string with your Gigya API-Key, which can be obtained on the Dashboard page on the Gigya website.
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:
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
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
A: Yes, this is possible through the methods explained in Define A Session Expiration Cookie.