SAP Customer Data Cloud Positions

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 the SAP Customer Data Cloud platform. 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 or open a support ticket.


SAP Customer Data Cloud Change Schedule

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


Monday, July 5, 2021

Deprecation of Legacy SDKs

Who Will Be Affected: Customers who use the legacy Android v3.x or Objective-C SDKs, will be affected.

Impact: On July 5, 2021, we will cease support for our Android v3 and Objective-C SDKs:

  • Support tickets for these SDKs will not be handled 
  • No backward compatibility or security features will be released for these SDKs


Why: SAP Customer Data Cloud has invested in new SDKs that support new technologies from Google and Apple, and function much more smoothly with our core capabilities, including support for Native Screen-Sets. Facing forward, we believe that investing resources in the newest and best is the right thing for our customers and platform, and are excited about feature releases that build on the new SDKs and enable you much greater flexibility and scalability in your mobile implementations.

Action Required: If your implementation still uses the legacy SDKs, migrate to the new SDKs by July 5, 2021.

 

Deprecated Webhook Versions 1.0 and 1.1

Who Will Be Affected: Customers who have not updated their downstream systems to expect Webhooks version 2.0 will be affected.

Impact: On July 5, 2021, we will no longer support sending Webhooks with a version number of 1.0 or 1.1.

Why: Webhooks version 2.0 and above is signed with a bearer token, which is considerably more secure. We want to encourage our customers to migrate to this version, but recognize that this requires implementation updates. Note that version 2.0 also includes version 1.1:

  • 1.1: Webhooks are fired also for lite account interactions, and include a callId
  • 2.0: Webhooks are signed with a JWT and include the API key of the site on which they were triggered

Action Required: Update your downstream application implementations to handle Webhooks version 2.0 (including 1.1).


Monday, February 8, 2021

Deprecation of Proprietary Sanitization of Profile Fields

Who Will Be Affected: Customers who rely on proprietary field sanitization when retrieving data from SAP Customer Data Cloud so as to display on a web page, using custom server or JavaScript code, may be affected.

Impact: Until now, SAP Customer Data Cloud applied automatic sanitization to some profile fields, e.g. escaping HTML characters. On February 8, 2021, we will stop applying the SAP Customer Data Cloud proprietary sanitization logic to saved data to the following profile fields:

  • profile.firstName
  • profile.lastName
  • profile.city
  • profile.country
  • profile.nickname
  • profile.username
  • profile.zip
This change does not affect Screen Set implementations as they correctly sanitize data on display. This only applies when retrieving data from SAP Customer Data Cloud so as to display on a web page, using custom server or JavaScript code.


Why:

  • Sanitization needs to be specific to the output channel (e.g. HTML, JS, email).
  • Proper sanitization is done on output, not input.
  • If you wish not to sanitize data, but to limit input to a specific dictionary (i.e. alphanumeric characters) a regex may be applied to schema fields.


Action Required: Apply your own sanitization to these fields. We recommend following OWASP best practices for input sanitization.


Sunday, January 31, 2021

Social Engagement Deprecation

On January 31, 2021, SAP Customer Data Cloud will be deprecating social engagement features and services. For more information about this deprecation, see Social Engagement Deprecation.


Monday, January 25, 2021

SSL Cipher Hardening

Who Will Be Affected: All customer implementations may be affected. 

Impact: On January 25 2021, SAP Customer Data Cloud is removing support for legacy TLS 1.0 and TLS 1.1 protocols, which are no longer considered secure, on our front-end servers, across all data centers. Going forward, we will be supporting TLS protocols 1.2 with specific ciphers.

Please note that API calls made with deprecated protocols, will fail. 

The following tables list the supported ciphers and those being deprecated:

In OpenSSL naming convention: 

Supported TLS v1.2 Ciphers
(from June 1, 2020)

Deprecated Ciphers
ECDHE-ECDSA-AES128-GCM-SHA256 

ECDHE-ECDSA-AES128-SHA

ECDHE-ECDSA-AES256-GCM-SHA384 

ECDHE-RSA-AES128-SHA

ECDHE-ECDSA-AES128-SHA256 

ECDHE-RSA-AES256-SHA

ECDHE-ECDSA-AES256-SHA384 

ECDHE-ECDSA-AES256-SHA

ECDHE-ECDSA-CHACHA20-POLY1305 

AES128-SHA

ECDHE-RSA-AES256-GCM-SHA384 

AES256-SHA

ECDHE-RSA-AES128-GCM-SHA256 

AES256-SHA256

ECDHE-RSA-AES256-SHA384  
ECDHE-RSA-AES128-SHA256  
ECDHE-RSA-CHACHA20-POLY1305  
AES256-GCM-SHA384  
AES128-GCM-SHA256  
AES128-SHA256  

 

In IANA naming convention: 

Supported TLS v1.2 Ciphers Deprecated Ciphers 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 
TLS_RSA_WITH_AES_256_GCM_SHA384 
TLS_RSA_WITH_AES_128_GCM_SHA256 
TLS_RSA_WITH_AES_128_CBC_SHA256 

 

Why: Increased security and better standards.

Action Required: Update your implementations to support the new protocols. The following servers are available for testing implementations. We recommend that your IT / R&D teams change configuration files accordingly, and run functionality tests to ensure your sites may run smoothly.

Data CenterTest IP
US118.210.152.0
EU134.241.4.148
AU154.79.56.25
CN147.103.95.152
RU195.213.238.68


Monday, September 14, 2020

Only Latin Alphabet Allowed in Schema Field Names

Who Will Be Affected: Customers that create custom schema fields with non-Latin alphabet letters may be affected.

Impact: Starting September 14, 2020, we will allow schema fields names to include only Latin alphabet letters, and other alphabets will not be supported. This applies to the creation of fields using the Schema Editor, accounts.setSchema, and accounts.setAccountInfo when a dynamic schema is enabled. Please note that existing fields will not be changed.

Schema fields:

  • May contain only Latin letters, digits, underscores "_", and/or periods "." (using periods in the field name will create a nested data structure).
  • Must begin with a letter.
  • Must be a minimum of 2 characters long.

Why: Platform consistency and best practice.

Action Required: Review your field creation flows and make sure they do not include creating a field that has special characters.

