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, February 4, 2019

Hash Algorithm Changing for SAML Assertion

Who Will Be Affected: Implementations of SAML login that rely on using the SHA1 algorithm.

Impact: On February 4, 2019, we will be changing the algorithm used for signing the SAML assertion, from SHA1 to SHA256.

Why: Improved security.

Action Required: If your site implements SAML login, review the code and make sure it does not rely on the SHA1 algorithm. If your code expects a specific algorithm, it should be updated to SHA256.

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 of accounts.getAccountInfo, socialize.getUserInfo, and 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 of accounts.getAccountInfo socialize.getUserInfo, and ids.getAccountInfo 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.