To get the account system in WeChat Eco, it is enough to read this article.

www.huxiu.com/article/308172.html

Take care of the account system in WeChat Ecology and read this article.

This article comes from: Debate state, Author: debate state (hentaigeyi), head diagram from the visual China

Recently, the concept of private domain traffic is very hot. The so-called private domain traffic is that you can freely and repeatedly use it, without paying, and can be reached at any time. It is deposited in the public number, WeChat group, personal micro-signal, headline number, vibrato, etc. Users of the media channel. Relative to the public domain traffic platform such as Taobao, Jingdong and Baidu, it belongs to the “private assets” of the merchants.

Everyone should have used Mini Programs or opened the web page in WeChat. Do you often find that you will play a window and ask for authorization, and then you can display your WeChat avatar and nickname on the page? This is actually WeChat through the interface to developers to provide the ability to identify users.

To do private domain traffic, it will inevitably involve a question, saying that users have entered their own "private domain", but can we really know the user? Can we successfully identify this user and show the data that should be shown to this user? How many people know the complexity of WeChat's openid and unionid mechanisms? Do we make good use of these mechanisms provided to us by WeChat? How on earth does Douyin use these interfaces to get the user's relational chain?

I searched a lot of relevant information on the Internet, there are some descriptions of the nature of the mechanism, but the problem is very completely analyzed, and there are few articles that share detailed best practices, and most of them analyze this thing from the interface point of view. . Just recently contacted this piece of content, I summed it up, hoping to help the later people to step on a few pits.

In writing this script, I also consider that the stages of different companies may be different, and theoretically, the functional development requirements should be different. Therefore, this publication will discuss how to deal with WeChat private user data under different business and scenarios, and hope to be able to be able to throw away.

What do you know about basic concepts?

To do identification and authority restrictions on users is essentially a thing done by a user center. The development of computer systems has a long history. From ancient times to the present, the purpose of all systems involving user centers is nothing more than two:.?

First, "identity", can accurately know who this user is, there will not be a user, the system should know TA, but do not know, will not recognize the wrong user, will not regard this user as another person, will not regard others as this user, will not allow someone to impersonate this user. It is best to realize the one-to-one correspondence between physical users and virtual accounts. (the case of the trumpet is not taken into account here)

Second, "limited power", the user-related data can be displayed in conjunction with each other, will not lose the data, will not display the data should not be displayed, there will be no ultra vires phenomenon.

A good user system is mainly about doing two things, identification and restriction. So all the following content is around the identification and restriction of power these two bottom needs to do. All the iterations and improvements made by the system have only one purpose-how to minimize the cost of user identification and how to make the system limit the right to do the most accurately. The above paragraph is the "core idea" of the whole user center design, if you want to build a reliable user center, it is important to keep these things in mind.

Before officially embarking on the exploration of best practices, take a brief look at the following interfaces.

1. WeChat web page authorization (open the corresponding web page within WeChat for users):

https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140842

The authorization window style on the client side is shown in the following figure:

2, get a list of users (for users who have already followed the official account):

Https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140840

3, the small program to obtain the user information interface (for the scene of accessing the applet):

https://developers.weixin.qq.com/miniprogram/dev/api/open-api/user-info/wx.getUserInfo.html

The authorization pop-up style on the client side is shown below:

4. mobile application WeChat login interface (for scenarios within App that use third-party logins to access WeChat):

Https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419317851&token=&lang=en_US

The authorization window style on the client side is shown in the following figure:

The above four interfaces are the interfaces provided by WeChat for the WeChat browsing webpage, the users who have paid attention to the public number, the applet and the App to obtain the WeChat related information and the unique identifier of the current user.

The process of all four interfaces(except the second)involves user authorization, and the user may refuse authorization, and the official document of WeChat often says a bullshit that developers need to properly handle the situation of user rejection, but never said how to handle it properly.

The interaction process at the user end of the four processes is not the same (mainly, the style of the authorization window and the arousal environment are not the same, I think you should both have seen), but generally have to go through the user's authorization (non-silence), and the developer can get the key information. For example, the head portrait, unonid _ is a very important unique identification.

Some people may ask, why do I have a developer with 4 interfaces? Because a developer has multiple public numbers, applets, and apps, all of which belong to different "applications" in WeChat, WeChat will assign a unique Appid to each "application". Different application types and interfaces are naturally different. of.

