2015 Change Archive
- Monday, November 10, 2014
- Monday, January 12, 2015
- Tuesday, February 17, 2015
- Monday, March 23, 2015
- Monday, April 13, 2015
- Thursday, April 30, 2015
- Monday, May 18, 2015
- Monday, June 15, 2015
- Monday, July 20, 2015
- Tuesday, September 01, 2015
- Sunday, October 11, 2015
- Monday, October 26, 2015
Monday, November 10 2014
1. Gigya will stop supporting the Android stock browser (AOSP browser in Android OS versions 4.0 to 4.4)
- Should any users access your website from an affected Android browser, login will be disabled and all plugins will be displayed in the logged-out user state.
- Should a user attempt to log in, they will receive the following error message in the browser window: “You are attempting to login from an unsecure browser. Switch browsers to login.”
- Should a user attempt to login, error code 400097 will be passed to the site with the following description: “User is attempting to access the Gigya service from an unsecure browser that is not supported. User should switch browsers.”
- The Gigya Admin Console will be disabled when accessed from an affected Android browser and an error message will be displayed in the browser window.
This change is necessary due to a severe security vulnerability that has been uncovered (for more information on the vulnerability, see http://arstechnica.com/security/2014/09/android-browser-flaw-a-privacy-disaster-for-half-of-android-users/).
Monday, January 12 2015
Impact: The following changes to the current behavior of the search APIs, accounts.search and ids.search, will take place:
1. Strings must be enclosed with quotes
If you send a string value in the "where" clause of accounts.search without enclosing it in single or double quotes, the server will successfully process your request.
If you send a string value in the "where" clause of accounts.search you must enclose it in single or double quotes, otherwise the server will return error 400006 ("Invalid parameter value").
Example of valid vs. invalid query
- Invalid query
2. Query statement order should follow SQL rules
The order of operators and terms in the accounts.search query was not enforced.
The order of operators and terms in the accounts.search query must follow the standard SQL order:
Select - From - Where - Group BY - Order By - Limit
If the order is not valid, the server will return error 400006 ("Invalid parameter value").
Example of valid vs. invalid query
- Valid query
- Invalid query - "limit" statement must be after "where" clause
3. Unsupported SQL syntax
Generic SQL operators that are not supported by accounts.search (e.g. the SQL "having" operator) were ignored by the Gigya server.
Using generic SQL operators that are not supported by accounts.search (e.g. the SQL "having" operator) will result in error 400006 ("Invalid parameter value").
4. "Encrypted" is only supported for string or text fields (only impacts clients who are setting their database schema manually using the setSchema API call)
Setting a field as "encrypted" but not setting its type to "string" or "text" does not result in an error. But, if you call setAccountInfo and pass a value that is not a string/text, the call will fail.
Setting a field as "encrypted" but not setting its type to "string" or "text" will result with an error (error 400006, "Invalid argument: Field couldn't be encrypted").
Tuesday, February 17 2015
Impact: The following changes to the current behavior of the accounts.search, socialize.removeConnection, accounts.setAccountInfo, ids.setAccountInfo, ds.store, and accounts.register APIs will take place:
1. New "timeout" parameter and timeout error code in accounts.search API
When a search request fails due to timeout on the Gigya server side in long search queries, the returned error code is 500028.
When calling accounts.search, particularly to extract large amounts of data, it is possible to specify a timeout value of up to 60 seconds. The default value is 20 seconds.
When the call fails due to timeout, the error code is 504001.
How To Prepare
- Modify your code to expect this type of error and contact Gigya if timeout errors occur.
- U se the new “timeout” parameter to extend the server timeout.
2. New need to use “is not null” to filter empty search results
When you search for a field that only appears in some of the user records or does not appear at all with accounts.search, the server either returns the records that have the fields or returns an empty results array.
For example, sending the following query when not all users have the data.f1 field:
Will return the following results:
The server will return the first set of results as JSON objects (default 300 or what is defined in the LIMIT), even if they are empty
How To Prepare
Always filter your results based on the existence of custom fields using the “ is not null ” operator. For example:
Modify your code to handle the empty objects structure
3. Change to socialize.removeConnection when removeLoginID=True
When calling socialize.removeConnection with removeLoginID=true when an the account has a site identity (email+password) and social identity with the same email address (i.e. same loginID), the call succeeds.
The call will fail with error 400096.
How to Prepare
Capture the error and display to the user a message that explains why the connection cannot be removed.
4. Can no longer store more than 16KB in an individual profile/data field
The call will fail with error 400096.
How to Prepare
Make sure you are not attempting to store more than 16KB for individual fields.
5. Updated data type: "basic-string"
This is no longer a breaking change: Existing profile fields will not be impacted by this change. Instead, this new "basic-string" type will just become available to you in future accounts.setSchema calls.
As a reminder, the "basic-string" type only allows exact matches using the "=" operator in the accounts.search or ids.search API.
6. Improved accuracy of login counts in websites calling socialize.notifyLogin server-side
When the socialize.notifyLogin API is called from the server, and the session cookie is carried into a page that includes the Gigya Web SDK, the JS code sends the cookie to the server to finish the user login. This call triggers another login reporting event, meaning the login is counted twice.
The second login reporting event has been removed, so that login counts will reflect the reality more closely. Some websites may therefore display fewer logins going forward.
Monday, March 23 2015
Impact: The following changes to the current behavior of Facebook share, any API calls that return dates, and the accounts.setAccountInfo, ids.setAccountInfo and accounts.register API methods will take place:
1. Must configure Open Graph tags for ‘facebook’ button for Share Bar
2. Unified format of dates returned from the API
The date format returned from API calls is inconsistent.
Fields of type "date" (ISO8601 date) will always return in the following format: yyyy-MM-ddTHH.mm.ss.SSSZ
How to Prepare
If you have code parsing the dates returned from API calls, make sure it does not rely on any other date format being received.
3. Attempting to send a JSON object to a Profile field defined as an array will return an error
In an API call, when sending a JSON object to a Profile field that is defined as Array (e.g. profile.education), the server returns error = 0 (no error).
In these cases the server will return error 400006 ("Invalid argument").
4. The "arrayOp" property is being deprecated from setSchema and getSchema API calls
In schema fields that hold array data, the "arrayOp" property determines if new data that is sent in is added to the array or replaces the current data.
The "arrayOp" property will no longer be returned in the getSchema response and will not be accepted in the setSchema request. The behavior for array fields will be that new data replaces the existing data.
5. Changes to email template fields in accounts.setPolicies, accounts.getPolicies
In certain email templates (welcomeEmailTemplates, welcomeEmailDefaultLaguage, accountDeletedEmailTemplates, accountDeletedEmailDefaultLaguage, confirmationEmailTemplates and confirmationEmailDefaultLanguage), the location of the templates in the JSON object is:
The fields will be located under a new "emailNotifications" section:
How to Prepare
If you read or set Policies directly via an API call, and attempt to modify these specific fields, you will need to change your code appropriately.
6. socialize.getAuthValidationData method no longer supported
socialize.getAuthValidationData was required for authenticating sessions for the Chat plugin.
Due to security improvements, socialize.getAuthValidationData is no longer required or supported.
Monday, April 13 2015
1. FQL support will be removed, resulting in changes to three Gigya APIs: socialize.getRawData, socialize.getAlbums, and socialize.getPhotos. In the case of getRawData, only apps created on or after August 7, 2014 will be affected.
socialize.getRawData [REQUIRES YOUR ACTION if you are using this API and your app was created on or after August 7, 2014]
The fields parameter allows you to set the provider-specific fields to retrieve. If you are using an app created before August 7, 2014, no change is needed and this will continue to function.
New Behavior (for Facebook apps created on or after August 7, 2014)
A new optional parameter named path has been added to socialize.getRawData, which refers to the Graph API path you would like to retrieve data from. This parameter replaces the fields parameter for implementations using FB apps created on or after August 7, 2014.
How to Prepare
If you are using a Facebook app version 2.1 or higher, you will need to stop using the fields parameter and use path instead. Note that the path needs to follow the graph.facebook.com format (e.g. /me/photos), which is different from the SQL-like query used in FQL (e.g. fql?q=SELECT+uid2+FROM+friend+WHERE+uid1=me() ).
socialize.getAlbums [REQUIRES YOUR ACTION if you are using this API]
Today, the optional values for type are ‘normal’, ‘profile’, ‘mobile’, ‘wall’ and ‘all’. In addition, if the title field is empty, a null value will be returned and the following fields return certain values:
As of this change, the optional values for type will now include the following (in addition to those listed above): ‘app’, ‘cover’, ‘album’.
Also, if the title field is empty, it will not be returned at all, thumbnailHeight will no longer be returned, and the values for the fields listed below will change:
- thumbnailWidth (will always be 100px)
socialize.getPhotos [REQUIRES YOUR ACTION if you are using this API]
Today, when the tags parameter of socialize.getPhotos is used, each photo is returned with its thumbnailWidth and thumbnailHeight. In addition, the changes to the getAlbums response apply here as well. Today, if the title field is empty, a null value will be returned and the following fields return certain values:
When using only the tags parameter of socialize.getPhotos, the thumbnailWidth and thumbnailHeight will no longer be returned. Also, as with getAlbums, if the title field is empty, it will not be returned at all, thumbnailHeight will no longer be returned, and the values for the fields listed below will change:
- thumbnailWidth (will always be 100px)
2. LinkedIn permissions settings will update in preparation for changes to their public API availability coming on May 11 [REQUIRES YOUR ACTION if you plan to use the Apply with LinkedIn program and continue requesting extended permissions like Full Profile and Network]
Any LinkedIn app can request the following scopes (and Gigya requests the first two by default):
The above scopes will only be available when you are using LinkedIn within the Careers or Jobs section of your website, in order to simplify the application process for interested candidates looking for jobs with your company. If this use case is relevant to you, then you will need to apply for these permissions via Apply with LinkedIn.
- If your app is approved, these scopes will be available to you.
- If your app is not approved, then requesting these scopes will result in an error.
How to Prepare
On April 13, Gigya will update the LinkedIn permissions within the Gigya Console to more granularly break out all available permission types. All of the LinkedIn Extended Permissions will be de-selected by default. These should only be re-selected if and when you have been approved for Apply with LinkedIn. Otherwise, users will receive an error.
Note that Gigya will ask for the r_basicprofile scope by default. Email, post to stream, and notifications permissions will be migrated based on your current Permissions settings in the Gigya Console.
Thursday, April 30, 2015
Impact: The following changes to Facebook will take place as a result of the version 1.0 API deprecation.
1. All Facebook apps must be upgraded to version 2.0
Steps to Upgrade:
- Upgrade your Facebook application to the new Facebook Login by undergoing Facebook App Review. We will assist you from start to finish on getting your app approved by Facebook. You can find out more by visiting our App Review FAQs.
- Enable Facebook API v2 within your Gigya Console account, as detailed here (please note that if your apps are part of a Site Group in Gigya, there are special instructions for ensuring Gigya is able to identify the same user across sites).
- Update to the latest version of the Facebook SDKs for iOS and Android in your mobile applications.
Consequences of Not Upgrading:
Mobile - we encourage you to make this update as soon as possible to ensure the maximum number of users download the latest versions of your mobile apps before the April 30th deadline. Should you not upgrade to version 2.0 of Facebook’s API, or if users do not successfully upgrade their version of your mobile app in time, then users may experience the following issues:
- Crashes on login
- Login loops when people decline permissions
- Degraded experiences because friend_* permissions are no longer there
- Errors due to change in Graph API response format
2. Facebook will no longer support Checkins
As a part of the API version 1.0 deprecation, Facebook will no longer support checkins. This means that Gigya’s socialize.checkin and socialize.getPlaces APIs will no longer support Facebook. You should remove references to Facebook when calling these API methods.
Monday, May 18, 2015
1. All domains shortened via Gigya will need to be explicitly defined under Site Settings
Who Will Be Affected: Anyone who is not yet explicitly defining all domains shortened and shared in their Gigya implementation (under Trusted Site URLs or Additional Share URLs within Site Settings in the Gigya Console).
Impact: If the domains shortened and shared in your Gigya implementation are not explicitly defined, then attempts to shorten and then share those domains will fail.
Current Behavior: Only those domains shortened and shared via Gigya’s sharing via email capability need to be explicitly defined under Site Settings.
New Behavior: On May 18, all domains shortened and shared via the Gigya platform, whether via our share, engagement, or loyalty plugins or our APIs (such as postBookmark or publishUserAction), will be subject to the same restriction. As such, all domains shortened and then shared from your Gigya implementations will need to be explicitly defined either under Trusted Site URLs or Additional Share URLs within Site Settings in the Gigya Console prior to May 18, in order to prevent spam abuse and improve the quality of content being shared.
If the domain is only used for sharing, please add it under Additional Share URLs.
Please also note that the most common domains to be impacted by this change will be custom URL shorteners, but all domains to which those custom shorteners resolve will need to be defined as well.
2. Yahoo! authentication will be upgraded to OAuth 2.0
2a. Considerations for determining which permissions are requested of your users will change
Who Will Be Affected: Anyone who is not following our documentation for Yahoo! application setup, and is not requesting the ‘Profiles - read/write public and private’ scope as a result.
Impact: If your Yahoo! app is not properly configured, then the data you receive about your users will decrease.
Current Behavior: Gigya’s API ensures that the full profile is requested of all users authenticating via Yahoo! login, regardless of the site’s Yahoo! app configuration.
New Behavior: Yahoo’s OAuth login will no longer allow Gigya’s API to override a site’s Yahoo! app configuration. If your app was configured precisely according to our documentation, then no changes to your app will be required; all changes will be internal to the Gigya platform and the user experience will be unchanged. If, however, your Yahoo! app does not request the Profiles - read/write public and private scope, then users will no longer be asked to grant the site access to their full profile. This means only the following data points will be returned:
In order to continue receiving the user’s full profile, you will need to:
- Log into your Yahoo! app
- Update the permissions requested (as detailed in our documentation)
- Enter the consumer key and secret, which will be newly generated by Yahoo!, into the Yahoo! Provider Configuration in your Gigya Console account.
2b. Calls to notifyLogin with Yahoo! providerSessions now require that the providerUID is passed
Who Will Be Affected: Anyone who is calling notifyLogin with Yahoo! providerSessions but not passing the providerUID.
Impact: If calls to notifyLogin are not updated, then they will fail and Yahoo! users whose sessions you attempt to pass to Gigya will not be logged in.
Current Behavior: When notifyLogin is called with Yahoo! providerSessions, passing the providerUID is optional. As such, if the providerUID is not passed, the call will still be successful if all required parameters are passed correctly.
New Behavior: When notifyLogin is called with Yahoo! providerSessions, passing the providerUID will now be required. If the providerUID is not passed, then the following message will be returned: error : missing parameter: providerUID.
3. Child (member site) API keys will no longer be able to set the “required” value for a RaaS field globally for the site group
Who Will Be Affected: Anyone who is currently setting the schema for a site group using a child (member site) API key.
Impact: If schema updates are made using a child (member site) API key, then they will only apply to that site, and not globally.
Current Behavior: The schema for a site group applies globally across all sites and changes to the “required” values on fields can be made using any API key -- child or parent.
New Behavior: Given that “required” field settings can differ for each site within a site group, any “required” field value changes made with a child (member site) API key will only apply to the child (member site) API key. Changes to the global default will need to be made using the parent API key or via the UI Builder.
4. Replies to deleted comments will no longer be hidden from the stream
Who Will Be Affected: This change requires your action if you have a non-English-language site or app displaying a custom comments UI using the getComments API.
Impact: If you make no changes, then the translation of “This comment has been deleted” in the comments.getComments response will be based on an auto-detection of the language of the comments on your site.
New Behavior: Approved replies to comments that have been deleted will be included in the stream that is retrieved or displayed on the site. In other words, comments.getComments will return "approved", "rejected", "deleted" and "pending" comments, not just "approved" as it does today).
In a deleted comment, the text and user info will be removed, and replaced with the following:
- commentText, commentTitle: "This comment has been deleted" / "This comment is awaiting moderation"
- name - "[removed]"
If your site is not in English, you will be able to set the language to translate the above text using a new “lang” param on comments.getComments. If this param is not set, then Gigya will auto-detect the language based on the other comments posted on your site.
Here is the list of full API updates associated with this change to deleted comments and their replies:
- comments.getComments (in addition to the above): The comment object's descendantsCount will now count only the approved descendants. Note: the commentsCount field in the response is unchanged, meaning it will still return the exact number of comment objects returned.
- comments.getStreamInfo, getTopRatedStreams, getTopStreams: A new field, approvedCommentCount, will be returned to indicate the number of approved comments in the stream. The commentCount field will return the same number as approvedCommentCount, but will now be marked as deprecated.
- comments.getRelatedUsers: Will now return users from all approved comments (as opposed to only "visible" comments as today).
- comments.deleteComment: Deleting a comment will now delete only the comment without deleting its descendants.
Monday, June 15, 2015
1. Facebook has deprecated their 'Interests' and 'Activities' fields.
Who Will Be Affected: Anyone who is asking for 'Enable retrieving user interests' or 'Enable retrieving user activities' permissions and especially those who are using the data returned from these requests.
Impact: Interests and Activities permissions will no longer be requested of users when they login with Facebook, and the data will no longer be returned to sites. Existing data will be maintained until the user’s first login with Facebook following this change.
Action Required: If you are relying on Interests or Activities data from Facebook in your implementation, you will need to make any necessary updates to ensure your implementation does not break when these changes go into effect on June 15.
Monday, July 20, 2015
1. The error code will change when a user tries to verify the email address of an account that’s already been created in the system.
Who Will Be Affected: Anyone who has RaaS implemented and email verification enabled, who is also handling the 500001 error returned when a user tries to verify the email address of an account that’s already been created in the system.
Impact: Rather than the 500001 error code that is returned when a user tries to verify the email address of an account that’s already been created in the system, a new error code (400010) with the reason, “loginID not found or reserved by another user”, will be returned.
Action Required: Update any logic set against the 500001 error code in this scenario to listen for a 400010 error instead. Error code 500001 (general server error) should still be handled for any other unpredictable errors.
2. Decimal numbers with a comma separator will be rejected by the server when sending to a data field defined as "float" via the accounts.setAccountInfo, accounts.register, ids.setAccountInfo or ds.store APIs.
Who Will Be Affected: Anyone who calls accounts.setAccountInfo, accounts.register, ids.setAccountInfo or ds.store APIs with decimal numbers that have a comma separator (e.g. 123,77) instead of a period (123.77).
Impact: Previously, a comma separated value was accepted by the server, but was not indexed. As of the July 20 change, these comma separated values will be rejected by the server.
Action Required: Update all decimal numbers to use a period separator rather than a comma.
Tuesday, September 01, 2015
1. Error code 409030, "Concurrent updates not allowed", will be returned when a site attempts to make concurrent calls to accounts.setAccountInfo or socialize.setUID for the same UID.
Impact: Rather than receive an error code of 0 (indicating no issue) when concurrent calls to accounts.setAccountInfo or socialize.setUID for the same UID are made, a site will now receive an error code of 409030.
Action Required: If you are currently making concurrent calls to accounts.setAccountInfo or socialize.setUID for the same UID, you will need to both avoid doing this, as well as ensure your implementation is prepared to handle the 409030 error code in the event that such concurrent calls occur. You will be able to test your implementation once this release goes to Staging on August 18.
2. Error code 400006, "Number of possible login ids is above the limit", will be returned when a site attempts to set more than 30 login identifiers on a single user record.
Who Will Be Affected: Any customer with end users who have nearly 30 or more login identifiers. (Please note that the likelihood this will affect your implementation is very low.)
Impact: Attempting to store more than 30 login identifiers on a single user record, a previously allowed operation, will now trigger a 400006 error.
Action Required: If you think this change will affect you now or in the future, we recommend getting in touch with Gigya Support to work on optimizing your implementation. While the likelihood this change will affect you is low, you can configure your system to handle the 400006 error, just in case.
3. Support for PayPal as an OAuth2 login provider.
Who Will Be Affected: Any customer who has implemented PayPal OpenID login. (For those of you who have not yet implemented PayPal, but are planning to in the future, be sure to launch with the ‘paypaloauth’ provider from the start.)
- PayPal doesn’t have a user migration plan from OpenID login to OAuth2.0, so customers who want to upgrade to OAuth will need to replace the ‘paypal’ provider with ‘paypaloauth’.
- An end user who previously created an account using the ‘paypal’ provider will need to re-authenticate using ‘paypaloauth’, and re-grant permissions as if they are a brand new user.
- Note that if social-to-social account linking is available on the site, then the user will be able to link their new ‘paypaloauth’ account to their existing ‘paypal’ account for a more seamless experience.
Action Required: Although the ‘paypaloauth’ provider will not identify an existing user, we encourage using it due to the benefits detailed above in the “New Gigya Features” section of this email. A best practice implementation will include social-to-social account linking to optimize this process for your users.
Note: Gigya will sunset support for the current ‘paypal’ OpenID provider in the first half of 2016 (exact date to be communicated once set), so you should plan your migration now. Despite this continued technical support, the 'paypal' provider and related app setup documentation will be marked as deprecated in the Gigya documentation once we launch 'paypaloauth' on September 01, to ensure that no new customers use the older version.
Sunday, October 11, 2015
1. Gigya is removing support for legacy SSL ciphers which are no longer considered secure.
The following ciphers will be removed from Gigya's US1, EU1 and AU1 data centers:
The following ciphers will be supported in Gigya's US1, EU1 and AU1 data centers:
The following ciphers will continue to be supported in Gigya's EU1 and AU1 data centers:
Who Will Be Affected: Any customer using any of the SSL ciphers in the first column above to connect to Gigya's APIs over HTTPS.
Impact: If you are connecting to Gigya’s APIs over HTTPS and your web browser or server relies on one of the above mentioned ciphers, without support for a newer cipher, then a connection will not be established. In this instance, HTTPS API calls to Gigya will not succeed.
Action Required: We believe it is highly unlikely that any customer will be impacted. However, these SSL changes will be made in the Gigya staging environment on September 20 and we recommend that you test your implementation at that time.
FAQ'S Regarding This Change:
- What can I do to see if I will be affected and how can I prepare for these changes?
Your IT team can verify that your server supports at least one of the supported ciphers listed above. You can then verify this in Gigya’s Staging environment.
- Why are these ciphers considered insecure?
Some ciphers which are currently supported by Gigya's servers are marked as insecure ciphers. Use of these ciphers is considered insecure, since an attacker can theoretically sniff the communications and potentially crack the encryption.
- How could I check / ask my IT team to check if we are affected (without loading staging)? Is there some type of config file?
In order to work with HTTPS, there's a negotiation phase in which the client / server agrees on the protocol for the communication. In order to verify that the change will be transparent, you will need to verify that you are supporting at least one of ciphers which are on the list of our supported ciphers above. Note that all recent browsers support ciphers that will work well with our environment.
- How would I change / ask my IT team to change the ciphers?
The change is done on Gigya's end. In case you are using only those specific ciphers that we are going to remove, you should add more ciphers based on your platform. Since we support many ciphers that should be supported even on older platforms, we do not anticipate that a change will need to be done on the customer's end, but we are sending this notification just in case.
Monday, October 26, 2015
1. Support for hardware “Back” buttons on mobile devices is removed. A software “close” button has been added to the dialog layout instead (for both new and old screen-sets).
Who Will Be Affected: Anyone who is calling accounts.showScreenSet on mobile.
Impact: Users will no longer be able to press the hardware “Back” button on their mobile device to close a screenset on mobile. Support has been removed since this functionality is not compatible with modern SPA frameworks. “Close” functionality was added to the dialog’s layout instead.
Action Required: None, unless you want to proactively notify your users of this change.
2. Visual style (CSS) for Gigya’s Social Login, Add Connections, and Edit Connections plugins, when rendered in a pop-up (dialog), will be updated to match the new style of RaaS screen-sets.
Who Will Be Affected: Anyone calling socialize.showLoginUI version 2, socialize.showEditConnectionsUI, or socialize.showAddConnectionsUI who do not set the containerID parameter for embedding the UI within the page.
Impact: The appearance of the pop-ups (dialogs) for the Social Login, Add Connections, and Edit Connections plugins will change (see example below), and the CSS class names used to format that appearance will also change.
Action Required: None. You will be able to view these changes in Staging on October 12 and make any desired CSS adjustments, but no changes are required on your end.
|Old Login UI Popup||New Login UI Popup|
3. Calls to accounts.getConflictingAccount will no longer return a user’s loginID if there is no password associated with it. Instead, for social accounts, the call will only return loginProviders.
Who Will Be Affected: This change is to fix a bug on the back-end such that the platform is not behaving according to its documentation . You will not be affected if your integration complies with our platform as it is documented. If, however, you are relying on the loginID returned for social accounts via the accounts.getConflictingAccount API, then you will be affected by this change.
Impact: When calling accounts.getConflictingAccount, you will no longer receive a loginID for social users.
Action Required: If your implementation relies on the loginID returned for social accounts when calling accounts.getConflictingAccount, then you will need to update your implementation to look for the user’s social loginProviders instead. You will be able to test your implementation once this release goes to Staging on October 12.
4. Gigya is sunsetting the concept of temporary users
In an effort to help you drive more value from customer identities, Gigya is planning to sunset the concept of temporary users from our platform.
Who Will Be Affected:
- RaaS customers implementing any of Gigya's engagement and loyalty add-ons (see below) who have changed the connectWithoutLoginBehavior to something other than 'alwaysLogin'.
- Social Login without RaaS customers implementing any of Gigya's engagement and loyalty add-ons (see below) who have not changed the connectWithoutLoginBehavior to 'alwaysLogin'.
- Related add-ons:
- Advanced Share
- Email Share
- Activity Feed (Deprecated)
- Anytime a logged out user authenticates via one of the above mentioned add-ons, the connect action will behave like a login (i.e., creating a permanent user record, storing it in Identity Storage and firing the onLogin event).
- Since there are no more temporary users, a user connecting to the same social network account from multiple computers will actually be connecting to the same back-end account.
- If there are any RaaS policies configured for authentication, they will apply to users authenticating via any of the above-mentioned add-ons.
Action Required: If you are implementing any of Gigya's engagement or loyalty add-ons, check the current value set for connectWithoutLoginBehavior. If RaaS is enabled for your site and you are not explicitly setting this parameter in the Global Config or including it as a parameter in your 'show' add-on API method calls, you should not be impacted. If you are using Social Login without RaaS and you are not explicitly setting this parameter, you will be impacted.
- If you are relying on temporary users and you have RaaS implemented on your site, then you should, as soon as possible, update the Global Conf connectWithoutLoginBehavior to “alwaysLogin” in a pre-production environment to evaluate the impact to your implementation. Specifically, since RaaS policies such as account linking will now be prompted for all users, regardless of whether they authenticate via RaaS screens or the Gigya plugins, the UX will change.
- If you are relying on temporary users and you only use add-ons or Social Login (without RaaS), then the user experience on your site may change if you have flows triggered by the onLogin event that will now fire from the engagement and loyalty add-ons on your site.