Changes That May Require Your Action

Skip to end of metadata
Go to start of metadata

 

Please see below for detailed information about our upcoming release dates, as well as information on how to prepare for upcoming changes to both the Gigya platform and your Facebook implementation.

Should you have any questions or concerns regarding your implementation and how it may be affected by these changes, please do not hesitate to reach out to your Implementation Consultant.

 

Gigya Change Schedule

For an archive of older changes, see Past Changes Requiring Your Action.

Monday, June 26, 2017

1. Parameters deprecated in socialize.getSessionInfo

Who Will Be Affected: Anyone using the socialize.getSessionInfo API and relies on receiving the tokenExpiration or sessionExpiration parameters in the response.

Impact: The tokenExpiration and sessionExpiration parameters will not be included in the response for socialize.getSessionInfo.

Why: The existing tokenExpirationUTC and sessionExpirationUTC parameters provide the same capabilities in a common (UTC) format.

Action Required : If your code depends on either tokenExpiration or sessionExpiration, use tokenExpirationUTC and sessionExpirationUTC, instead.

2. Changes to socialize.getToken API

Who Will Be Affected: Anyone using the socialize.getToken API may be affected.

Impact: 

  • When grant_type=none and when passing the x_siteUID parameter (emulating the effect of socialize.notifyLogin), the providerSessions parameter will be ignored.
  • When the code parameter is not passed, will return “Missing_required_parameter” (error code 400002) instead of “Invalid_parameter_value” (error code 400006).
  • When grant_type=authorization_code, and an invalid code parameter value is passed, will return “Invalid_parameter_value” (error code 400006) instead of “Invalid_ApiKey_parameter” (error code 400093).

Why: 

  • When a user logs-in with this flow (with a site ID), the social identities are ignored.
  • More informative, helpful error messages.

Action Required : If your code expects to receive  providerSessions , or either of the specified error messages, update the code to match the new expected behavior.

3. Parameters deprecated in socialize.getFriendsInfo

Who Will Be Affected: Anyone using the  socialize.getFriendsInfo  API may be affected.

Impact: 

The following request parameters will be ignored:  UIDs , requiredCapabilities , and  signIDs  when the value is set to  true
Note that when  signIDs  was set to true, the following response parameters were returned for every friend in the list. These will now be ignored: 

  • friendshipSignature
  • signatureTimestamp
  • friendshipSig
  • Timestamp
  • providerUIDSig

Why:  The  UIDs requiredCapabilities  and  signIDs  parameters were not used.

Action Required : If your code depends on either the  UIDs requiredCapabilities , or signIDs  parameters, remove these parameters from your code.

4. Error code changes to accounts.getConflictingAccount

Who Will Be Affected: Anyone using the  accounts.getConflictingAccount  API.

Impact:  When the API is sent without a  regToken , it will return error code  400002  instead of error code 400006.

Why: More informative, helpful error messages.

Action Required : Update your code to handle the 400002 error code.

5. Security requirements for socialize.addConnection

Who Will Be Affected:  Anyone using the  socialize.addConnection  API. 
Impact  :  You can pass the  oauth_token  parameter only over HTTPS. Requests over HTTP will return an “invalid_token” error (error code 403025). 
Why:  Enhanced security. 
Action RequiredMake sure calls to socialize.addConnection are made over HTTPS when passing the oauth_token parameter.
 

6. Error Code Change in accounts.login

Who Will Be Affected: Anyone using the accounts.login API.

Impact: When CAPTCHA verification fails, will return error code 400021, instead of the previous 400009.

Why: More informative message prompts the correct user action.

Action Required: Update your code to handle the 40021 error code.

7. Changed error code in accounts.registerCounters, accounts.unregisterCounters and accounts.incrementCounters

Who Will Be Affected: Anyone using these APIs.

Impact: When a request is sent without the counters parameter, the error code will now be 400002 - “Missing required parameter”, instead of the previous error code 400006 - “Invalid parameter value”.

Why: More informative message.

Action Required: Update your code to handle the 400002 error code.

8. Changed functionality of accountUpdated Webhooks event

Who Will Be Affected: Anyone tracking the accountUpdated Webhooks event.

Impact: You will no longer be able to track logins using the accountUpdated event. Instead, use the new accountLoggedIn event.

Why: To enable tracking events in a more nuanced way, the accountUpdated event was separated into two events:

  • The existing accountUpdated event, which fires every time the account is updated, excluding login events.
  • A new accountLoggedIn event, which fires every time the user logs in

