This method notifies Gigya of an external login that happened outside of the Accounts system. The notifyLogin call registers a new user in the Accounts service, in case the siteUID parameter provided is new, or reconnects a returning user in case the siteUID already exists in our records.
Synchronizing the session to the client-side
When receiving the response from this API, please make sure to create a session cookie, using data contained in the returned sessionInfo object, so as to maintain the client application synchronized with the user state. The response includes data fields specifying the name, content and location of the session cookie. Please make sure that the page following the login includes Gigya's library i.e., gigya.js, in order for Gigya to read the cookie before it expires. If you are using an ajax-based site login (no page refresh after logging in), make a call to socialize.refreshUI after setting the session cookie so that Gigya is able to process the authorization before it expires.
The notifyLogin call registers a new user in the Gigya service when the siteUID parameter provided is new, or reconnects a returning user when the siteUID already exists in our records.
It is essential to call notifyLogin if you are enabling users in your site to add connections to social networks via Gigya (using socialize.showAddConnectionsUI or socialize.addConnection). The notifyLogin call allows Gigya to associate the current user's social connections with the User ID you have designated to this user.
This association has several benefits:
Any connections the user makes to social networks will be associated with the site account. The social graph will be automatically made available the next time the user logs in to the site.
Gigya will set the isSiteUser flag for this user to "true", thus even if this user is referred to as a friend of another user you can easily tell he is a user of your site and not just a friend of the visiting user.
Read more about integrating Gigya's Social Login and the implementation flow in our Social Login guide.
When calling notifyLogin on a user that has not finalized registration, if the user's account already contains all required fields, the isRegistered flag will set to true.
Note: If you plan on integrating Gigya's Accounts API, we highly recommend reading the Registration-as-a-Service Guide. Registration-as-a-Service (RaaS) is a premium platform that requires separate activation. If RaaS is not part of your site package, please contact Gigya by filling in a support form through the Console. You can access the support page by clicking Support on the upper menu after logging into the Gigya Console.
A unique identifier used by your site to identify the user. You may use the user's account ID that you have designated for this user in your database. Note: the parameter accepts only ASCII characters (not Unicode) and up to 252 characters. If you use this parameter, providerSessions is Optional.
*You are required to pass at least one of the parameters siteUID and/or providerSessions.
This parameter gives the option to pass to Gigya, session information obtained directly from a social network, so it can be used for making API calls to the social network. The value of this parameter is a JSON object with reference to other objects. The field names of the main object are the names of the provider to set the session information for. The sub-objects contain the session information. For example:
Note, each provider requires a different set of fields for making API calls. The provider field names may be: 'google','facebook', googleplus, 'twitter', 'yahoo', 'microsoft', 'line', 'linkedin', 'qq', 'renren', 'sina' , vkontakte , wechat (Note: messenger has been replaced by microsoft, however, for backward compatibility, either can be used). The sub-objects' fields are:
authToken : The session authentication token. Note: For Facebook this member should hold the Facebook Session Key.
tokenSecret : The session token secret. Note: For Facebook this member should hold the Facebook sessionSecret.
tokenExpiration : The absolute time when the session token expires in UNIX time format.
sessionHandle : The session handle encoded in BASE64.
sessionHandleExpiration : The absolute time when the session expires in UNIX time format.
Note: If this parameter is specified the call must be done over HTTPS and the siteUID parameter becomes optional.
*You are required to pass at least one of the parameters siteUID and/or providerSessions.
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).
Default is false. If set to true, the server will not perform any validation on the user and will not return any pending state errors and will not check for any registration requirements for the end user. This parameter can only be used over HTTPS.
A string of maximum 100 characters length. The CID sets categories for transactions that can be used later for filtering reports generated by Gigya in the "Context ID" combo box. The CID allows you to associate the report information with your own internal data. For example, to identify a specific widget or page on your site/application. You should not define more than 100 different context IDs.
This parameter defines your client side environment, which in return determines the server response data fields. The default value of this parameter is "browser", which means that by default you receive cookie-related data in the response. If your client runs on a mobile: If you are calling this method using a Mobile SDK since version 2.15.6, this parameter is automatically set to "mobile" (there is no need to set it manually). In any other case, you should set this parameter to be "mobile". As a result of setting the parameter to "mobile" the server response data fields will include: sessionToken and sessionSecret (instead of cookie related data). In such case, you should send the sessionToken and sessionSecret to your mobile client. On your client side, call GSAPI.setSession (using the Mobile SDK) to save them in the app's storage.
Records the source of the registration. The default value is the URL of the current page but it can be any string value. regSource is stored in the account and can be used by verification emails to determine which page should be opened (see accounts.set Policies). Can also be set via the Global Conf object.
Determines the format of the response. The options are:
jsonp - if the format is jsonp then you are required to define a callback method (see parameter below).
This parameter is required only when the format parameter is set to jsonp (see above). In such cases this parameter should define the name of the callback method to be called in the response, along with the jsonp response data.
This parameter may be used to pass data through the current method and return it, unchanged, within the response.
This parameter may be used in order to suppress the showing of screen-sets as a result of API calls. Default is false.
The default value of this parameter is false, which means that the HTTP status code in Gigya's response is always 200 (OK), even if an error occurs. The error code and message is given within the response data (see below). If this parameter is set to true, the HTTP status code in Gigya's response would reflect an error, if one occurred.
The following parameters are Requiredonly when calling the method from client side (e.g., using a Mobile SDK):
The UIDSig is an HMAC-SHA1 signature proving the authenticity of the data. The signature construction should be implemented on your server side. You can read more in Constructing a Signature.
The UIDTimestamp is the current GMT time when request is made. The expected format is the Unix time format (i.e. the number of seconds since Jan. 1st 1970). Gigya will check the time difference between the timestamp and the time on Gigya's server when this request is received. If the time difference is more than 5 minutes, the request is considered forged. Please make sure that the UIDTimestamp holds the same timestamp used in the construction of the UIDSig parameter. You can read more in Constructing a Signature.
Each REST API request must contain identification and authorization parameters.
Some REST APIs may function without these authorization parameters, however, when that occurs, these calls are treated as client-side calls and all client-side rate limits will apply. In order to not reach client-side IP rate limits that may impact your implementation when using server-to-server REST calls, it is Recommended Best Practice to always sign the request or use a secret. A non-exhaustive list of REST APIs that this may apply to are as follows:
The unique user ID. This user ID should be used for login verification. See User.UID for more information.
The signature that should be used for login verification. See User.UID for more information.
The GMT time of the response in UNIX time format, i.e., the number of seconds since Jan. 1st 1970. The timestamp should be used for login verification. See User.UID for more information.
The UTC time the account was created in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The UTC time the account was created in Unix time format including milliseconds (i.e., the number of seconds since Jan. 1st 1970 * 1000).
Custom data. Any data that you want to store regarding the user that isn't part of the Profile object.
The email addresses belonging to the user. This includes the following fields:
verified - an array of strings representing the user's verified email addresses
unverified - an array of strings representing the user's unverified email addresses.
Note: emails must be specified explicitly in the include parameter in order to be included in the response.
An array of Identity Objects, each object represents a user's social identity. Each Identity Object contains imported data from a social network that the user has connected to. Note: You must explicitly specify identities within the include parameter for them to be included in the response: identities-active , identities-all, or identities-global to return only active identities, all identities of a site, or all identities of a site group, respectively.
Be advised that if a user registers to your site using a Social Identity, then goes through the Forgot Password flow, a Site Login is added to their account, however, a Site Identity is not. A Site Identity can only be created when accounts.setAccountInfo is called on the user's account.
Influencer rank of the user. This property is deprecated and will always return 0.
Indicates whether the account is active. The account is active once the user creates it even without finalizing it. The account can be deactivated, but it will still be registered if the registration process has been finalized. If isActive==false the user cannot log in, however any currently active sessions remain valid.
Indicates whether the account is currently locked out. This parameter is not included in the response by default, and is not returned at all from accounts.search. If you wish to include it in a response, specify it as a value of the include parameter.
Indicates whether the user is registered. The user is registered once his registration has been finalized.
Indicates whether the account email is verified.
The time of the last login of the user in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The user's last login location. This includes the following fields:
country - a string representing the two-character country code.
state - a string representing the state, where available.
city - a string representing the city name.
coordinates - an object containing:
lat - a double representing the latitude of the center of the city.
lon - a double representing the longitude of the center of the city.
The UTC time of the last login of the user in Unix time format including milliseconds (i.e., the number of seconds since Jan. 1st 1970 * 1000).
The UTC time when user profile, preferences, or subscriptions data was last updated (either full or partial update) in ISO 8601 format, e.g., "2017-07-16T19:20:30Z".
The UTC time when the last update of the object occurred (either full or partial update) in Unix time including milliseconds, based on when the 'lastUpdated', 'Report AccountsFirstLogin' or 'AccountsReturnedLogin' events are fired.
The user's login identifiers. This includes the following fields:
username - a string representing the username
emails - an array of strings representing email addresses
unverifiedEmails - an array of strings representing email addresses that were not validated
Note: loginIDs must be specified explicitly in the include parameter in order to be included in the response.
The name of the provider that the user used in order to login.
The UTC time when the oldest data of the object was refreshed in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The UTC time when the oldest data of the object was refreshed in Unix time format including milliseconds (i.e., the number of seconds since Jan. 1st 1970 * 1000).
The user's Site account password details. Includes the following:
hash - the hashed password
hashSettings - object includes:
algorithm - Represents the hash algorithm used to encrypt the password.
rounds - Represents the number of iterations to perform the hashing.
salt - Represents the BASE64 encoded value of the salt.
format - Represents the template for merging clear-text passwords. This is only returned if the pwHashFormat parameter was set during account import and until the user's first login to Gigya (when the user's password is rehashed per the site's settings). See the RaaS Import Guide for additional information.
This property is deprecated in server to server REST calls! The signature that should be used for login verification. See User.UID for more information.
This property is deprecated in server to server REST calls! The GMT time of the response in UNIX time format, i.e., the number of seconds since Jan. 1st 1970. The timestamp should be used for login verification. See User.UID for more information.
The user's profile information as described in the object. The profile is returned in the response by default, but if the include parameter is used to specify other fields that should be provided in the response, the profile must also be specified explicitly in the include parameter.
The current RBA Policy defined for the specified user. Properties include:
riskPolicy - Determines the rule set from the defined rulesSets configured in accounts.rba.setPolicy or one of the default policies.
riskPolicyLocked - Determines whether the user can change their own riskPolicy. If true, only an admin can change the user's riskPolicy.
The UTC time when the isRegistered parameter was set to true in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The GMT time when the isRegistered parameter was set to true in UNIX time format, including milliseconds.
A string representing the source of the registration. Can be used to set varying destination pages in accounts.setPolicies.
A comma-separated list of the names of the providers to which the user is connected/logged in.
The Gigya User object. This property is deprecated and should not be relied upon.
The UTC time when the isVerified parameter was set to true in ISO 8601 format, e.g., "1997-07-16T19:20:30Z".
The GMT time when the isVerified parameter was set to true in Unix time format including milliseconds (i.e., the number of seconds since Jan. 1st 1970 * 1000).
A ticket that is used to complete a registration process. A new regToken is returned when there is a pending registration error, which occurs when the user did not complete the registration process, or there are missing fields in the user profile data that were defined as "required" in the Schema.
An object containg session information. The content of this object depends on the targetEnv parameter (see above). By default, if the targetEnv parameter is not set (your client environment is web), the sessionInfo object contains the the following string fields: cookieName and cookieValue. Please create a session cookie with the name and value specified by these fields. Alternatively, if the targetEnv parameter is set to "mobile" (your client runs on a mobile), the sessionInfo object contains the the following string fields: sessionToken and sessionSecret. Please send these fields to your mobile client. On your client side, call GSAPI.setSession (using the Mobile SDK) to save them on the app's storage.