GConnector - CMS and E-Commerce Integrations

Skip to end of metadata
Go to start of metadata

Overview

GConnector is a tool that makes it easy to implement Gigya within a CMS or e-commerce platform, while leveraging the best of Gigya functionality without compromising the CMS capabilities. GConnectors share the same design principles. 

Benefits 

  • Scalable - including in multi-site, multi-CMS scenario
  • Seamless integration between Gigya and CMS identities for a smooth user experience
  • Fast implementation
  • Based on Gigya's best practices
  • Support for new CMS version releases
  • Cross-platform support of SSO (across different CMS systems)

Features  

  • Support for RaaS and Gigya plugins
  • Session management configuration
  • Secure encryption for app secret
  • Field mapping
  • Easy logging and debugging
  • Sync with Gigya's Data Store (DS)
  • Hooks for data transformation
  • Backoffice sync so as to display up-to-date user data in the CMS admin panel

GConnector Identity Data 

The main RaaS actions (i.e. login, register and edit profile) are mirrored in the CMS user management system. This is achieved by registering to Gigya’s onLogin event, and creating or updating a user account in the CMS. In the case of mismatching data (for example, the user's country is registered as France in Gigya's database and Germany in the CMS database), the Gigya data overrides that of the CMS. 

The flow when a user logs in is as follows: 

UID-Based Sync

Data sync between Gigya and the CMS is based on Gigya's UID. This way, user information is independent of any input provided by the user (such as name or email), and passed consistently between systems, so as to provide a seamless integration and improve the users' experience. The UID field is created automatically in the CMS when installing the GConnector. When configuring Gigya for CMS integrations, the email is always the login identifier (included in the loginID). 

We differentiate between two types of CMS: 

  • Email is required and unique (a user identifier in the CMS).
  • Username is required and unique (a user identifier in the CMS).

When Email is the CMS Identifier

When the user's email is an identifier in the CMS, by default, the CMS email field is mapped to the emails stored in Gigya's loginID. This cannot be overridden by field mapping. 

The login/registration flows in this case require that at least one email that is recognized in Gigya as a login identifier is unique to the user. After a user logs in or registers, the flow is as follows:

  1.  Following Gigya's onLogin event, the UID is passed. 
  2. The GConnector checks if the UID exists in the CMS database: 
    • Login: If the UID exists in the database, the system makes sure that at least one of the emails in the loginID is unique to this user, logs the user in and sets that email address in the CMS. If all of the user's loginID emails are saved to other users (other UIDs), the user will not be logged in, and will receive an error.
    • Register: If the UID does not exist, the system makes sure that at least one of the emails in the loginID is unique to this user, registers a new user and sets that email address in the CMS. If all of the user's loginID emails are saved to other users (other UIDs), the user will not be logged in, and will receive an error.

If you are using the profile.email Gigya data field, it should be mapped to a custom email field in the CMS, and not to the default required email field in the CMS.

When Username is the CMS Identifier

  1.  Following Gigya's onLogin event, the UID is passed. 
  2. The GConnector checks if the UID exists in the CMS database: 
    • Login: If the UID exists, the user is logged in. Data is updated according to this flow (required fields are updated before non-required).
    • Registration: If the UID does not exist, a new user is registered in the CMS. Data is saved according to this flow (required fields are updated before non-required).

Data Store Sync

When implementing Gigya's Data Store (DS) to store user-related data, GConnectors may offer a DS Sync module that adds the ability to pull data from Gigya's Data Store and map it into the user account database in the CMS. This is provided through an optional, separate package that is installed separately.

This capability is currently available for the following connectors:

Back End Sync

In some cases, the GConnector includes a module for synchronizing Gigya data to the CMS back end or back office, where CMS admins manage user data.

This capability is currently available for the following connectors:

Field Mapping

Fields in one database are dynamically mapped to the corresponding field in the other database. For examples, see Gigya Connector for Drupal 8Gigya Extension for Magento 2.0, and Gigya Connector for Sitefinity 9

By default, the GConnector usually maps the following fields for every user in every CMS: first namelast name, and email

Data Transformation Using Hooks

GConnectors usually offer the option of registering to specific events and adding custom code so as to transform data to the format required by the receiving platform. A common use case is transforming the user's birthday from 3 Gigya fields (profile.birthDayprofile.birthMonthprofile.birthYear)  into one CMS field (e.g., birthDate).

Security

Gigya is committed to maintaining the highest level of security. Our platform is designed to protect customer data with a series of strict security and compliance standards which are applied to our GConnectors as well. These include the following principles: 

  • The Application Secret is never used or stored in the CMS (session /cache/cookie etc.), but rather loaded from the database for each call. 
  • The Application Secret is encrypted in the database. 
  • Validates using accounts.exchangeUIDSignature
  • Gigya's Web SDK is loaded over HTTPS. 
  • Session expires automatically. 
  • Uses server-side calls when verified user data is required.
  • Server-side calls are signed.

Configuration Options

Generally, the GConnector configuration options (sometimes available within the CMS Admin area) align with those of Gigya's Global Configuration. In addition, they include

  • Field mapping 
  • Session management and session expiration settings 
  • Redirect and logout URLs

Multi-Site and SSO Support

GConnectors support multi-site implementations. Configuration for each site is independent, and in some cases sites can inherit configurations from a master site. In addition, SSO is supported by Gigya. For more information, see Site Groups and Single Sign-On 

GConnector Data Flow

The following diagram illustrates the typical data flow between Gigya (RaaS accounts namespace and Data Store) and the CMS (both client and server side), using the GConnector extension of the CMS. 

  • The Accounts namespace is where core Gigya user and identity data is stored, and includes the basic identifiers such as first and last name, email, UID and any other fields stored in the profile and data objects.
  • Gigya's Data Store (DS) is a premium product, an additional database with a flexible, dynamic schema. The DS part of the flow below is relevant only to customers who have implemented the Data Store.

For a list of links to the APIs participating in this flow and other relevant documentation, see below. 

APIs and Objects Used in GConnectors

Products

 

GConnectors

    
  

 

 

Save

Save

Save

Save

Other Gigya-CMS Connectors

In addition, Gigya offers the following CMS connectors. These connectors support some of the GConnector functionality but not all of it. For more details, click on the relevant CMS icon: