This method notifies the Gigya service that the user has completed the registration process at your site. Gigya then completes the user's login process.
If you pass the optional "siteUID" parameter with this method (see the table of parameters below), this method also acts like the socialize.setUID method, replacing Gigya UID in the user account with the site UID that you provide.
Call this method in the following scenarios:
The basic scenario: A new user has registered through Gigya (using a social network).
Call notifyRegistration immediately after you have stored the new user in your database. Set the "siteUID" parameter (see table of parameters below) with the user ID which you have designated to this user in your database.
The advanced scenario (optional): Link an existing site account to a social network identity.
Both scenarios are fully described in the Social Login guide.
The consequences and advantages of using the optional "siteUID" parameter:
- It simplifies your site development, in the following manner: you continue using your site User IDs (rather than Gigya's UIDs) thus avoiding the need to alter your database.
- This operation practically links the current user's Gigya account to his account on your user management system.
Thus, allowing users to sign in either by using their site credentials or by using their preferred provider? and both would lead to the same site account, so as to provide an improved user experience.
us1.gigya.com- For the US data center.
eu1- For the European data center.
au1- For the Australian data center.
ru1- For the Russian data center.
cn1- For the Chinese data center.
If you are not sure of your site's data center, see Finding Your Data Center.
|||siteUID||string||The user ID which you have designated to the current user on your user management system. This site UID must be different than the Gigya ID.|
Note: The parameter accepts only ASCII characters (not unicode) and up to 252 characters.
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.
|The following parameters are Required only when calling the method from client side (e.g., using a Mobile SDK) and if you pass the siteUID parameter with this method:|
|||UIDSig||string||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.|
|||UIDTimestamp||string||The UIDTimestamp is the current GMT time when the 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:
Please refer to the Authorization Parameters section for details.
A field that does not contain data will not appear in the response.