Through the "WeChat Web Authorization" interface document, we can know that WeChat will return the following parameters to our system:

Based on the document, you can see two fields related to id, one called openid, and the other called unionid,. What are the concepts of these two id? What's the difference between id,?

WeChat official explanation is this: the role of the unionid mechanism: If the developer has multiple mobile applications, website applications and public accounts, you can distinguish the user's uniqueness by obtaining the unionid in the user's basic information, because the same user, The unionid is the same for different applications (mobile apps, web apps, and public accounts) under the same WeChat open platform.

That is to say, if a company has a Mini Programs matrix and the same user uses these three Mini Programs, the developers can get a total of three pieces of data from the WeChat interface, the openid of the three data users is inconsistent, but the unionid is consistent, openid and unionid are the only signs of the user, but the generation conditions of the uniqueness of the two are inconsistent.

Uniqueness of openid = appid of user WeChat account application (different official account, Mini Programs, appid are different) uniqueness of unionid = user WeChat account developer principal (usually company)

It is worth mentioning that the webpage in WeChat must be linked to a public number, so the openid authorized by the WeChat webpage is the same as the openid of the corresponding public number. Developers can choose to have all of their pages under a public number, which reduces the number of authorized pop-ups.

Generally speaking, WeChat provides a very comprehensive ecosystem, but because of its large WeChat system, coupled with its conservative design concept and extreme emphasis on user privacy (and even paranoid), WeChat will cause developers a lot of trouble, so it is not easy to use it correctly.

In addition, in the following specific content, there will be a description of more system modules. If the reader's own company has not implemented a structure similar to "microservices", then some modifications to the infrastructure may be needed, but the core Thought can also be applied.

WeChat account system construction in a single Appid scenario

Suppose we now join a startup whose business is very simple, with no paid business for the time being, just a small community that provides some comments, likes and collections. At present, only one official account has been opened, so how should we design an account system for WeChat? How do we apply openid and unionid?

Based on the "core idea of ​​the user system" mentioned above - it is possible to achieve accurate identification of the user's identity and to be able to identify the data corresponding to the user accurately, and the things to be done are clearer. Generally, a userid is generated in the system to be used as the unique identifier of the user in the system, and the business party associates the user with the business data based on this field to implement the limitation.

In the WeChat system, the unionid field can be identified as the core key, that identifies users, so you need to make an association between userid and unionid, and to sum up, you have to do the following:

First, "fast and accurate identification"-in order to be able to identify users quickly, user identification should be accurate, there can be no error in identifying users, nor can there be situations that should be recognized but not recognized. At the interactive level, it is best for users to operate at a super low cost, click on it, or even identify it without clicking. Second, "accurate limitation"-user-related data can be displayed in conjunction with each other, will not lose data, will not display data that should not be displayed.

Combine the interface capabilities provided by WeChat to translate the above goals. The actual thing to do is this:

The core mechanism, "Bind the unionid and userid binding to achieve the right" - Bind the unionid of WeChat with the userid of the own system, usually need to implement the core mechanism based on the login behavior, "Using openid for fast identification" - - Since the WeChat web page can directly identify the user's openid, it is necessary to associate the openid with the unionid to achieve a "long-lasting and accurate cookie" effect, so that even if the user changes the mobile phone, the system will not change the micro-signal. It can always be identified directly at the lowest cost. Core mechanism III, “Interactive level handling user denial of authorization” – properly handle user rejection of authorization, so can not get unionid

Although I hate WeChat's "proper handling" statement, in this case, I really don't know how to summarize this work.

The core mechanism one - the logic of "bining unionid and userid to achieve weight limit" is relatively simple. The user accesses the system page in WeChat, triggering the pop-up window of "WeChat webpage authorization". After the user agrees to authorize, the system gets the The unionid corresponding to the user (the micro-signal), and then associate the unionid with the userid of the system itself (for example, first pop-up window, then ask the user to log in based on the mobile phone number and SMS verification code, or do silent registration to see the specific business) Then the system will have a [unionid-userid] data, one for each.

From then on, the user simply accesses the system system through the WeChat environment, and automatically adds the cookie corresponding to the userid that the database has associated with, and restricts the user to use the userid to log in again in other micro-signal environments. (Scenario example: try to log in with the same mobile phone number as the micro credit)

