Database synchronization

In the SSO/registration scenarios when FM is a child, the following flows apply:

  • 1. New user registration on FM site.
    • a. User clicks Register button.
    • b. User is redirected to the registration page of the Master site with return URL specified on the query string.
    • c. User registers on the Master site. Upon the successful registration, the Master site posts user data to FM API using this API method.
    • d. User is then redirected back to the FM site using the return URL provided.
    • e. As an alternative to c) , the Master site exposes and API for FM to retrieve the user information. When the user is redirected back to the FM site after a successful registration, the user unique identifier from the Master database is passed along to the FM site. FM will then using this ID calls the Master API to retrieve the user info and saves it in the FM database.
  • 2. User profile updates.
    • a. User clicks on Edit profile on the FM site.
    • b. User is redirected to the Profile page of the Master site with return URL specified on the a query string.
    • c. When changes to the profile are saved on the Master site, the Master site posts user data to TL API using this method.
    • d. User is then redirected back to the FM site using the return URL provided.
    • e. As an alternative to c) , the Master site exposes and API for FM to retrieve the user information. When the user is redirected back to the FM site after a successful profile update, FM will then using the user ID call the Master API to retrieve the user info and saves it in the FM database.
  • 3. User registers on the Master Site.
    • a. Depending on the business need the Master site may or may not post the new user data to FM immediately. In the cases when only a subset of the Master DB is engaged in the loyalty program, the immediate synchronization is not necessary. Once the user navigates to the FM site for the first time, FM will add the record upon the successful login. The Master site in this case must expose the API described in 1e.
  • 4. User logs in on FM site. Both the Master site and FM site are on the same domain
    • a. User clicks Sign In button.
    • b. User is redirected to the Master site login page for authentication.
    • c. Upon the successful authentication against the Master DB, the user is redirected to FM with an encrypted cookie set.
    • d. The FM accesses the encrypted cookie created by the Master site and calls an API on the Master site, which decrypts the passed in cookie and returns the user unique identifier to FM.
    • e. The FM site logs the user in. If the user does not exist in the FM database (see 3a), FM will create the user record and log the person in.
  • 5. User logs in on FM site. FM authenticates against a Master service on a different domain.
    • a. User clicks Sign In button.
    • b.FM Sign In modal is displayed.
    • c. FM sends user credentials to the Master authentication service on a different domain.
    • d. Upon the successful authentication, the Master service returns an encrypted token, which FM sets as a cookie in the session.
    • f. FM calls an API on the Master site, which decrypts the passed in cookie and returns the user unique identifier to FM.
    • e. The FM site logs the user in. If the user does not exist in the FM database (see 3a), FM will create the user record and log the person in.As an alternative, the user click sign-in button on the rewards site, and we pop-up a window to load the master site’s login dialog. Once the user authenticates, the pop-up window will redirects back a page under FM rewards site’s domain with an authentication token on the query string. FM will then use the token to query the master site’s API to retrieve the member info.