Action Required: If you are using the accountUpdated event to track account logins, update your code to use accountLoggedIn for these events, instead. In addition, any notification URL currently subscribed to the accountUpdated event will be automatically subscribed to the accountLoggedIn event. 

For more information, see Webhooks.


Monday, March 27, 2017

1. The OpenId Connect Relying Party (OIDC RP) redirectUri has been changed

Who Will Be Affected: All existing OIDC RP implementations.

Impact: Existing OIDC RP implementations were configured with a different redirectUri. Now that the redirectUri has been changed, users will not be properly redirected after login and the logins will fail.

Why: To aid in the reporting of OIDC logins.

Action Required: You must change the redirectUri registered with your OpenId Provider from https://socialize.us1.gigya.com/GS/GSLogin.aspx? to https://socialize.us1.gigya.com/socialize.finalizeOidcLogin?, or if you’re using a CNAME, from https://<CName_alias>/GS/GSLogin.aspx? to https://<CName_alias>/socialize.finalizeOidcLogin? .

2. The socialize.exportUsers API is being deprecated

Who Will Be Affected: Anyone using the socialize.exportUsers API.

Impact: Starting April 10th, 2017, calls to this API will fail.

Why: To improve efficiency and de-duplicate API functionality.

Action Required: Locate any references to the above API and replace them with ids.search.

Old Request - socialize.exportUsersNew Request - ids.search

curl --request POST
--url https://socialize.us1.gigya.com/socialize.exportUsers
--header 'content-type: application/x-www-form-urlencoded'
--data-urlencode apiKey=’<APIKEY>’
--data-urlencode userKey=’<USERKEY>’
--data-urlencode secret=’<SECRET>’
--data-urlencode format=’json’
--data-urlencode fields=’uid, provider, providerUID’

curl --request POST
--url https://ids.us1.gigya.com/ids.search
--header 'content-type: application/x-www-form-urlencoded'
--data-urlencode apiKey=’<APIKEY>’
--data-urlencode userKey=’<USERKEY>’
--data-urlencode secret=’<SECRET>’
--data-urlencode format=’json’
--data-urlencode query=’select UID, identities.provider, identities.providerUID from accounts'

ids.search returns JSON and not csv. If your current workflow requires csv, you can convert the JSON response using any number of online tools.

 

Thursday, December 01, 2016

1. The Activity Feed Add-On is Being Deprecated

Who Will Be Affected: 

Impact: Any elements powered by the above REST or JS APIs will cease to function, and any calls to those APIs will be ignored.

Action Required: Locate and remove the above APIs from your site’s code.

2. Live Chat is Being Deprecated

Who Will Be Affected: 

  • Anyone using any chat API (the entire chat namespace is being deprecated).
  • Anyone using reports.getChatStats.

Impact: Any elements powered by the above APIs will cease to function, and any calls to those APIs will be ignored.

Action Required: Locate and remove the above APIs from your site’s code.

3. The Follow Bar Add-On is Being Deprecated

Who Will Be Affected: Anyone using socialize.showFollowBarUI.

Impact: Any elements powered by the above API will cease to function, and any calls to that API will be ignored.

Action Required: Locate and remove the above API from your site’s code.

4. The Friend Selector Add-On is Being Deprecated

Who Will Be Affected: Anyone using socialize.showFriendSelectorUI.

Impact: Any elements powered by the above API will cease to function, and any calls to that API will be ignored.

Action Required: Locate and remove the above API from your site’s code.

5. Some Socialize APIs are Being Deprecated

Who Will Be Affected:

Impact: Any elements powered by the above REST or JS APIs will cease to function, and any calls to those APIs will be ignored.

Action Required: Locate and remove the above APIs from your site’s code.

The above APIs will be deprecated as of December 1st, 2016.
After that date, they will be removed from the Gigya platform without further notice. 

 

 

Monday, September 26, 2016

1. Password length limited to 100 characters and later on to 30 characters

Who Will Be Affected:

At phase 1 (v6.4): Users who have a password longer than 100 characters, or wish to create an account with a password longer than 100 characters.

At phase 2 (April 1st or later): Same thing, but down to 30 characters.

Impact:

Users with passwords longer than 100/30 characters will not be able to log in and will need to reset their password.

Action Required:

We believe that in phase 1, there’s no required action since there are practically no users with passwords longer than 100 characters.

In phase 2, still, almost no users will be affected. However, sites that wish to present a unique message to users that try to login with a password longer than 30 characters will get a new error code when such a login occurs and will be able to present a unique message such as “Please choose a new password that is up to 30 characters long. Click here to reset your password”.

 

2. Password hash no longer returned by accounts.getAccountInfo

Who Will Be Affected:

Non-privileged users calling the accounts.getAccountInfo REST method and passing ‘password’ in the include parameter. Privileged users will continue to receive this data. A privileged user is defined as someone that passes an API key/partner secret or API key/user key/secret with the request.

Impact:

The accounts.getAccountInfo REST endpoint will no longer return the user’s password hash. No error will be returned, but ‘password’ will be ignored.

Action Required:

No action is required.

 

3. Usernames limited to 500 characters

Who Will Be Affected:
Anyone calling the accounts.register REST or JS methods and passing a username with more than 500 characters.

Impact:

You will no longer be able to register accounts with a username longer than 500 characters.

Action Required:

No action is required. Usernames longer than 500 characters will continue to work, but new ones cannot be created.

 

4. Changes to email address validation

Who Will Be Affected:
Anyone calling the accounts.register REST or JS methods and passing an email address containing a single character in the domain.

Impact:

Email addresses can no longer contain a single character in the domain part of the address (e.g. test@gigya.c)

Action Required:

No action is required. Accounts with email addresses containing a single character in the domain part of the address will continue to work, but new ones cannot be created. If a user attempts to register with an invalid email address, Gigya will return a validation error (error code 400009).

 

5. Deprecation of legacy identity providers

Who Will Be Affected:

Any customer passing one or more of the following providers in any Gigya API call relying on authentication: Kaixin, VZNet, TypePad, Verisign, LiveJournal, MySpace, Skyrock, Digg, OpenID or Signon. (Please see “API calls that will be affected” below, for a detailed list of affected APIs.)

Impact:

  1. If you try to log a user into or add a connection to an unsupported network via the REST or JS API, the call will not be performed and you will receive an error message indicating the provider is not supported.

  2. The unsupported networks will not be displayed in our UIs (via the JS API).

For example, if you pass Kaixin as a provider, the login widget will appear as follows:

Kaixin

Action Required

  1. Remove the deprecated social networks from x_provider, provider, enabledProviders and providerSessions, in any Gigya API call.

  2. Encourage users who log in with these social networks to add a connection to another social network. This can be accomplished by displaying the Add Connections UI (remember to set requiredCapabilities to ‘login’) when a user logs in using any of the above social networks. By adding another connection that can also be used as a login identity, users will be able to retain site settings, achievements, social activities, etc. when logging in with the linked account in the future.

API Calls That Will Be Affected:

REST APIs:

accounts.socialLogin while passing any of the above social networks in x_provider.

comments.postComment while passing any of the above social networks in enabledProviders.

socialize.addConnection while passing any of the above social networks in x_provider.

socialize.login while passing any of the above social networks in x_provider.

socialize.getFriendsInfo while passing any of the above social networks in enabledProviders.

socialize.getUserInfo while passing any of the above social networks in enabledProviders.

socialize.removeConnection while passing any of the above social networks in provider.

socialize.notifyLogin while passing any of the above social networks in providerSessions.

 

JS APIs:

accounts.socialLogin while passing any of the above social networks in provider.

chat.showChatUI while passing any of the above social networks in enabledProviders

comments.showCommentsUI while passing any of the above social networks in enabledProviders.

socialize.addConnection while passing any of the above social networks in provider.

socialize.getFriendsInfo while passing any of the above social networks in enabledProviders.

socialize.getSessionInfo while passing any of the above social networks in provider.

socialize.getUserInfo while passing any of the above social networks in enabledProviders.

socialize.login while passing any of the above social networks in provider.

socialize.removeConnection while passing any of the above social networks in provider.

socialize.showAddConnectionsUI while passing any of the above social networks in enabledProviders.

socialize.showEditConnectionsUI while passing any of the above social networks in enabledProviders.

socialize.showFeedUI while passing any of the above social networks in enabledProviders.

socialize.showFriendSelectorUI while passing any of the above social networks in enabledProviders.

socialize.showLoginUI while passing any of the above social networks in enabledProviders.

socialize.showShareUI while passing any of the above social networks in enabledProviders.

 

