This API 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.
Note: This method is also supported in our REST API. It is highly recommended when possible, for security reasons, to execute this method from your server, so please refer to REST API > socialize.notifyRegistration.
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 the table of parameters below) with the user ID that 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.
The Gigya service supports a mechanism to verify the authenticity of the notifyRegistration call. This mechanism is used to prove that the call is in fact coming from your site in order to prevent fraud.
If you pass the optional siteUID parameter with this method (see the table of parameters below), we require it to be signed using a HMAC-SHA1 signature. The signature and timestamp parameters are defined for this objective, and they become required parameters in this scenario. Gigya will verify the authenticity of the signature parameter to prove that it is in fact coming from your site and not from somewhere else.
Follow the instructions in Constructing a Signature to set the signature parameter of the notifyRegistration call, and make the API call as soon as possible after that to prevent the signature from expiring.
The following table lists the available parameters:
|||siteUID||string||The user ID that 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.
|||UIDTimestamp||string||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). This parameter is required if you pass the siteUID parameter with this method. Gigya checks the time difference between the timestamp and the time on Gigya's server when the setUID request is received. If the time difference is more than 5 minutes, the request is considered forged.|
|||UIDSig||string||A HMAC-SHA1 signature proving the authenticity of the data. This parameter is required if you pass the siteUID parameter with this method. See the Security Requirements above for more details.|
A reference to a callback function. Gigya calls the specified function along with the results of the API method when the API method completes.
The callback function should be defined with the following signature: functionName(Response).
The "Response Object Data Members" table below provides specification of the data that is passed to the callback function.
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.
A developer-created object that is passed back unchanged to the application as one of the fields in the response object.
Response Object Data Members