Monday, August 17, 2020

Placeholders Not Supported in Code Verification Email

Who Will Be Affected: Customers who use the email code verification flow and have included placeholders in the code verification email template.

Impact: On August 17, 2020, we will cease support for placeholders in the code verification email template. Any placeholders, e.g. $firstName, will not be populated with a value, and will be replaced by an empty string.

Why: Since this email is sent out before the registration / login is completed, the user is still considered “unknown” and the email will not reflect the account information.

Action Required: If your code verification email templates include a placeholder, remove them and replace them with actual text.


Monday, July 20, 2020

Deprecation of FTP Component in IdentitySync

Who Will Be Affected: Customers with existing flows that involve reading from FTP or writing to it will be affected. 

Impact: On July 20, 2020 IdentitySync flows will no longer be able to use the FTP components datasource.read.ftp and datasource.write.ftp. 

Why: FTP is considered less secure.

Action Required: Customers that currently use an FTP solution will need to update their flows to a different storage solution supported in IdentitySync, such as SFTP, Azure, S3 or Google Cloud. For the full list of supported components, see Component Repository.


Monday, June 29, 2020

id_token to Include Trailing Slash in API Response

Who Will Be Affected: Customers who validate JWTs received from SAP Customer Data Cloud may be affected. 

Impact: On June 29, 2020, the JWT returned from the following client-side APIs will include a trailing slash as the final character, in the issuer field of the JWT, in the following format:

Affected APIs: 

  • accounts.login 
  • accounts.verifyLogin
  • accounts.notifyLogin 
  • accounts.linkAccounts

Why: To match the response returned from accounts.getJWT, so as to successfully validate a JWT. 

Action Required: If you are using the include parameter of the above APIs to include an id_token in your response, update your code to expect the new format, by June 22 2020.

 

External (GitHub) Screenset Validation Extension Deprecation

Who Will Be Affected: Customers who use the Gigya Screen-set validation extension will be affected.

Impact: On June 29, 2020, the Gigya Screenset validation extension will no longer be supported. Instead, validations should be performed using our out-of-the-box Web SDK Screen-Set Events. The screen-set documentation also includes an example of implementing the same functionality described in the validation extension, using screen-set events.

Why: Consolidating SAP Customer Data Cloud solutions to out-of-the-box supported methods and events that are built in to our product.

Action Required: If you are using the external screenset validation extension, migrate your implementation to use out-of-the-box screen-set events.


External (GitHub) Markup Extension Deprecation

Who Will Be Affected: Customers who use the GitHub Markup Extension will be affected.

Impact: On June 29, 2020, the GitHub Markup Extension will no longer be supported. Instead, you may use existing methods. 

Why: Consolidating SAP Customer Data Cloud solutions to out-of-the-box supported methods and events that are built in to our product. 

Action Required: If you are using the external screenset validation extension, migrate your implementation to use out-of-the-box screenset events.

 

Monday, June 22, 2020

Email in LoginID to Be Saved in Lowercase Only

Who Will Be Affected: Implementations that rely on case-sensitive searches or retrievals may be affected. 

Impact: Starting June 22, 2020, user emails in the loginID field will be saved and returned only in lower case. Note that usernames are not affected.

Why: Previously, emails may have been returned only in lower case in some API calls (such as accounts.getAccountInfo), and may have included upper case letters in other API calls (notably, in accounts.search). This change fixes that. 

Action Required: Review your code and ensure all emails may be received and handled in lower case letters. Please note that searches (using accounts.search) are case sensitive. 

Redirect URL Validation on Mobile

Who Will Be Affected: Implementations of social login on mobile may be affected. 

Impact: By June 22, 2020, the following will occur: 

  • The checkbox Enable Mobile or Desktop Client Applications API Access on the Permissions page will be removed. 
  • SAP Customer Data Cloud will validate all URLs on social login redirects on mobile devices. See below for the required steps to ensure your mobile implementations continue to run smoothly.

Why: Increased security. 

Action Required

  • Open the Site Settings page of the Console and make sure that all the URLs that participate in the redirect social login flow are added to the list of Trusted Site URLs. For example: 
    • com.my.app://home_page 
    • Using a wildcard: com.my.app://* 
    • For Swift apps:  gsapi://*
    • For Objective-C, enter both gsapi://* and the bundle ID of your project (e.g., com.app.app://*)
  • On the same page, a temporary checkbox is added for validating URLs on mobile. This checkbox will be visible for sites for which the Enable Mobile or Desktop Client Applications API Access box was checked on the Permissions page. Use it to test your implementations and ensure login flows work as expected on mobile, prior to June 22.

Monday, May 25, 2020

Timestamp Format Change for audit.search

Who Will Be Affected: Implementations that pass a query to the audit log (including the consent vault) which includes a timestamp, may be affected.

Impact: Until now, audit log / consent vault queries that included a timestamp in an unsupported format, were treated like queries that do not include a timestamp and were allowed to run. On May 25, 2020, we will enforce the format of the timestamp used for querying the audit log (using audit.search), and return an error if an unsupported format is used. The supported format is: “yyyy-MM-dd’T’HH:mm:ss.SSS’Z’” (e.g., 2020-01-29T11:20:37.095Z).

Why: This is the expected behavior. Excluding a timestamp from a query may result in huge queries that have an impact on performance.

Action Required: If your implementation includes regular audit log queries, check the timestamp format and ensure it is correct.

 

Whitelisting IPs

Who Will Be Affected: Customers who maintain a whitelist of IP addresses for making API calls may be affected. 

Impact: On May 25, 2020, we will start using the following IP addresses as load balancers in our datacenters. 

Why: Platform stability and flexibility. 

Action Required: If you are whitelisting IP addresses, please add the below SAP Customer Data Cloud addresses to your existing whitelists. For the full list, see our developer’s guide:

USEUAUCNRU