Core mechanism 2 - "Using openid for fast identification" is not complicated to implement. "WeChat webpage authorization" has a mechanism called "snsapi_base for webpage authorization initiated by scope", which can get the openid of the user who enters the page, and is Silent authorization. At the same time, since the user has allowed authorization, the system has obtained the association relationship of [openid-unionid], and the data in the system becomes the data of [openid (public number A)-unionid-userid] structure.

With the help of the data in the database and the "snsapi_base-originated web page authorization" mechanism, this user can know him in the future, whether he is at the end of the world or the cape, as long as the web page is opened in WeChat.

The core mechanism three - "interactive level to deal with users refused to authorize", this thing will be more metaphysical to deal with, the more common practice is to set up an interception mechanism. In general, the interface for authorizing the authorization popup and the process for forcibly logging in can be done together. After all, these two properties are very similar. To put it bluntly, there are two different forms of identity recognition.

What operations must be done by the logged in user (such as order purchase, collection, like, comment), add a pop-up window in front of the corresponding process. The WeChat webpage authorization popup window can be triggered repeatedly. Just like the original login popup window written by the company itself, it can also determine whether there is a corresponding data record in the database (openid the same data) when entering the page. No pop-ups.

How to design these mechanisms specifically requires the product manager to decide according to his own business and sensitivity to conversion. If the boss thinks it is stupid to intercept users to log in before placing an order, he can also consider removing them, but this requires the design of a "tourist identity" mechanism, which will be described in more detail below.

The above three core mechanisms are the core logic for the public number login (WeChat web page authorization), please be sure to keep in mind if you want to practice.

In the aspect of data storage, you can choose to store the association information of openid-unionid first, and then store the association information of unionid-userid according to the situation of user login. The specific logical order will be shown in the flow chart of the next section.

Of course, some students will ask, why can't directly obtain openid through "snsapi_base for webpage authorization initiated by scope", and then associate with userid. Why do you want to intercept because you can't get unionid? The reason is very simple, because the company will develop, sooner or later, it will do small procedures, do more business, and then go back and fill this pit, it is not worth the candle.

In the case of unable to get unionid, the openid, can only be used as a front-end to provide tourists with cookie means, can be stored, for the front end when the cookie logo position, but do not drop into the "user center" database, otherwise the backfill pit is really crematorium, although there will be two pit filling tips on the following, but students who have the conditions not to do so please do not do so.

All of the above designs are ideal, and in real life, we will also encounter some undesirable situations, such as that the programmer forgot to save unionid field.

What can we do? The unionid can be brought back based on the user's openid through the following interface. Interface address:

https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140839

In theory, this interface can get the data back, it must be because the user did the following things:

There is a public number of the same subject under the developer account, and the user has already paid attention to the public number. The public account or mobile application of the same subject exists under the developer account, and the user has authorized to log in to the public number or mobile application.

The above-mentioned authorization to log in to this public number is actually a "WeChat web page authorization", which is to blow down the official documents of WeChat, and a behavior makes two nouns. It's really annoying. So what would be the effect of a user's authorization to cross the same subject? The official document has not been written, and I can't say it.

This method is not omnipotent. If the user has already cleared the public account (remarks: take care of it again, openid and unionid are unchanged), the system will not get the information, and then a bunch of unionid fields will appear in the database. Empty data, in fact, is very painful, so the system is built this time, sometimes it is a step by step. But often at the beginning of the business, product managers and developers are not very concerned about it, which will cause great trouble to the people behind. I will understand this mechanism so much, I believe that readers already know how many pits I stepped on before.

If the user has already taken the check, in order to retrieve the data when the user meets again, the front-end layer code needs to add a piece to the judgment mechanism for authorizing the pop-up window to play, and the unionid field of the user data corresponding to the openid Whether it is empty, if it is empty, you need to authorize the window and get the corresponding unionid.

The Construction of WeChat account system based on Multi-Appid scenario

With the development of the company's business, the previous public number did a good job. Recently, the small program has won the wind. The company also hopes to do some work. The boss said that we are going to be a small program, and then we will do our e-commerce, what kind of improvements and changes should the user center make in the face of new business requirements?

In this case, we must first structure the goal, how to do a good job in the case of the new Mini Programs user system? In fact, in the final analysis, we still have to bear in mind the core idea of designing user centers, abstracted to achieve the following goals:

