All are my understanding, notes general concept, not detailed and not completely correct, so only for reference.

What is syndication

Due to the development of our products, we will connect with some third-party merchants, and the merchants APP will provide access to our H5 page to provide services.

However, merchants expect users to log in to their APP but not to log in after entering the H5 page. Therefore, our H5 needs to get the id of the user’s account in the APP (temporarily called PartnerID) and associate it with the id of our product’s account (temporarily called H5ID), so that after the user logs in to the APP, We can query the associated H5ID for account information through PartnerID so that we can keep our logins in sync.

The solution

One key point in this description is: How do I get PartnerID

There are three ways to obtain PartnerID:

  • Scheme 1: Authorization callback type, merchants provide authorization page, H5 page to log in, first enter the authorization page provided by merchants, the user agrees to authorize, and then obtain PartnerID
  • Scheme 2: APP interface type, merchant APP has nativeAPI, H5 page calls nativeAPI to obtain PartnerID
  • Scheme 3: Credential decryption, merchant APP adds encrypted string to query of URL of H5, and decrypts it from H5 page to obtain PartnerID

Basically speaking, most of the joint logins encountered are one of the above three types. For example, wechat authorized logins can be regarded as merchants, wechat unionID is PartnerID, and wechat uses scheme 1.

In addition, scheme 1 is an improvement of Scheme 2. In fact, scheme 2 is used to obtain PartnerID on the authorization page provided by merchants, so as to ensure that the nativeAPI of their APP is called by their H5 page, thus increasing security.

Therefore, the order of security is: 1 > 2 > 3

The more secure the development, the more complex the development, so the complexity of the development is the order above.

Detailed steps for federated login

The code will not be posted, the detailed steps are as follows:

  • 1: Ready to enter an H5 page, which requires a login to access
  • 2: Enter the PartnerID before entering, if the merchant APP is not logged in, the APP login, and then return the PartnerID
  • 3: If you have PartnerID, go to the corresponding H5ID. If yes, go to Step 5. If no, go to the next step
  • 4: H5 Login page, obtain THE H5ID, bind the H5ID to PartnerID, and store account login information
  • 5: You have logged in to the page

Independent code

There are three solutions, but some code must be written, summarized as follows:

  • Configuration file: Because merchants are different, the access type and configuration parameters are different. Assume that there is a Shanghu.js with the following code:
module.exports = {
  id: 'a'.// Merchant name
  type: 1.// Access scheme type
}
Copy the code
  • Scheme 1: “Call to enter merchant authorization page” and “call merchant API to get PartnerID” two functions
  • Scenario 2: “Call nativeAPI to get PartnerID” function
  • Option 3: “Decrypt string to get PartnerID” function

These codes are also different according to different merchants, so it is impossible to achieve a unified solution. So, write honestly.

However, some of the code can be made generic, and after development, subsequent access can be ignored.

Generic code

Scheme 1: Authorization callback type

The most complex scheme, in fact, the common code is two routes:

Go to Authorization /toAuth: When going to the page you need to log in to (assuming the address is A), go to this route first, this route receives A callback address (A) and stores it in the session, and then this route enters the merchant authorization page (at this time, the function that enters the merchant authorization page in the independent code is called).

Authorization callback /authBack: The callback route that must be provided to the merchant will be returned after the user is authorized in the merchant authorization page, and the user’s token will be passed back on query to exchange the token for PartnerID. That is, after steps 3 or 4 of the federated login (calling the function in the separate code that calls the merchant API to get the PartnerID), fetch the callback address in the session (A in the example) and enter

Scheme 2: APP interface

The generic code for this scenario is essentially a front-end function:

Call its specific independent function according to the merchant: the front end can get the PartnerID, so before login, call the function called nativeAPI in the independent code of the merchant to get the PartnerID, and then perform steps 3 and 4 of joint login, and finally complete the login operation.

Scheme 3: certificate decryption type

The simplest solution is to add an operation to the entry route:

Storing encryption certificate string: in the entry route, the encryption certificate is stored in the session. Before login, the function of the PartnerID is obtained by calling the decryption string in the independent code of the merchant, and then the PartnerID is obtained. Steps 3 and 4 of joint login are performed, and finally the login operation is completed.

Query interface

In step 3 of syndication, there are two apis, which we developed ourselves, respectively:

  • Query a bound Account: Query the associated H5ID using PartnerID. If the account exists, the login information is displayed; if the account does not exist, no bond is displayed. The front end determines whether the LOGIN page of H5 is displayed based on the API result
  • Bind the Account: Bind the PartnerID and H5ID to return the account login information

Other special logins

Silent login

In the above process, there will be a layer of binding operation in the middle, which requires a login on internal H5 page. In this case, there will be two logins: after APP login, enter H5 for the first time, login and binding in H5.

Therefore, some merchants have such requirements: if the APP has been logged in, there is no need to log in inside H5, that is, there is no need to log in binding in H5 when entering H5 for the first time.

This solution is actually very simple, in the two query interface, there is a query bound account interface, the function of this interface is:

  • Query the associated H5ID using PartnerID. If the account exists, the login information is displayed; if the account does not exist, no bond is displayed and the login page of H5 is displayed

If you want to satisfy the above requirements, the interface will always return login information, including the first login, as simple as that.

Because the merchant name and the PartnerID are passed when the interface is invoked, the interface developer can act on the merchant name.

For example, if the platform CMB requires silent login, the backend developer receives partnerName in the query binding account interface. If partnerName === ‘CMB’, the backend developer silently registers an account and logs in, returns the login information, and the rest is normal.

For multiple merchants with such requirements, an array can be maintained, which conforms to the items in the array, and silent registration and login can be carried out. Otherwise, normal steps will be taken.

Fast application embedding

The quick application page can obtain the user’s unionID on the open platform. During the embedded development, it is sometimes necessary to get the unionID and the H5 account for binding.

First, quick application provides apis to get the user identity, the only second, faster application itself should be considered as a lightweight APP development, application and fast also provides some methods, we can seal up some methods and interface, call by H5 nativeAPI manner and development, and quick application of combined log should be scheme 2: APP interface type.

encapsulation

Web components can be used:

  • PostMessage: Pushes a message to internal H5
  • Onmessage: Listens for internal H5 messages

Internal H5 can be used:

  • System.postmessage: Pushes a message to an external Web component
  • System.onmessage: Listens for messages delivered by external Web components

So you can call the login API in the fast application layer when the Web component listens on onMessage and gets the login request sent by the web page System. PostMessage. The Web component’s postMessage passes the PartnerID to the internal H5 page, which gets the PartnerID and goes through the normal federated login process.

END

Personally, I do not recommend to write a plan for one merchant, which is a waste of time and a large number of repeated codes, which is not conducive to code maintenance.

Although there are a variety of scenarios, most of them can be extended around the three scenarios, and supplemented by other scenarios, I will write here now.