52.6.26.84
34.195.47.15
3.221.10.189
18.213.25.247
54.156.43.185
34.225.174.66
3.224.65.44
52.206.129.214
50.16.48.161
18.215.54.106
52.20.216.25
34.225.149.206
34.237.146.47
54.161.111.152
52.207.159.21
34.230.143.213
18.205.216.249
35.171.212.167
3.228.82.127
52.201.178.222
18.209.151.69
52.6.224.59
52.3.218.124
3.219.104.30
54.152.45.26
3.210.106.177
18.232.202.52
3.212.31.166
3.210.194.15
18.210.129.238
3.95.78.149
18.210.166.88
3.222.201.219
23.20.32.15
54.208.42.61
3.218.242.64
3.210.215.98
50.19.195.148
3.211.165.106
3.213.33.94

54.194.222.9
18.203.197.165
34.241.90.83
52.18.169.88
54.194.21.199
34.250.47.16
52.212.8.161
34.240.223.46
52.209.186.86
52.18.11.120
52.212.46.3
52.49.135.37
54.171.56.227
54.171.78.88
54.229.36.147
52.49.85.76
54.171.58.75
52.18.227.38
54.171.54.74
54.171.78.95

52.63.21.113
52.64.41.144
13.239.101.5
3.24.152.14
13.237.35.75
54.79.56.25
3.25.12.237
13.239.50.99
52.62.188.46
13.237.223.3

101.133.232.100
101.133.239.21
101.133.238.34
101.133.238.189
101.133.234.145
101.133.236.42
101.133.236.48
47.103.95.152
101.133.236.186
47.100.37.57
101.133.212.98
139.224.234.53

82.202.216.216/29
185.143.175.208/29
95.213.250.240/28
95.213.238.64/28
95.213.253.40/29
95.213.238.40/29

 

Error Code Change for accounts.importFullAccount

Who Will Be Affected: Customers with recurring import dataflows who expect to receive a specific error code, may be affected. 

Impact: On May 25, 2020, error code behavior when using accounts.importFullAcount will change to the following:

  • Error code 206004 will be returned if the imported identity conflicts with an existing social identity 
  • Error code 400003 will be returned if the imported identity contains an existing email or username 

Why: Clearer flow and platform alignment. 

Action Required: If you have an implementation that uses accounts.importFullAccount (as an API call or using IdentitySync), make sure you do not expect to receive the 206004 error code. Generally, we recommend that your code should be able to handle/ignore error codes gracefully.

 

Monday, May 11, 2020

Certificate Update to US Data Center

SAP Customer Data Cloud is switching the root certificate provider for all our data centers, from Comodo to Digicert. Please note that the Digicert certificate is already an integrated part of our client-side SDKs and has been for several years – so for the most part, the impact to your implementations is low.

Who Will Be Affected: Implementations in the US data center may be affected.

Impact: On May 11, 2020, we will switch the root certificate provider for our US data center.

Why: Routine certificate update.

Action Required: If you have an implementation in the US datacenter, test your implementation using the following test server: 34.231.231.19. If any issues arise, please Open a support incident.

 

Monday, May 4, 2020

Certificate Update to EU Data Center

SAP Customer Data Cloud is switching the root certificate provider for all our data centers, from Comodo to Digicert. Please note that the Digicert certificate is already an integrated part of our client-side SDKs and has been for several years – so for the most part, the impact to your implementations is low.

Who Will Be Affected: Implementations in the EU data center may be affected.

Impact: On May 4, 2020, we will switch the root certificate provider for our EU data center.

Why: Routine certificate update.

Action Required: If you have an implementation in the EU datacenter, test your implementation using the following test server: 18.203.71.102. If any issues arise, please Open a support incident.

 

Monday, April 27, 2020

Certificate Update to AU Data Center

SAP Customer Data Cloud is switching the root certificate provider for all our data centers, from Comodo to Digicert. Please note that the Digicert certificate is already an integrated part of our client-side SDKs and has been for several years – so for the most part, the impact to your implementations is low.

Who Will Be Affected: Implementations in the AU data center may be affected.

Impact: On April 27, 2020, we will switch the root certificate provider for our AU data center.

Why: Routine certificate update.

Action Required: If you have an implementation in the AU datacenter, test your implementation using the following test server: 13.238.163.152. If any issues arise, please Open a support incident.

 

Monday, April 20, 2020

Certificate Update to CN Data Center

SAP Customer Data Cloud is switching the root certificate provider for all our data centers, from Comodo to Digicert. Please note that the Digicert certificate is already an integrated part of our client-side SDKs and has been for several years – so for the most part, the impact to your implementations is low.

Who Will Be Affected: Implementations in the CN data center may be affected.

Impact: On April 20, 2020, we will switch the root certificate provider for our CN data center.

Why: Routine certificate update.

Action Required: If you have an implementation in the CN datacenter, test your implementation using the following test server: 101.132.175.108. If any issues arise, please Open a support incident.

Monday, March 30, 2020

1. SSO Methods Deprecation

Who Will Be Affected: Existing SSO implementations may be affected.

Impact: On March 30 2020, we will no longer support accounts.setSSOToken and the public endpoint /gs/SSOGateway.aspx. As communicated above, on Safari and Firefox, these no longer work since August 2019, due to changes made by Apple and Mozilla to browser tracking capabilities.

Why: Triggered by Apple and Mozilla's changes to browser behavior, and in anticipation of similar changes to be made by Google and Microsoft, we are ceasing support for existing SSO mechanisms and encouraging our customers to move to the single-domain or centralized login domain approach.

Action Required: Migrate your SSO implementations according to the guide provided here.

2. SSO: User Will Not Be Logged in If Session is Invalid

Until now, in certain edge cases, when a user was logged into one site ("site A") of an SSO group and moved to another ("site B"), if the user's session on site B was invalid (for example, if they were missing required schema fields), they may have skipped the session validation (e.g., not submitted required fields in a Registration Completion screen) and still had a valid session. This change fixes that behavior.

Who Will Be Affected: Site groups whose implementation depends on having an active user session on a given page (e.g. initiated calls to accounts.setAccountInfo) may be affected..

Impact: On March 30, 2020, we will ensure that users who move between sites in an SSO group, are considered logged in only after their session is validated.

Why: This is the expected behavior for SSO.

Action Required: If you have SSO groups with different validation requirements for the different sites, review your site pages and make sure you do not expect users to have a valid session on the page before they pass validation.

 

3. Certificate Update to RU Data Center

SAP Customer Data Cloud is switching the root certificate provider for all our data centers, from Comodo to Digicert. Please note that the Digicert certificate is already an integrated part of our client-side SDKs and has been for several years – so for the most part, the impact to your implementations is low.

Who Will Be Affected: Implementations in the RU data center may be affected.

Impact: On March 30, 2020, we will switch the root certificate provider for our RU data center.

Why: Routine certificate update.

Action Required: If you have an implementation in the RU datacenter, test your implementation using the following test server: 95.213.238.72. If any issues arise, please Open a support incident.

Monday, February 10, 2020

1. Tag Change for Custom Buttons in Social Login UI

Who Will Be Affected: Customers who use custom code with custom buttons in their social login UI may be affected.

Impact: On February 10, 2020, in the social login UI, the classification of custom buttons will change from an 'img' tag to 'button' tag. 

Why: This change is required for better WCAG compliance. 

Action Required: Review your login UI and make sure to update any code that expects an image tag for custom buttons, to a "button" tag.

 

2. Password Complexity Will Return Validation Error

Who Will Be Affected: Implementations that use our screen-sets and have custom code around screen-set events may be affected.

Impact: Currently, password complexity requirements are enforced only for registration. On the 10th February, 2020, update profile and change password screens will display an error when password complexity requirements are not met, where previously no error was displayed before form submission. 

Why: The expected behavior is to enforce complexity requirements on all password related flows. 

Action Required: Check your code and make sure you do not rely on specific events around password change flows. A temporary parameter, toggles.alwaysValidatePassword, has been made available in the WebSDK Configuration (previously Global Configuration). When set to "true", screen-sets will behave according to the new behavior. After February 10 2020, this will become the default behavior and the temporary parameter will be removed.

 

3. gigya.auth.loginToken.getTokenParam to be Removed from the Web SDK

Who Will Be Affected: Implementations that rely on this specific method will be affected.

Impact: On February 10, 2020, we will remove this method from the Web SDK. 

Why: This method is part of legacy code and is not required or used by the SDK. 

Action Required: Review your implementations and ensure that your code does not use the gigya.auth.loginToken.getTokenParam.

 

4. End of Support for socialize.getUserSettings and socialize.setUserSettings

Who Will Be Affected: Customers who use these methods will be affected.

Impact: On February 10, 2020, we will cease support for socialize.getUserSettings and socialize.setUserSettings.

Why: As platform capabilities for setting and getting user data have grown and become more sophisticated, these methods are no longer in use.

Action Required: Review your code and ensure it does not use either of these methods.

 

5. UI Builder: Removing Class "sortable-drag"

Who Will Be Affected: Some implementations using custom CSS in the UI Builder may be affected.

Impact: On February 10, 2020, this class will no longer be supported.

Why: Bug fix.

Action Required: If you have custom code around screen-sets, review your code and make sure it does not use the 'sortable-drag' class.

6. Changed Cookie Values Encoding

Who Will Be Affected: We do not anticipate affected customers, as we always recommend that customers never use the data stored by a Gigya cookie for their own business logic.

Impact: On February 10, 2020 we will change cookie values encoding from escape to encodeURIComponent.

Why: The "escape" function is a deprecated web standard and less compatible with language codes.

Action Required: Review your code and make sure this change does not break your implementation.

7. Renaming Internal Parameter: dontHandleScreenSets

Who Will Be Affected: Implementations that rely on the internal parameter dontHandleScreenSets will be affected.

Impact: On February 10, 2020 we will rename dontHandleScreenSets to ignoreInterruptions.

Why: As this parameter will have a wider functionality of interruption handling, we are renaming it to a more accurate name.

Action Required: If your code uses dontHandleScreenSets, rename the parameter to ignoreInterruptions.


8. Remove 'i' Icon From Photo Widget

Who Will Be Affected: Implementations that use custom logic for screen-set implementations may be affected.

Impact: On February 10, 2020 we will remove the element with the class gigya-myPhoto-status-icon and all its children, from the photo widget on the Profile Update screen.

Why: As part of the code cleanup, we are removing unnecessary and unused elements from our code and screens.

Action Required: If you have custom code that depends on our screen-sets, review your implementation and make sure to remove any usage of the gigya-myPhoto-status-icon class.

 

9. Changed Behavior in TFA Screen

Who Will Be Affected: Customers that rely on specific behavior in the "Secure Your Account" screen may be affected.

Impact: On February 10, 2020, the focus will be removed from the second input field in the "TFA Registration" screen in the registration-login screen-set.

Why: Better WCAG compliance.

Action Required: Check your implementation and make sure it does not rely on the existing screen behavior.

 

10. Console to Switch to TLS 1.2

Who Will Be Affected: We do not expect Console users to be affected.

Impact: On February 10, 2020 we will enforce TLS 1.2 on the SAP Customer Data Cloud Console.

Why: Increased security and better browser standards.

Action Required: Make sure the browser you are using to access the Console supports TLS 1.2. This is a widespread standard, so we do not anticipate any issues.

 

Monday, November 25, 2019

httpStatusCodes will Return Codes

Who Will Be Affected: Any implementation passing httpStatusCodes=true and expecting to receive only a HTTP "200" response will be affected.

Impact: On November 25, 2019, setting the httpStatusCodes parameter to "true" in our REST APIs, will be corrected to the expected behavior.

Why: The expected behavior of the httpStatusCodes parameter is that when set to "true", the HTTP status code in SAP Customer Data Cloud's response would reflect an error, if one occurred. However, in some cases, when set to "true", this parameter continues to return a response of "200". This fix changes that.

Action Required: Review your code and make sure it does not expect to receive only a "200" response from the SAP Customer Data Cloud HTTP status code.

 

New Error Codes for Embargoed Countries Login Flows

Who Will Be Affected: Implementations that rely on receiving the 403051 code in the response of a login flow will be affected.

Impact: On November 25, 2019, the following error codes will be returned from login flows:

  • 451001 - "Access has been denied"
  • 451002 - "Login has been denied"
  • 451003 – "Login has been denied"


Why: SAP policies for embargoed countries.

Action Required: Review your code and update the flows that involve the 403051 code.

Monday, November 11, 2019

Object Fields in Profile Object

Who Will Be Affected: Any implementation that uses data in the fields outlined below, may be affected.