6. Encryption to be Required on All Profile Fields Containing PII

We will be activating encryption on all profile fields containing PII, automatically, for all sites. You will not be able to disable this feature. Dynamic data fields will not be encrypted automatically.

The following profile fields will be encrypted automatically:

  • firstName

  • lastName

  • email

  • address

Impact:

All personally identifiable information (PII) contained in the above-mentioned profile fields will be encrypted automatically. Please note that this only applies to new data. Data stored previously will remain unencrypted.

Action Required:

If your implementation relies on queries that extract account data using partial searches of PII fields (e.g., SELECT * FROM accounts WHERE profile.lastName CONTAINS “David”), these queries will no longer return results, because you cannot perform partial searches on encrypted fields. For more information, see the Developer’s Guide.

 

7. Changes to New Registered Users and New Users by Provider reports

Who Will Be Affected:
Anyone using the New Registered Users or New Users by Provider reports.

Impact:

Due to a fix in the algorithm used to calculate new users, the New Registered Users and New Users by Provider reports will show lower new user counts from the date of this release as compared to previous periods.

Action Required:

No action is required. From now on, the above reports will automatically reflect new users based on the new algorithm.

 

Monday, March 28, 2016

1. Deprecating support for Comments version 1.

Who Will Be Affected: Anyone calling comments.showCommentsUI without passing the version parameter.

Impact: Comments version parameter will now default to 2 instead of 1. Any implementations that do not specify a version number will be automatically upgraded to Comments v2.

Action Required: Upgrade to Comments v2 and verify your implementation accordingly.

If you are using any of the below UI customizations on Comments version 1, your implementation will require special care to transition to version 2 in order to prevent a broken interface:

We encourage everyone to upgrade to Comments v2, but if you still want to use version 1, you will need to pass the version parameter with a value of 1.

  1. Though no sunset date has yet been set, we will stop supporting Comments v1 in the future, so you should plan your migration now.
  2. Comments v2 is supported by the latest browsers. Older browsers will automatically fallback to Comments v1.

 

2. New error code returned if you pass an object when an array is expected.

Who Will Be Affected: Anyone calling accounts.setAccountInfo or ids.setAccountInfo and passing dynamic data to a field of type array.

Impact: When passing a simple object to a field that expects an array, Gigya will now return error  400006 instead of error 500028. If your implementation specifically tests for error 500028, it will never find it, because the error code has now been changed.

Action Required: Update your implementation to test for error code  400006 instead of error code 500028.

 

3. CAPTCHA is now required for all shares via email

Who Will Be Affected:

Impact:

  • The useEmailCaptcha parameter will be ignored, and CAPTCHA will be activated automatically for all email shares.
  • When a user chooses to share via email, after filling in the email details and clicking ‘Send’, they will be presented with the CAPTCHA screen.

Action Required: No action is required. If you continue to pass the useEmailCaptcha parameter in socialize.showShareUI or socialize.showShareBarUI, it will be ignored. From now on, CAPTCHA will be automatically activated for all email shares.

SimpleShare_email.gif

After clicking ‘Send’, the user is presented with the CAPTCHA screen

email-captcha.png

Monday, November 09, 2015

1. Due to Twitter’s share button redesign, Twitter buttons will no longer display share counts as of November 09, 2015.

Who Will Be Affected:

Impact: Twitter share buttons will no longer return a share count. Gigya will remove share counts from the twitter button on your behalf on November 09. If your implementation relies on Twitter share counts, you will need to plan accordingly.

The native twitter-tweet button changes will take place on November 20, 2015.

Also, if you are using the native twitter-tweet button, note that Twitter has made some UI changes: the Tweet and follow buttons will switch to a modern, high-contrast design of white text on a dark blue background.

Action Required: Ensure that your implementation will not break without Twitter counter data. For example, if your implementation relies upon Twitter share counts to provide certain functionality, you will need to adjust accordingly.

If you call socialize.getProviderShareCounts and pass Twitter as the provider, the API will ignore the request but will not return an error. If you pass other valid providers, those will be processed. As a Best Practice, we recommend that you stop requesting share counts for Twitter at your earliest convenience.

Please keep in mind that there is no workaround. This capability is being deprecated by Twitter on November 20, 2015.

For more information, see the following links:

https://twittercommunity.com/t/a-new-design-for-tweet-and-follow-buttons/52791

https://blog.twitter.com/2015/hard-decisions-for-a-sustainable-platform