First, "fast and accurate identification"-in order to be able to identify users quickly, user identification should be accurate, there can be no error in identifying users, nor can there be situations that should be recognized but not recognized. At the interactive level, it is best for users to operate at a super low cost, click on it, or even identify it without clicking. Second, "accurate limitation"-user-related data can be displayed in conjunction with each other, will not lose data, will not display data that should not be displayed. Third, "fast identification automatic binding"-because there are two software environments (WeChat web page and Mini Programs), which will involve the binding and unification of user data in the two environments, because they can be e-commerce, users will be very sensitive to "data loss", so the binding of user data is particularly important.

The above three points, one and two points are inherent requirements, and the third point is the new requirements after the multi-Appid situation.

Combined with the results provided by WeChat, translating the above objectives is the following core points:

The core mechanism, "Bind the unionid and userid binding to achieve the right" - bind the WeCin unionid and the userid of the own system, usually need to implement the core mechanism based on the login behavior, "using openid for fast identification" - - Since the WeChat web page can directly identify the user's openid, it is necessary to associate the openid with the unionid to achieve a "long-lasting and accurate cookie" effect. Core mechanism three, "Using openid for fast identification" (small program scenario) - small programs can also directly get the user's openid, so you need to associate openid and unionid to achieve a "long-lasting and accurate cookie" Effect. Core mechanism four, "Using the binding relationship between unionid and userid to achieve fast login" - the unionid obtained from the applet is consistent with the unionid obtained in the WeChat webpage, so if the unionid is already established in the database The associated data with userid, the other party should be able to automatically establish contact with the data in the database without requiring the user to do any identification operation similar to "mobile phone number verification code login". Core mechanism five, "Using the binding relationship between unionid and userid to achieve silent login" - In some specific cases, the applet can directly obtain the unionid without user authorization, so this mechanism should be used to help the user achieve without any The effect of direct login can be operated. The core mechanism is six, "Interactive level handling user denial of authorization" - properly handle the user's denial of authorization, so the unionid situation is not obtained.

"Core Mechanism One," "Two," "Three," and "Six" have not been described in detail in the above section. Let us focus on the above "core mechanism four" and "core mechanism five". .

The essence of "Core Mechanism IV" and "Core Mechanism V" are the same, and in essence they are the following processes:

To be sure, the biggest difference between "core mechanism four" and "core mechanism five" is in the yellow area of ​​the above flow chart.

In general, we need a pop-up window to request authorization from the user in order to get the relationship between openid and unionid from the user, otherwise we can only get the data of openid. Under special circumstances, in Mini Programs environment, the relationship between unionid and openid of the user can be obtained directly through the interface. For a specific description, see the document-unionid access path:

Https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/union-id.html

On the other hand, if users log in first in Mini Programs, and then visit the WeChat web page, they also have to do the operation in the above flow chart, so that the maximum cost can reduce the cost that users identify very much. after all, many users can not tell the difference between Mini Programs and WeChat pages at all. In their cognition, this service is provided by the same company. In theory, it should be available automatically. You can't lose the data.

After finishing the``Core Mechanism IV'' and``Core Mechanism Five'' , I went back to``Core Mechanism One'' . Although there are 2 data, things have not become complicated, as long as I don't die.

In the above section, we describe the logic of the binding as follows:

The user accesses the page of the system in WeChat, triggering the pop-up window of "WeChat webpage authorization". After the user agrees to authorize, the system obtains the unionid corresponding to the user (the micro-signal), and then associates the unionid with the userid of the system itself. Get up (for example, first pop up the window, then ask the user to log in based on the phone number and SMS verification code, or you can do silent registration to see the specific business), then we have a [unionid-userid] data, one for each.

Since then, as long as users access the system through WeChat environment, they will automatically plant the cookie, corresponding to userid, which is already associated with the database, and restrict users to log in with this userid in other WeChat environments. (example of the scene: change WeChat to try to log in with the same cell phone number)

In fact, the core of this logic does two things. The first is to save the association data of [unionid-userid], and the other is to make the restriction logic to ensure that the two are one-to-one corresponding relations.

After adding the applet, this scene has produced some changes, because the data such as unionid-userid will appear two, and there must be some after, so the later one can completely fill in the data of the previous userid. Come over, the logic described in the flowchart above. Even if one piece of data becomes two, the nature of things is not changed.

There is a special emphasis on this, as mentioned in a subsection above:

The openid obtained without the unionid can only be used as a means for the front-end to give the visitor a kind of cookie. You can drop the library and give the front-end a cookie identifier, but don't drop it to the [user center] database. .

What would be the problem if we left the data with the unionid field empty in the "user center" database? Give an example to illustrate. Try this scenario: a user enters Mini Programs, refuses to authorize but logs on to the mobile phone number A, then goes to the WeChat web page, also refuses to authorize but logs on to the mobile phone number B, and we will have the following data.

[openidA-unionid is empty-useridA]

[openidB-unionid is empty-useridB]

What if the user is allowed to access again and the authorization is allowed in both environments? The data in the database will be completed and become the following.

[openidA-unionidA-useridA]

[openidB-unionidA-useridB]

The problem is. If the company develops a small program at this time, the user comes over and allows authorization. The system gets openidC and unionidA. Which userid should the user be associated with? So we can see that if the data with the unionid field is empty, it is so troublesome that the data of the [user center] is involved. Once the two appid systems are involved, it is very easy to make a mistake, but if the unionid is not Allowed to be empty, then the logic of the system is still relatively simple and very clean.

If someone does not believe that evil can be associated by appid or other means, you can try it, run it online for a while, then go to mysql to run the number, 100% will encounter a micro-signal associated with two userid At this time, the user complained about the "order lost" problem, and it was really difficult to wash into the Yellow River.

In addition to the difference in the logical level, there is a big difference between the way in which the pure public number scene is handled in the above section, that is, there are theoretically two such data in the database:

[openid (public number A)-unionid-userid]

[openid (small program B)-unionid-userid]

I would suggest that the data structure be transformed into the following:

[openid (public number A)-unionid-userid-appidA]

[openid (small program B)-unionid-userid-appidB]

Why do you want to increase the field of appid? The reason is relatively simple. I will do a message notification and other functions. In many cases, I will search based on the appid field. It is convenient to add it.

In many cases, some developers who have little experience will like to use numeric enumeration values. For example, the public number is 1, and the small program is 2. However, in fact, after the company's business development, it may do 7 or 8 small programs. The enumeration value is not very high. Good expression of the substantive meaning of the business level, this is a problematic abstract way, so it will be more scientific to deposit the Appid into the system from the beginning.

The logic described above is actually very complicated. It is not very easy to use the text description. Below is a flow chart. You can copy the homework. It should be emphasized that the business scenario of my company is more complicated than this. The content of this flowchart is not verified online, so this flowchart cannot guarantee 100% correct.

If I look at the flow chart alone, it is not very easy to understand, so I did the logic of tips, in six places, which may be a little around, but it all has a very clear purpose, and the lack of one of these steps will lead to a change in the results.

[1] this step is mainly aimed at the fact that there is probably an identical piece of data in the database. If the user clears the cookie, front end and does not know the user, he will transmit the existing data. If he does not do so, there will be a problem in the logic judgment below.

[2] if this situation is developed in full accordance with the above requirements, it will not happen in theory, but because the development non-standard is likely to lead to a similar situation, so the restriction logic is deliberately added.

A mechanism designed to prevent users from trying to log on to a mobile phone number already bound to WeChat on another WeChat account.

[4] The purpose of re-weighting is also relatively simple. It is possible that the data in the previous database [openidA-unionidA-userid is empty], and then the interface is passed [openidA-unionidA-useridA], the first time to go heavy will not These two data are treated as duplicate data, but after the above process is processed, both data will become [openidA-unionidA-useridA], so deduplication logic is required.

[5] When alpha is written to the database, if the data is read, the read_time is empty, indicating that this is new data and needs to be directly inserted. The typical scenario is the first time the user accesses the service of our system.

[6] This step is the process of returning the final result to the front end. It is very likely that the front end only gives the backend openid and unionid, but the backend returns the userid to the frontend through the associated logic, and the frontend can seed the cookie.

The above process is not a regular``login'' process, but it is more like a``data binding'' process, but I suggest that all the interfaces involving WeChat user system be sealed into one interface and not divided into``binding'' and``login'' interfaces.