Impact: On November 11, 2019, we are changing the way existing data is handled for the following JSON object fields in the profile object. Previously, any data written to a field in the object, would nullify data that was already saved to other fields in the object. For example, if the first call wrote a value to “likes.id” and a second call wrote a value to “likes.name”, the second call would also remove the existing “likes.id”. This changes fixes that behavior. The relevant fields:

  • Certifications
  • Education
  • Likes
  • Patents
  • Phones
  • Publications
  • Skills
  • Work

Why: This behavior did not match the intended design and therefore is a bug fix.

Action Required: Check to see if your implementation relies on the old behavior. If it does, change your implementation to match the new behavior.

Monday, October 28, 2019

New SMTP Mail Servers

Who Will Be Affected: Customers who use their own SMTP servers to send SAP Customer Data Cloud emails will be affected.

Impact: New IP addresses will be rolled out for email relay to the following data centers on the following dates:


AU1 – October 28, 2019
13.238.247.161
52.62.123.56
13.237.130.60
52.63.248.45

EU1 – October 30, 2019
52.213.224.81
3.248.150.41
54.246.201.168
108.128.177.17

US1 – November 4, 2019
3.230.65.173
18.211.233.189
52.200.102.20
34.237.168.152

Why: To improve load efficiency of our mail servers. 

Action Required: If you are using email forwarding (SMTP relay) to send emails from your own servers, the above addresses should be added to your whitelist by the specified dates.

Internet Explorer No Longer Supported for SAP Customer Data Cloud Console

Who Will Be Affected: Any users of the SAP Customer Data Cloud Console may be affected.

Impact: Managing your SAP Customer Data Cloud sites is no longer supported on Internet Explorer, and issues may occur when doing so. 

Why: Following the 2015 release of Microsoft Edge to replace Internet Explorer (IE), there has been a steady decline in IE usage by end users. In addition, Microsoft's investment in IE has ceased, and they officially discourage using Internet Explorer as a default browser. Therefore, we no longer officially support using the SAP Customer Data Cloud Console on Internet Explorer and will not resolve bugs or issues concerning Console usage with IE.

Action Required: Console users should switch to other browsers: Edge, Chrome, Firefox and Safari.

 

Apple App Store Approval Requirements

Apple has announced the following prerequisites for App Store approval:

  • Apps must not include the UIWebView.
  • Apps that offer social login, must also include the Apple Sign-In option.

Who Will Be Affected: Customers who use the Swift and Objective C SDKs will be affected.

Impact

  • Apps using older versions of SDKs will be rejected by Apple.
  • Apps that do not include “Sign in with Apple” will be rejected by Apple.

Why: Strategic Apple decision.

Action Required:

  • Migrate your apps that use the Swift and/or Objective-C SDKs, to the new SDKs available on our Developer’s Guide, that support WKWebView and not UIWebView.
  • Integrate “Sign in with Apple” to your social login offering.

 

August 2019

Browser Support for SSO

Since August 2019, SSO between different domains does not work on Safari and Firefox browsers, due to tracking prevention features that target adtech. These browser changes impact SSO capabilities offered by many CIAM vendors, including SAP Customer Data Cloud. To enable SSO in these situations, follow this guide.

 Why is SSO not working on Safari?

 Due to enhancements in Apple's Intelligent Tracking Prevention capabilities to prevent Cross Site Tracking in Safari, our SSO solution will no longer work.

Apple's ITP release schedule – note that SSO impacting features were only released in the latest iteration of ITP changes:

June 2017  https://webkit.org/blog/7675/intelligent-tracking-prevention/

Mar 2018  https://webkit.org/blog/8142/intelligent-tracking-prevention-1-1/

Jun 2018  https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/

Feb 2019  https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

April 2019  https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/

Aug 2019  https://webkit.org/tracking-prevention-policy/

 Why is SSO not working on Firefox?

Firefox, like Apple, have implemented Cross Site Tracking Prevention capabilities, that prevent our current SSO solution from working.

Timeline:

  • January 28th 2019 – version 65.0, Enhanced Tracking Protection: Simplified content blocking settings give users standard, strict and custom options to control online trackers
  • June 4th 2019 - version 67.0.1, Enhanced Tracking Prevention (ETP)
  • September 3rd 2019 – version 69, ETP with stronger protection:
    • Default setting for this feature now blocks third-party tracking cookies and cryptominers
    • Optional strict setting blocks fingerprinters
 Backround about Intelligent Tracking Prevention (ITP)

Apple first launched ITP in Safari browsers in 2017, with the goal of reducing the number of tracking mechanisms that are available to advertisers and technology companies, so as to protect the privacy of their users and improve the browsing experience. Safari as a platform has always blocked 3rd party cookies. SAP Customer Data Cloud previously had workarounds using CNAMEs to allow an SSO experience to end users.  ITP's first restriction pertaining to SSO was to only allow a 24 hour period where the first party cookie could be accessed in a third party context. SSO was not impacted (most logged in sessions would expire after 1 hour of inactivity or when the browser closes), so there was no need to make changes to the SAP Customer Data Cloud platform.

 Why are Safari and Firefox implementing further changes now?

Typically, cookies are there to enhance your browsing experience to store login data, session information etc. Over the years, this functionality has been leveraged for advertising and to track users across multiple domains in an aggressive way, rather than to enhance user experience in a positive way. A typical example of negative experience is viewing a product on one website, then seeing an ad for that product on an unrelated site. This type of aggressive advertising makes users feel uncomfortable about their privacy when browsing sites and concerned about how their data is used. Apple and Mozilla have been at the forefront of looking at ways to protect their users' privacy and in doing so have developed tracking prevention capabilities into their browsers.

Google and Microsoft have announced that they will be working on similar features for their browsers to protect their privacy of their users. So that going forward, not only SAP Customer Data Cloud, but all CIAM vendors, will be looking at alternate ways of implementing SSO.

 How will this impact end-users?

Unless you implement the workaround for this issue, end users will no longer be able to log into Brand A’s website and be automatically logged into Brand B’s website, on Safari and Firefox browsers. In any case, the end-user will still be able to have a single set of credentials and a single account to log in to both A and B independently.

 Are other web products impacted by this change?

Many web applications and CIAM vendors are impacted by these changes. Specifically, any solution that manages SSO sessions using cookies, similar to SAP Customer Data Cloud, is also impacted by cross site tracking prevention. 

 Will there be a fix for this?

We suggest using this implementation approach, and staying in touch with our teams, as well as following this page for possible future adjustments.

 What else can be done?

If your implementation is impacted, we recommend reaching out to your Customer Engagement Executive or open a support ticked to discuss any immediate concerns. We would very much like to know about your specific use case, as this helps us validate our proposed solutions and come up with a plan that suits your needs.

Monday, September 2, 2019

New IP Addresses

New load balancer IP addresses added to our Russia and China datacenters. For a full list of SAP Customer Data Cloud IPs, see Whitelisting Gigya IP Addresses

RU1
95.213.238.74
95.213.250.245

CN1
139.224.134.172
139.196.120.165

Monday, May 27, 2019

Social Login Initiation Domain Validation

From 27 May 2019, all websites (domains) that initiate Social Login will need to be explicitly whitelisted in the Gigya Admin Console. Domain validation is already in place for redirects on social logins, so this change only applies to social logins which redirect to a different domain from where they were initiated. For example, if site A initiates Social Login, and redirects to site B for that purpose, the domains of both A and B need to be added to the list of trusted sites in Gigya’s Admin Console.

Who Will Be Affected: Customers with a live implementation of social login that is triggered from a domain that is not whitelisted on the API key.

Impact: Following this change, if a customer does not whitelist a domain that initiates social login, end users will not be able to use social login on that website.

Why: This change further enhances security for social logins.

Action Required: For all of your websites which initiate Social Login:

  1. Open Gigya’s Admin Console in the “Site Settings” page
  2.  Make sure all domains that are related to your Social Login flow are listed under “Trusted Site URLs”:

  3. Repeat for any relevant sites (API keys)

The license could not be verified: License Certificate has expired!

Monday, April 8, 2019

Minor Change to Consent Enforcement in Registration

Previously, end-users could complete registration on a child site with a mandatory “other” consent statement without agreeing to that statement, if it was not required on the parent site. This change fixes that.

Who Will Be Affected: Customers with a live implementation of Customer Consent may be affected.

Impact: Following this change, end-users who have previously registered on a child site, may be required to grant consent to all the mandatory site terms, via the “Registration Completion” screen of your site.

Why: This change ensures that agreeing to the site mandatory “other” statements is a pre-condition for site registration.

Action Required: Review your implementation and make sure any mandatory consent statements checkboxes are visible in the “Registration Completion” screen. This ensures that users may grant consent and continue using your site services.

Monday, January 21, 2019

XML Format No Longer Returned in Socialize Responses

Previously, many socialize APIs allowed a value of 'xml' in the format parameter, and used this value as the default unless specified otherwise. Following this change, the 'xml' value will no longer be supported, and all responses will be returned in JSON or JSONP.

Who Will Be Affected: The following customer implementations may be affected:

  • Implementations of the socialize REST APIs that do not pass any value for the format parameter
  • Implementations of the socialize REST APIs that explicitly pass a value of xml for the format parameter

Impact: On January 21, 2019, we will no longer send a response in XML format from our APIs. All responses will be returned in JSON. This has an impact on REST APIs in our socialize namespace.

  • The xml value of the format parameter in APIs will no longer be supported (e.g., in socialize.notifyLogin).
  • The default value of the format parameter will now be json.

Following are the affected REST APIs. Note that for most of these methods, the xml value of the format parameter has already been documented as deprecated:
socialize.deleteAccount
socialize.delUserSettings
socialize.getAvailableProviders
socialize.getContacts
socialize.getFriendsInfo
socialize.getRawData
socialize.getSessionInfo
socialize.getTopShares
socialize.getUserInfo
socialize.getUserSettings
socialize.logout
socialize.notifyLogin
socialize.notifyRegistration
socialize.publishUserAction
socialize.removeConnection
socialize.setStatus
socialize.setUID
setUserSettings
socialize.shortenURL

Why: We are changing the APIs in the socialize namespace to maintain consistency with all other namespaces, which do not return XML responses.

Action Required: Review your code that expects to receive a response from socialize REST APIs and make sure that it supports a JSON format.

Monday, November 19, 2018

1. Redirection in SSO Gateway 

Gigya will now enforce redirection only to a URL that is part of the site's (or site group's) base domain.

Who Will Be Affected: Any sites that implement SSO may be affected.

Impact: Starting November 19, 2018, Gigya will no longer allow open redirects during an SSO flow, but will validate that the base domain of the redirect URL belongs to the site or site group initiating the redirect.

Why: To align with security best practices and require only explicitly authorized redirect URIs. 

Action Required: Check the redirects configured in your SSO implementations, and make sure that all the base domains in those URLs are listed in the Settings page of Gigya's Console.

2. Changed Response Format of Preferences Object in accounts.login and accounts.verifyLogin

Who Will Be Affected: Any SAP Customer Consent customers may be affected.

Impact: On November 19, 2018, the format of the 'preferences' object returned in the response of accounts.login and accounts.verifyLogin will change from a flattened format, to a regular JSON.
Sample object before the change:

"preferences": { 
	"terms.my_terms_of_service": { 
		"isConsentGranted": true, 
		"docDate": "2018-01-01T02:00:00Z", 
		"lastConsentModified": "2018-09-03T13:45:02.376Z", 
		"tags": [], 
		"entitlements": [] 
	} 
}

Sample object after the change: 

"preferences": { 
	"terms": { 
	"my_terms_of_service": { 
		"isConsentGranted": true, 
		"docDate": "2018-01-01T02:00:00Z", 
		"lastConsentModified": "2018-09-03T13:52:48.005Z", 
		"tags": [], 
		"entitlements": [] 
		} 
	} 
}

Why: Standardization of API responses. 

Action Required: Review your code to see if it expects to receive the 'preferences' object in a flattened format for these APIs. If it does, update the code to expect a JSON format.

3. OIDC JWT to Return Integers, not Strings

Who Will Be Affected : Implementations of OIDC.

Impact: On November 19, 2018, the value of "exp" in OIDC JWT will be returned as integers, not strings.

Why: Compliance with OIDC protocol.

Action Required: If your site implementation includes an OIDC login, review your implementation and update it to receive integers in the exp parameter of the JWT.

4. Changes to Response Messages

As part of the new capability to edit user-facing messages in the reset password flow, existing response codes have changed.

Who Will Be Affected: Implementations that rely on receiving a specific response in a defined flow for response codes 403025 and 401030.

Impact: On November 19, 2018, these response codes will have changed messages. 403025 has also changed its functionality. The new responses:

  • 403025: "Uh-oh, your link is not valid. Restart the reset password flow to get a new link."
  • 401030: "You've already used that password. Please create a new one."

Why: As part of the improvement to the reset password flow, that allows admins to customize user-facing messages, these messages have changed.

Action Required: Review your code and check the flows that involve these response codes.


Thursday, October 11, 2018

  • StumbleUpon is no longer a supported social provider, as this network has ceased to exist. 


Tuesday, September 4, 2018

The following sections outlines the details of the change to Gigya's US data center, including new IP addresses, impact on the day of the switch, and frequently asked questions.

IP addresses: 

Load Balancers (HTTP/HTTPS):

52.2.141.183
107.23.218.60
18.209.204.66
18.210.235.241
18.205.77.36
18.211.61.121
18.210.153.8
107.23.67.121
18.206.141.83
54.88.149.194 
34.193.10.229
18.211.190.134
18.210.152.0
18.211.56.0


Staging (HTTP / HTTPS)

18.205.215.220
54.86.153.93
18.211.1.219
18.211.224.177
18.211.19.247

 

* NAT IPs:

52.204.240.189
18.208.46.48
54.227.162.232
23.20.2.50
54.175.227.163
18.210.248.215
18.211.46.230
34.237.6.119
34.238.1.105
35.153.145.8

* Used by Webhooks, IdentitySync, email share verification . (Social networks are also accessed through those IPs)


Mail servers (SMTP):
52.3.88.164 (gigya-ugc.com)
54.85.225.191(gigya-ugc.com)
18.210.84.72(gigya-raas.com)
18.210.223.137(gigya-raas.com)
54.86.176.109 (gigya-comments.com)
18.210.199.197 (gigya-comments.com)
18.209.203.238 (console.gigya.com)
54.83.168.120 (console.gigya.com)
52.7.57.9 (gigya-ext.com)
34.200.97.129 (gigya-ext.com)

If you have explicitly whitelisted any of Gigya's US IP addresses, you should not delete them from the whitelist, as they may still be in use.

Impact

During the cut-over window we anticipate a period of up to 2 minutes where connectivity to Gigya may be impacted. Users of Gigya’s Console may be logged out during that window.

FAQs

What action do I need to take?
Most likely, you will not need to take any action. However, if you have explicitly whitelisted any Gigya owned IP addresses for connections to or from the Gigya US1 datacenter, you must add the new Gigya IP addresses to your whitelisting settings before September 4th, 2018. The new IP addresses for whitelisting are provided above.

The following example scenarios would require your action:

  • If you have whitelisted Gigya IP addresses on your SFTP server to receive incoming files from IdentitySync
  • If you have whitelisted Gigya IP addresses to receive Webhooks notifications
  • If you have whitelisted Gigya IP addresses on your SMTP server which is relaying Gigya Registration-as-a-Service emails

Please note that if you have intentionally bypassed our CDN or DNS servers when making connections to Gigya, you should get in touch with your Account Manager.

What is the rollback plan for the changes?
The migration is done by pointing the load balancers and DNS records (after lowering the TTL) to Amazon Web Services (AWS) instead of the current primary datacenter and making the databases the master nodes in AWS. At this stage, the data will still be replicated between the datacenters, but in the opposite direction. In case rollback is needed, we will switch the configuration back as it was before the migration.

What is the disaster recovery plan and how has it changed?
At stage 1 we will have our primary datacenter work from the AWS N.Virginia region which will have full redundancy for all components, and the Equinix datacenter (current US primary datacenter) will become the disaster recovery. This is planned for September 4th 2018. In summary, we will be switching sites between our current primary datacenter (Equinix) and the disaster recovery datacenter (AWS).

At stage 2, we will work from multi availability zones in AWS which will provide another level of redundancy and after it’s fully operational we will stop using the Equinix datacenter for disaster recovery. This is planned for Q1 2019.

What kind of cutover validation will there be? How will you be validating that everything is working as expected?
The environment is built in a similar way to other working datacenters that we already have in AWS and with the exact same components and versions as we have in the existing DC.

In preparation, we are running extensive tests to verify that all of the
components are working as expected before allowing customer traffic through. Those tests include: functionality, performance, resilience and redundancy.

Will long life sessions still be active after the AWS migration?
Existing sessions and tokens will not be affected by the move. There may be two minutes during which users will experience connectivity issues.

Users will remain logged into the following:

  • Mobile sessions, including long-lived sessions
  • Web sessions, including SSO
  • Server side sessions
  • Sessions generated using OAuth 2.0 tokens
  • IoT sessions (e.g., Alexa OIDC)


Regarding NAT IPs, can we know which address is used for which service?

The new NAT IPs are a pool of IP addresses, and no address is specific for one service or application.

Which old IP addresses can be removed from whitelists?

Since the current datacenter will become the disaster recovery DC after the switch, you should keep existing IPs whitelisted as they are.

 

Wednesday, August 8, 2018

As previously detailed in our March Product Announcement, all Gigya Downloads are now only available via our official download site located at https://downloads.gigya.com.

If you are using any Gigya software (i.e., Mobile SDKs/Server SDKs/GConnectors) that are currently hosted on other services or repositories, be advised that all resources are now only available via the aforementioned site.

 

Wednesday, August 1, 2018

Facebook has deprecated the publish_actions scope. You should remove this scope from all of your Facebook apps to avoid warning messages and update any implementations that rely on it. This also means that certain Gigya features that use publishUserAction will cease to share to Facebook, to include: 

  • socialize.publishUserAction
  • socialize.showShareUI*
  • All Loyalty add-ons that rely on sharing