At the same time, where regular login is involved (such as App's secret login), if the front end can get openid and unionid's value, you should call the interface of the above process again.

There are three reasons for this, one is that it can also meet the needs of the business. Second, in order to reduce the cost of testing, we can see from the complete flow chart above that the logic above is very simple, in fact, it is very troublesome, if you distinguish between binding scenario or login scenario, testing will be a headache. Third, from the bottom abstraction, the so-called "data binding" essence is to use the user can not forge openid to do an identity, in fact, is also a kind of login, binding is a kind of login.

The input parameters of the interface are mainly three elements: openid, unionid, and userid, where userid can be defaulted, because in the scenario of automatic login mentioned in "core mechanism four" and "core mechanism five". We still can't get the user's userid. In fact, we pass the unionid to the server, and the server returns the userid.

Construction of WeChat account system involving non-login student orders

Mini Programs went online, the number of users soared, the company got a financing, the boss is a little inflated, said let's do App.

It happens that the competitor's App is also online. They also support a very hanging function, that is, the identity of the visitor can also be directly purchased, and there is no need to log in before the order. At this time, the boss is in a hurry and asks for his own product. Have the same function.

First of all, this is a very real background, and according to the practice of well-known ecommerce companies in the industry, more than 40% of orders come from tourists' orders, so when it is necessary to do so, the key point is how to do it. Before we officially start talking about the plan, we might as well look back at the core idea again.

What is the user system to do? Identify users and perform restricted operations based on identification. So is the design of the “visitor purchase order” that is common in the industry contradicting the system itself? Is this design too "personality split"? I don't think so.

Because no matter which company it does, no matter how well it supports "tourist purchase," it is still doing everything it can to guide users to log in. The essence is that "tourist purchase" is actually the only identification of cookie in App, and we all know that cookie is actually very easy to erase, if users use the garbage collection function to clear the cache, it is likely to be washed off, and the feeling to the client is that the order can not be found, which is actually more serious.

It should be noted that there is a big difference in interaction between WeChat authorization in App and WeChat authorization in Mini Programs / WeChat web page.

When you get the openid in the applet/weick webpage, you can get the openid directly by using the "snsapi_base for the webpage authorization initiated by scope", without the user to do anything.

When acquiring the unionid, it only evokes the controls (that is, a pop-up window) that are included in the WeChat environment to request authorization from the user. The interaction process is very simple, and any page or any button can be added with this trigger, which is actually very convenient.

Within the app, you want to get the user's authorization (this is the only way to get openid and unionid). You need to wake up WeChat's app, and then the user will be authorized to post the developer's app. This means that this wake-up operation cannot be inserted at any node as arbitrarily as in the previous design, because in the previous environment, the authorization is only a pop-up window, the blocking will be smaller, and the App will jump out directly. App, the cost of interaction will be relatively large, frequent pop-ups will easily lead to blocking the main process, not worth the candle.

It is generally recommended to make the authorization of the WeChat account at the login interface to guide the user to bind. There are also some very slippery companies that play in the WeChat ecosystem. They choose to guide users in the "order list" and "my" pages, because many of these merchants are diverted from WeChat, after the user downloads the app. The first reaction must be "Where did I go to the list under WeChat?" This design can guide the user well.

All of the above are interactive issues, and at the back-end logical level, App completion can be used as another Mini Programs or official account.

After saying WeChat's authorization in the app, let's talk about the situation of “visitor purchase order”. There are two technical solutions for tourists to purchase a single order.

The first is``guest order purchase'' designed based on the business. In short, the database of the business party allows the userid field to be empty under certain circumstances.

The second option is to design a “visitor purchase order” based on the user center. Simply put the cookie of the visitor as the unique identifier of the identity, for example, use a cookie to generate a userid, send it to the backend, and then wait for the user to log in. The user center then replaces it and broadcasts it to the business party.

Whether my own company or consult the product manager of other companies, generally think that the second scheme is better design, scalability will be stronger, the line of business does not need to care about such complex userid replacement logic, can be used directly, more in line with the "small front desk, large and medium platform" design concept, the coupling is relatively low.

According to the logic of the second scheme above, the student can only do this thing. Most companies choose to do it in the app because the app's cookie storage time is generally longer than the browser. It won't be okay to clear the app's cache, and the risk is relatively controllable.

After discussing the main solutions for this system improvement, let's go back and look at the goals of this system design. I think it is mainly the following goals:

First, "fast and accurate identification"-in order to be able to identify users quickly, user identification should be accurate, there can be no error in identifying users, nor can there be situations that should be recognized but not recognized. At the interactive level, it is best for users to operate at a super low cost, click on it, or even identify it without clicking. Second, "accurate limitation"-user-related data can be displayed in conjunction with each other, will not lose data, will not display data that should not be displayed. Third, "quickly identify automatic binding"-because there are multiple software environments (WeChat web pages, Mini Programs, App, etc.), it will involve the binding and unification of user data in multiple environments. Because they can be e-commerce, users will be very sensitive to "data loss", so the binding of user data is particularly important. Fourth, "Design of interaction related to account binding after product diversion"-because users will probably take the lead in using Mini Programs and then download App, App may need to guide users to bind WeChat accounts in order to synchronize the data. (for example, users place orders as tourists in Mini Programs, but agree to authorization within the WeChat web page, the order list to App can not see the data, need to guide users to bind WeChat accounts) 5, "automatic binding based on tourist identity"-the relationship between users in multiple WeChat environments as tourists, although the user did not log in, But we can still think of him as the same person based on WeChat, so we need to do something about it.

The above five points, one, two, three points are the inherent requirements mentioned above, and four or five points are new requirements based on new business scenarios.

Combined with the interface provided by WeChat, the above requirements are translated into specific enforceable measures, which are the following core points:

Core mechanism 1, "binding unionid and userid to limit rights"-binding WeChat unionid to userid of its own system, usually based on login behavior to implement the core mechanism 2, "using openid for rapid identification"-because WeChat web pages can directly identify users' openid, it is necessary to associate openid with unionid to achieve a "long-term and accurate cookie" effect. Core mechanism 3, "using openid for fast identification" (Mini Programs scene) Mini Programs can also directly obtain the user's openid, so it is necessary to associate openid with unionid to achieve a "long-term and accurate cookie" effect. The core mechanism is "solving the problem of data synchronization in App based on interactive boot" in App, which is based on the interaction mechanism of WeChat authorization and the behavior track of users, and prompts the user to "bind WeChat account" on the key page. The core mechanism is "using the binding relationship between unionid and userid to achieve fast login"-the unionid, obtained from the small program in the WeChat web page and the unionid obtained by App based on account binding are the same, so if the relevant data of unionid and userid has been established in the database, The remaining two parties should be able to automatically connect with the data in the database without requiring the user to do any identification operations similar to the "mobile phone number verification code login". This association logic needs to take effect for virtual userid generated by tourist identity as well. Core mechanism 6, "make use of the binding relationship between unionid and userid to achieve silent login"-in some specific cases, Mini Programs can directly obtain unionid, without user authorization, so we should use this mechanism to help users achieve the effect that they can log in directly without any action. Core mechanism 7, "interactive level to deal with user denial of authorization"-properly handle user refusal of authorization, so do not get unionid. Core mechanism 8, "broadcast mechanism after user identity change"-all behaviors involving replacement between userid must be broadcast to all lines of business, whether the virtual userid is replaced by the real login userid or the virtual userid.

Among them, "Core Mechanism 1", "two", "three", "six" and "Seven" have all been discussed above. "Core Mechanism IV" has already been discussed at the beginning of this subsection. Let's talk about "Core Mechanism 5" and "Core Mechanism 8".

We may wish to compare the different requirements for the design of the “core mechanism five” involving the student’s student list and not involving the student’s student list.

[Involving tourist orders]

The unionid obtained by unionid, in WeChat web page and the unionid obtained by App based on account binding are the same, so if the associated data of unionid and userid have been established in the database, the remaining two parties should be able to automatically establish the connection with the data in the database without requiring the user to do any identification operation similar to "mobile phone number verification code login". This association logic needs to take effect for virtual userid generated by tourist identity as well.

[Do not involve tourist orders]

The unionid obtained from the applet is consistent with the unionid obtained on the WeChat webpage, so if the two have already established the associated data of unionid and userid in the database, the other party should be able to automatically establish contact with the data in the database without The user is required to do any identification operation similar to "Mobile Number Verification Code Login".

Excluding the addition of the App runtime environment, the biggest difference is that "this association logic needs to take effect on the virtual userid generated by the tourist identity as well." This sentence。

Why do you need to do this? The main purpose is to meet the following scenarios:

The user agreed to "user Information Authorization" at Mini Programs, and the system obtained her openid and unionid, but she followed up as a tourist and did not log in.

At this time, the user did the same thing on the WeChat webpage. At this time, if the system does not synchronize her userid as a visitor, then the cookie in the two environments is different, and the generated virtual userid is naturally different, but The system based on unionid should be able to integrate and synchronize the data of users in different places.

Some people may say that trying to help users synchronize data will not make users feel``creep'' . I think it's not funny. I have done a lot of user interviews. Many people can tell the difference between``applets'' and``WeChat Web pages'' . In their view, the data should be synchronized. The loss of data will scare them.

Based on the above discussion, we will correct the flowchart again and get the following flow chart:

Compared with the above flow chart, the only difference is that the logic of judging whether "userid is empty" becomes "whether userid is all virtual", because under the mechanism of tourist order, even if the user does not log in, a virtual userid. can be obtained.

When the userid is added, if the system can identify the user (based on the obtained unionid), even if the current userid is virtual, the userid of the previous user data in the database is also virtual, and the userid-unionid needs to be maintained. Corresponding relationship, replace the current virtual userid with the earlier one in the database, so that the user's previous data can be read in this environment. The specific application scenario is described above. But if one of the userids is true, then it should get the highest priority.

postscript

At this point, the discussion on how to build the whole WeChat account system has come to an end. In fact, there are a lot of things we can do to build a complete user system, such as whether we can support the login of QQ and Weibo in addition to WeChat, such as whether third-party social accounts support unbundling (which is done by the user centers of large companies), which we need to consider, but I think it is enough to do a good job of WeChat in the early stage.

If you add the data from Weibo and QQ, the overall data structure will have the following distribution:

The overall product structure presents the following style:

In fact, after I officially started writing this article, I have time to sink my heart and think again about the logical abstraction. I came up with the flow chart above.

Before that, I showed it to the development, and I checked it myself. The logic of thinking is a logic similar to a binary tree. However, as the complexity of the business increases, the logic of the binary tree is obviously only used for coverage testing, and is not suitable for development. This is a small pit in the process of this matter.

I think that the user system has been developed for so many years, and it seems very simple, but in fact, there is a lot of learning in it, but in general, in actual work, it is still necessary to firmly grasp the core ideas of the bottom, good. The user system is mainly to do two things, identification and limitation. All the work should be done around the two bottom layers of identity and power. In fact, everything we do is inseparable, how to let users minimize the cost of identification, how to make the system The most restrictive power is done.

It may be worth recalling that the previous user system would also distinguish between "registration" and "login". Now it is basically a mobile phone SMS verification code login, and no registration is registered. This change is actually a practical solution of the core ideas mentioned above. And through the practice of the major manufacturers in the industry, it can basically be considered a best practice.

From a personal point of view, the mechanism of WeChat and unionid is very painful. WeChat itself has made a lot of improvements, but I think it is still a very fucked and troublesome thing. From the official point of view of WeChat, they may still be doing this from the point of view of protecting the privacy of users from abuse, and as developers only adapt, after all, the mechanism is already here, there is nothing to say.

Many of the ideas in the above article, most of which I have practiced, are in line with expectations, but due to the limitations of objective conditions, some ideas have not been verified in the production environment, and can not guarantee 100% correctness, and different business scenarios will give rise to different practical solutions for the same thing, for example, this paper will emphasize that as far as possible to achieve [userid-unionid] one-to-one correspondence. In practice, some companies allow a userid to correspond to multiple unionid, in fact, think carefully, as if there is nothing wrong with it.

I would like to thank the following partners for their support to this article: Xibei Science and Technology-Front-end engineer-Zhou Hang, a unemployed front-end engineer-Quan Jinduo, Xibei Technology-Senior java engineer-Li Rui, Kitchen Core Technology-Product Manager-Shao Kun-Rong, Tiger sniff-Editor-Oda Yicheng. The flow charts in this paper are drawn by using OmniGraffle and Xmind.

This article comes from: Debate state, Author: debate state (hentaigeyi)

* The article is the author's independent point of view, does not represent the position of the tiger sniffing net. This article was published by the authoritative authorization of Huwei.com and edited by Tiger Sniffing. Reprint this article with the author's consent, and please attach the source (虎 sniffing net) and the link on this page. Original link: https://www.huxiu.com/article/308172.html

In front of the future, you and I are still children, do not download tiger sniff App sniff innovation!

Get it WeChat ecology account system look at this articles articles enough

Read More Stories

© NVBOOK.com , New View Book , Powered by UIHU