* If you are currently using socialize.showShareUI for Facebook shares, you can use socialize.showShareBarUI instead.
The following errors will be thrown, depending on the action: 
  • 403023 - No_user_permission 
  • 403022 - Permission_not_requested 
  • 403017 - Unexpected_provider_user 
  • 403026 - Unauthorized_access_error

Monday, June 11, 2018

1. AOL

The integration with AOL is no longer supported as AOL has stopped supporting OpenID integrations.

Who Will Be Affected: Any customer who has a Gigya integration with AOL.

Impact: Any usage of AOL as an identity provider will not function.

Why: AOL has ceased to support any OpenID-based integrations. In addition, as this integration has no adoption, we prefer to focus on integrations that bring higher value to our customers. 

Action Required: If your site uses AOL as an authentication option, you should remove that option, and encourage your users to use other identity providers instead.

2. OpenID-Based Integration with PayPal

The integration with PayPal that is based on OpenID has not been supported for a while, and was officially deprecated by PayPal on May 20th, 2018.

Who Will Be Affected: Any customer who has an OpenID based integration with PayPal.

Impact: This integration is no longer supported. 

Why: In accordance with changes to PayPal’s platform, Gigya’s integration with PayPal is based on OAuth v.2.

Action Required: If you are still using the OpenID-based integration with PayPal, follow the steps in our Developer’s Guide to set up your OAuth integration with PayPal instead.


Wednesday, March 28, 2018

1. Verification email will be sent out only after registration is final

Who Will Be Affected: The impact of this change should be minor. Some implementations that require email verification in their policies may be affected.

Impact: A verification email will now be sent out only once a user is successfully registered (i.e., the finalizeRegistration parameter of accounts.register is set to true, or accounts.finalizeRegistration is called and returns “account pending verification”), and no data is missing from the required fields in the schema. Note that the email will not be sent if the account is pending registration.

Why: To prevent confusion and an erroneous delivery of multiple verification emails.

Action Required: A verification email will no longer be sent unless finalizeRegistration is set to “true” and all the required fields are supplied. You should review your code and make sure there is no dependency that says otherwise.


2. Two-factor authentication now requires setting up a Twilio account

Who Will Be Affected: Any customers using SMS for two-factor authentication.

Impact: As of April 30, 2018, in order to send SMS messages for TFA, you will be required to have a Twilio account and provide those credentials via the Console.

Why: In an effort to support those customers that require access to two-factor authentication logs about delivery and configuration, we have changed the platform to require Twilio account details to be configured within the Gigya console. 

Action Required: In order to use the TFA service, you will need to obtain a Twilio account and enter those credentials in the Console. Gigya will use that account for sending TFA messages on your behalf.


3. When creating a new schema field, you are now required to set the type

Who Will Be Affected: Customers who have an automated process in place for schema field creation may be affected.

Impact: As of May 15th, when new schema fields are created, the type will need to be specified explicitly, rather than implicitly as was available before. If you do not set the type parameter, Gigya will respond with error code 400002 - Missing required parameter.

Why: To prevent errors and confusion when creating schema fields.

Action Required: Review your code and make sure that new schema fields are created with an explicit type, rather than relying on Gigya to infer the type the first time data is pushed to the field.


4. Custom Data and Data Store schema field limitation

Who Will Be Affected: Customers with a large amount of custom fields in their Data Store and ‘data’ schema may be affected.

Impact: A new limitation is in place. You can now have a maximum of 1500 custom fields in each of the ‘data’ namespace and the Data Store.

Why: This limitation is in place so as to provide better service and performance to our customers all around. The recently released ability to delete unused schema fields should minimize any negative impact this change might otherwise have.

Action Required: No action is required. If you are one of the few customers currently beyond the 1500 field maximum, your Account Manager will be reaching out to you directly to plan the next steps. In the interim there will be no disruption to your service.


Wednesday, November 15, 2017

UIDSignature and signatureTimestamp parameters no longer returned on server-side calls

Some of the most commonly used APIs that will be affected:

  • accounts.getAccountInfo
  • socialize.getUserInfo
  • ids.getAccountInfo

Who Will Be Affected: Anyone depending on receiving these parameters in server-side calls may be affected. 

Impact: These parameters are no longer returned on server-side calls Client-side calls will continue to return these fields as they do today.

Why: The parameters are not necessary in server-side calls, and those are made over a secure channel. 

Action Required: Review any code that calls these APIs and ensure there is no dependency on these parameters.


Monday, September 25, 2017

1. Partial clauses no longer supported in accounts.search and ds.search

Who Will Be Affected: Anyone using the accounts.search and/or the ds.search APIs may be affected.

Impact: These APIs no longer support passing a partial field name. For example, if up until today you could send ‘SELECT email’ in your request, you will now have to specify ‘SELECT profile.email’.

Why: As Gigya’s data structure grows in complexity and flexibility, we can no longer support partial requests.

Action Required: Review any code that calls these APIs and ensure the requests are phrased properly.

 

2. Changed behavior of isLockedOut parameter in API Responses

Who Will Be Affected: Anyone who uses APIs that include user info in their response may be affected. 

Impact: The isLockedOut status will be returned from API calls only when specified in the include parameter of methods that return a user object (such as accounts.getAccountInfo. Previously, it was always returned in the response of these APIs. In addition, the parameter is being wholly removed from the response of accounts.search, and cannot be included in the response. 

Why: This change has been implemented as part of a performance update when getting or searching for the account.

Action Required: Review your code and make sure it does not depend on returning the isLockedOut parameter by default. When specifically expecting to receive back the parameter, make sure to specify it in the include parameter of the API call. 

 

3. Changed status code and status reason in the response received for accounts.setProfilePhoto

Who Will Be Affected: Anyone using the accounts.setProfilePhoto API may be affected.

Impact: Instead of returning statusCode '0' and statusReason '0', the API will now return statusCode '200' and statusReason 'OK'.

Why: To maintain consistency with other API responses.

Action Required: Review your code and see whether it depends on receiving a specific statusCode and/or statusReason in the response from accounts.setProfilePhoto. If it does, anywhere that previously received statusCode '0' should now accept statusCode '200', and anywhere that previously received statusReason '0' should now accept statusReason 'OK'.


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.

 

This change does not affect Screen Sets as they correctly sanitize data on display. This only applies when data that returns from CDC is manually rendered on a website.