TodayWeChat Mini Program Development column introduces the front-end design and implementation of mini program login.

1. Preface

The purpose of the login/registration design is of course to make this the basic capability of the application and be robust enough to avoid the occurrence of the whole site. sexual obstruction.

At the same time, we must fully consider how to decouple and encapsulate. When developing new small programs, we can quickly remove reuse capabilities and avoid repeated pitfalls.

The login and registration module is like an iceberg. We think it is just "enter your account and password, and you are logged in." But in fact, there are various issues that need to be considered.

Here, I would like to share with you all the design experiences and ideas I have accumulated after recently completing a small program login/registration module.

2. Business Scenario

In the process of users browsing the mini program, due to business needs, it is often necessary to obtain some basic information of the user. Common ones include:

1. 微信nickname
2. 微信手機

Different products have different information requirements for users, and will also have different authorization processes.

The first type is common in e-commerce systems. When users purchase goods, in order to identify the user's multi-platform account, they often use their mobile phone number to make a contact. In this case, the user needs to authorize the mobile phone number.

Second, in order to get basic initialization of user information, it is often necessary to obtain further user information: such as WeChat nickname, unionId, etc. User authorization is required.

The third type includes the first type and the second type.

3. Concept

With the goal of precipitating a set of universal mini program login solutions and services, let’s analyze the business and derive the variables.

Before doing technical design, talk some necessary nonsense and conduct basic tuning on some concepts.

2.1 About "Login"

Login is "login" in English, and the corresponding one is "logout". Before logging in, you need to have an account and "register" (or sign up).

It is said that the initial product did not have a login/registration function, but it gradually became available as more people used it. Due to the needs of the product itself, the "user" needs to be identified.

In the real society, each of us has an identity ID: ID card. When I turned 16, I completed a "registration" when I went to the Public Security Bureau to get my ID card for the first time. Then I went to the Internet cafe to surf the Internet, swiped my ID card, and completed the "login" behavior.

So for the Internet in the virtual world, this identity certificate is "account password".

Common login/registration methods are:

1. Account and password registration

   In the early days of the Internet, personal email and mobile phone Coverage is small. Therefore, the user needs to think of an account name. We register a QQ account, which is this form.

   

2. Email address registration

   After the millennium, the PC Internet era has rapidly become popular, and we have all created Get your own personal email. In addition, QQ also comes with an email account. Since email is personal and private and can communicate information, most websites have begun to use email accounts as user names for registration, and during the registration process they will be asked to log in to the corresponding email to check for activation emails to verify that we have Ownership of the registered email address.

   

3. Mobile Number Registration

   After the popularization of the Internet, smartphones and mobile Internet developed rapidly. Mobile phones have become an indispensable mobile device for everyone, and the mobile Internet has been deeply integrated into everyone's modern life. Therefore, compared to email, mobile phone numbers are currently more closely related to individuals, and more and more mobile applications are emerging, and registration methods that use mobile phone numbers as user names are also widely used.

   

# By 2020, the number of WeChat users will reach 1.2 billion. Well, WeChat accounts, at least in China, have become the "identity mark" of the new generation of the Internet world.

For WeChat applet, it is natural to know the WeChat account ID of the current user. WeChat allows mini program applications to quietly "log in" to our mini program applications without the user being aware of it. This is what we often call "silent login."

In fact, the login of WeChat applet is essentially the same concept as the "single sign-on" of traditional web applications.

1. Single sign-on: After logging in at station A, station C and station B can achieve fast "silent login".
2. WeChat mini program login: In WeChat, if you log in to your WeChat account, you can achieve "silent login" in the entire mini program ecosystem.

Since Http is originally stateless, the industry’s basic general approach to login state is:

1. cookie-session: commonly used in browser applications
2. access token: often used in non-browser applications such as mobile terminals

In the WeChat applet, the "JS logic layer" is not a browser environment, and naturally there is no Cookie, then access token is usually used.

2.2 About "Authorization"

For products that need to further obtain user nicknames, user mobile phone numbers and other information. For the sake of user privacy, WeChat requires users to actively agree to authorize. Only mini program applications can obtain this part of the information. This is the interaction of the currently popular mini programs "authorized user information" and "authorized mobile phone number".

Due to the different sensitivities of different user information, WeChat mini programs provide different "authorization" methods for different user information:

1. Call the specific API method, Pop-up authorization.
   1. For example, when calling wx.getLocation(), if the user is not authorized, the address authorization interface will pop up.
   2. If rejected, the window will not pop up again, and wx.getLocation() will directly return failure.
2. <button open-type="xxx"></button> method.
   1. Only supports: user sensitive information and user mobile phone number. You need to cooperate with the backend for symmetric encryption and decryption to obtain the data.
   2. The user has declined. If you click the button again, the pop-up window will still appear.
3. Through wx.authorize(), ask for authorization in advance, and there is no need to pop up the authorization again when you need to obtain relevant information later.

4. Detailed Design

After sorting out the concepts, our modules can be divided into two large blocks:

1. Login: Responsible for creating a session with the server. This session implements silent login and related fault-tolerance processing. The module is named: Session
2. ##Authorization: Responsible for interacting with users, obtaining and updating information, and controlling permissions, etc. The module is named: Auth
##3.1 Login implementation

3.1 .1 Silent login

The official login solution provided by WeChat is summarized in three steps:

wx.login()
1. Obtain the one-time encryption certificate code and hand it to the backend. The backend transmits this code to the WeChat server in exchange for the user's unique identifier
openId
2. and authorization certificate session_key. (Special API calls used for subsequent server-side and WeChat servers, see for details: WeChat official documentation - server-side acquisition of open data). The backend transmits the user credentials obtained from the WeChat server and the self-generated login credentials (token) to the frontend. The front end saves it and brings it to the back end the next time it is requested, so that it can identify which user.
3. If you just implement this process, it is quite simple.

But to achieve a robust login process, you need to pay attention to more edge cases:

1. Collapse

   wx.login() Call : Because

   wx.login()

   will produce unpredictable side effects, for example, it may cause session_key to become invalid, resulting in subsequent authorization Failure in decryption scenarios. We can provide a method like session.login() here to take control of wx.login() and perform a series of encapsulation and fault tolerance processing on it.

2. Timing of the call

   : Usually when the application starts (

   app.onLaunch()

   ), Go to initiate a silent login. However, there is an asynchronous problem caused by the applet life cycle design problem: when loading the page, when calling a back-end API that requires login state, the previous asynchronous static login process may not be completed, resulting in a request fail. <p> Of course, you can also initiate a login call in an asynchronous blocking manner when the first interface that requires login status is called. This requires a well-designed interface layer. </p> <p>The detailed design ideas for the two scenarios mentioned above will be discussed below. </p>

3. Problems with concurrent calls:

   In business scenarios, it is inevitable that there will be multiple codes that need to trigger login. If you encounter extreme situations, These multiple codes initiate calls at the same time. That will cause the login process to be initiated multiple times in a short period of time, even though the previous request has not been completed. For this situation, we can block the first call and wait for the result of subsequent calls, just like the process of combining sperm and eggs.

4. Problems with unexpired calls:

   If our login status has not expired, it can be used normally. By default, there is no need to call again. Go and initiate the login process. At this time, we can first check whether the login state is available by default. If not, we can initiate a request. Then you can also provide a parameter similar to session.login({ force: true }) to force login.

3.1.2 Handling of silent login asynchronous state

1. Called when the application starts

because in most cases They all need to rely on the login state. We will naturally think of calling this call when the application starts (app.onLaunch()).

However, due to the native applet startup process, the life cycle hook functions of App, Page, Component do not support asynchronous blocking. .

Then we can easily encounter that the "login process" initiated by app.onLaunch has not been completed at page.onLoad, and we will not be able to do it correctly. Some operations rely on login status.

In response to this situation, we designed a state machine tool: status

Based on the state machine, we can write code like this:

import?{?Status?}?from?'@beautywe/plugin-status';//?on?app.jsApp({????status:?{???????login:?new?Status('login');
????},????onLaunch()?{
????????session????????????//?發(fā)起靜默登錄調(diào)用
????????????.login()????????????//?把Understand the front-end design and implementation of WeChat mini program login設(shè)置為?success
????????????.then(()?=>?this.status.login.success())??????
????????????//?把Understand the front-end design and implementation of WeChat mini program login設(shè)置為?fail
????????????.catch(()?=>?this.status.login.fail());
????},
});//?on?page.jsPage({????onLoad()?{??????const?loginStatus?=?getApp().status.login;??????
??????//?must?里面會進行狀態(tài)的判斷，例如登錄中就等待，登錄成功就直接返回，登錄失敗拋出等。
??????loginStatus().status.login.must(()?=>?{????????//?進行一些需要登錄態(tài)的操作...
??????});
????},
});復(fù)制代碼

2. Initiate login when the "first interface that requires login state" is called

Further, we will find that a deeper level of login state is required The node is when launching the "backend API that requires login status".

Then we can initiate "silent login" when calling "backend API that requires login status". For concurrent scenarios, just let other requests wait.

Using fly.js as the "network request layer" encapsulated by wx.request(), make a simple example:

//?發(fā)起請求，并表明該請求是需要登錄態(tài)的fly.post('https://...',?params,?{?needLogin:?true?});//?在?fly?攔截器中處理邏輯fly.interceptors.request.use(async?(req)=>{??//?在請求需要登錄態(tài)的時候
??if?(req.needLogin?!==?false)?{????//?ensureLogin?核心邏輯是：判斷是否已登錄，如否發(fā)起登錄調(diào)用，如果正在登錄，則進入隊列等待回調(diào)。
????await?session.ensureLogin();????
????//?登錄成功后，獲取?token，通過?headers?傳遞給后端。
????const?token?=?await?session.getToken();????Object.assign(req.headers,?{?[AUTH_KEY_NAME]:?token?});
??}??
??return?req;
});復(fù)制代碼

3.1.3 Custom login state Expired fault-tolerance processing

When the custom login state expires, the backend needs to return a specific status code, such as: AUTH_EXPIRED, AUTH_INVALID, etc.

The front end can monitor the status code of all requests in the "network request layer", and then initiate a refresh of the login status, and then replay the failed request:

//?添加響應(yīng)攔截器fly.interceptors.response.use(????(response)?=>?{??????const?code?=?res.data;????????
??????//?登錄態(tài)過期或失效
??????if?(?['AUTH_EXPIRED',?'AUTH_INVALID'].includes(code)?)?{??????
????????//?刷新登錄態(tài)
????????await?session.refreshLogin();????????
????????//?然后重新發(fā)起請求
????????return?fly.request(request);
??????}
????}
)復(fù)制代碼

Then if there are multiple concurrent requests Each request returns a status code indicating that the login status is invalid, and the above code will be executed multiple times.

We need to do some special fault-tolerance processing for session.refreshLogin():

1. Request lock: At the same time, only A network request in progress.
2. Waiting queue: After the request is locked, all calls to this method are pushed into a queue, waiting for the network request to be completed to share the return result.
3. Circuit breaker mechanism: If called multiple times in a short period of time, it will stop responding for a period of time, similar to TCP slow start.

Sample code:

class?Session?{??//?....
??
??//?刷新登錄保險絲，最多重復(fù)?3?次，然后熔斷，5s?后恢復(fù)
??refreshLoginFuseLine?=?REFRESH_LOGIN_FUSELINE_DEFAULT;
??refreshLoginFuseLocked?=?false;
??refreshLoginFuseRestoreTime?=?5000;??//?熔斷控制
??refreshLoginFuse():?Promise<void>?{????if?(this.refreshLoginFuseLocked)?{??????return?Promise.reject('刷新登錄-保險絲已熔斷，請稍后');
????}????if?(this.refreshLoginFuseLine?>?0)?{??????this.refreshLoginFuseLine?=?this.refreshLoginFuseLine?-?1;??????return?Promise.resolve();
????}?else?{??????this.refreshLoginFuseLocked?=?true;??????setTimeout(()?=>?{????????this.refreshLoginFuseLocked?=?false;????????this.refreshLoginFuseLine?=?REFRESH_LOGIN_FUSELINE_DEFAULT;
????????logger.info('刷新登錄-保險絲熔斷解除');
??????},?this.refreshLoginFuseRestoreTime);??????return?Promise.reject('刷新登錄-保險絲熔斷!!');
????}
??}??//?并發(fā)回調(diào)隊列
??refreshLoginQueueMaxLength?=?100;
??refreshLoginQueue:?any[]?=?[];
??refreshLoginLocked?=?false;??//?刷新登錄態(tài)
??refreshLogin():?Promise<void>?{????return?Promise.resolve()????
??????//?回調(diào)隊列?+?熔斷?控制
??????.then(()?=>?this.refreshLoginFuse())
??????.then(()?=>?{????????if?(this.refreshLoginLocked)?{??????????const?maxLength?=?this.refreshLoginQueueMaxLength;??????????if?(this.refreshLoginQueue.length?>=?maxLength)?{????????????return?Promise.reject(`refreshLoginQueue?超出容量：${maxLength}`);
??????????}??????????return?new?Promise((resolve,?reject)?=>?{????????????this.refreshLoginQueue.push([resolve,?reject]);
??????????});
????????}????????this.refreshLoginLocked?=?true;
??????})??????//?通過前置控制之后，發(fā)起登錄過程
??????.then(()?=>?{????????this.clearSession();
????????wx.showLoading({?title:?'刷新登錄態(tài)中',?mask:?true?});????????return?this.login()
??????????.then(()?=>?{
????????????wx.hideLoading();
????????????wx.showToast({?icon:?'none',?title:?'登錄成功'?});????????????this.refreshLoginQueue.forEach(([resolve])?=>?resolve());????????????this.refreshLoginLocked?=?false;
??????????})
??????????.catch(err?=>?{
????????????wx.hideLoading();
????????????wx.showToast({?icon:?'none',?title:?'登錄失敗'?});????????????this.refreshLoginQueue.forEach(([,?reject])?=>?reject());????????????this.refreshLoginLocked?=?false;????????????throw?err;
??????????});
??????});??//?...}復(fù)制代碼</void></void>

3.1.4 Fault tolerance processing of WeChat session_key expiration

After we start the "silent login" above, the WeChat server will issue A session_key is given to the backend, and this will be used when it is necessary to obtain WeChat open data.

And session_key is time-sensitive. The following is taken from the official description of WeChat:

Session key session_key validity

If developers encounter signature verification failure or decryption failure due to incorrect session_key, please pay attention to the following precautions related to session_key.

1. wx.login 調(diào)用時，用戶的 session_key 可能會被更新而致使舊 session_key 失效（刷新機制存在最短周期，如果同一個用戶短時間內(nèi)多次調(diào)用 wx.login，并非每次調(diào)用都導(dǎo)致 session_key 刷新）。開發(fā)者應(yīng)該在明確需要重新登錄時才調(diào)用 wx.login，及時通過 auth.code2Session 接口更新服務(wù)器存儲的 session_key。
2. 微信不會把 session_key 的有效期告知開發(fā)者。我們會根據(jù)用戶使用小程序的行為對 session_key 進行續(xù)期。用戶越頻繁使用小程序，session_key 有效期越長。
3. 開發(fā)者在 session_key 失效時，可以通過重新執(zhí)行登錄流程獲取有效的 session_key。使用接口 wx.checkSession可以校驗 session_key 是否有效，從而避免小程序反復(fù)執(zhí)行登錄流程。
4. 當(dāng)開發(fā)者在實現(xiàn)自定義登錄態(tài)時，可以考慮以 session_key 有效期作為自身登錄態(tài)有效期，也可以實現(xiàn)自定義的時效性策略。

翻譯成簡單的兩句話：

1. session_key 時效性由微信控制，開發(fā)者不可預(yù)測。
2. wx.login 可能會導(dǎo)致 session_key 過期，可以在使用接口之前用 wx.checkSession 檢查一下。

而對于第二點，我們通過實驗發(fā)現(xiàn)，偶發(fā)性的在 session_key 已過期的情況下，wx.checkSession 會概率性返回 true

社區(qū)也有相關(guān)的反饋未得到解決：

• 小程序解密手機號,隔一小段時間后,checksession:ok,但是解密失敗
• wx.checkSession有效，但是解密數(shù)據(jù)失敗
• checkSession判斷session_key未失效，但是解密手機號失敗

所以結(jié)論是：wx.checkSession可靠性是不達 100% 的。

基于以上，我們需要對 session_key 的過期做一些容錯處理：

1. 發(fā)起需要使用 session_key 的請求前，做一次 wx.checkSession 操作，如果失敗了刷新登錄態(tài)。
2. 后端使用 session_key 解密開放數(shù)據(jù)失敗之后，返回特定錯誤碼（如：DECRYPT_WX_OPEN_DATA_FAIL），前端刷新登錄態(tài)。

示例代碼：

//?定義檢查?session_key?有效性的操作const?ensureSessionKey?=?async?()?=>?{??const?hasSession?=?await?new?Promise(resolve?=>?{
????wx.checkSession({??????success:?()?=>?resolve(true),??????fail:?()?=>?resolve(false),
????});
??});??
??if?(!hasSession)?{
????logger.info('sessionKey?已過期，刷新登錄態(tài)');????//?接上面提到的刷新登錄邏輯
????return?session.refreshLogin();
??}??return?Promise.resolve();
}//?在發(fā)起請求的時候，先做一次確保?session_key?最新的操作（以?fly.js?作為網(wǎng)絡(luò)請求層為例）const?updatePhone?=?async?(params)?=>?{??await?ensureSessionKey();??const?res?=?await?fly.post('https://xxx',?params);
}//?添加響應(yīng)攔截器,?監(jiān)聽網(wǎng)絡(luò)請求返回fly.interceptors.response.use(????(response)?=>?{??????const?code?=?res.data;????????
??????//?登錄態(tài)過期或失效
??????if?(?['DECRYPT_WX_OPEN_DATA_FAIL'].includes(code))?{????????//?刷新登錄態(tài)
????????await?session.refreshLogin();????????
????????//?由于加密場景的加密數(shù)據(jù)由用戶點擊產(chǎn)生，session_key?可能已經(jīng)更改，需要用戶重新點擊一遍。
????????wx.showToast({?title:?'網(wǎng)絡(luò)出小差了，請稍后重試',?icon:?'none'?});
??????}
????}
)復(fù)制代碼

3.2 授權(quán)的實現(xiàn)

3.2.1 組件拆分與設(shè)計

在用戶信息和手機號獲取的方式上，微信是以 <button open-type="'xxx'"></button> 的方式，讓用戶主動點擊授權(quán)的。

那么為了讓代碼更解耦，我們設(shè)計這樣三個組件：

1. <user-contaienr getuserinfo="onUserInfoAuth"></user-contaienr>: 包裝點擊交互，通過 <slot></slot> 支持點擊區(qū)域的自定義UI。
2. <phone-container getphonennmber="onPhoneAuth"></phone-container> : 與 <user-container></user-container> 同理。
3. <auth-flow></auth-flow>: 根據(jù)業(yè)務(wù)需要，組合 <user-container></user-container>、<phone-container></phone-container> 組合來定義不同的授權(quán)流程。

以開頭的業(yè)務(wù)場景的流程為例，它有這樣的要求：

1. 有多個步驟。
2. 如果中途斷掉了，可以從中間接上。
3. 有些場景中，只要求達到「用戶信息授權(quán)」，而不需要完成「用戶手機號」。

那么授權(quán)的階段可以分三層：

//?用戶登錄的階段export?enum?AuthStep?{??//?階段一：只有登錄態(tài)，沒有用戶信息，沒有手機號
??ONE?=?1,??//?階段二：有用戶信息，沒有手機號
??TWO?=?2,??//?階段三：有用戶信息，有手機號
??THREE?=?3,
}復(fù)制代碼

AuthStep 的推進過程是不可逆的，我們可以定義一個 nextStep 函數(shù)來封裝 AuthStep 更新的邏輯。外部使用的話，只要無腦調(diào)用 nextStep 方法，等待回調(diào)結(jié)果就行。

示例偽代碼：

//?auth-flow?componentComponent({??//?...
??
??data:?{????//?默認(rèn)情況下，只需要到達階段二。
????mustAuthStep:?AuthStep.TWO
??},??
??//?允許臨時更改組件的需要達到的階段。
??setMustAuthStep(mustAuthStep:?AuthStep)?{????this.setData({?mustAuthStep?});
??},??
??//?根據(jù)用戶當(dāng)前的信息，計算用戶處在授權(quán)的階段
??getAuthStep()?{????let?currAuthStep;????
????//?沒有用戶信息，尚在第一步
????if?(!session.hasUser()?||?!session.hasUnionId())?{
??????currAuthStep?=?AuthStepType.ONE;
????}????//?沒有手機號，尚在第二步
????if?(!session.hasPhone())?{
??????currAuthStep?=?AuthStepType.TWO;
????}????//?都有，尚在第三步
????currAuthStep?=?AuthStepType.THREE;????return?currAuthStep;
??}??
??//?發(fā)起下一步授權(quán)，如果都已經(jīng)完成，就直接返回成功。
??nextStep(e)?{????const?{?mustAuthStep?}?=?this.data;????const?currAuthStep?=?this.updateAuthStep();??
????//?已完成授權(quán)
????if?(currAuthStep?>=?mustAuthStep?||?currAuthStep?===?AuthStepType.THREE)?{??????//?更新全局的授權(quán)Understand the front-end design and implementation of WeChat mini program login，廣播消息給訂閱者。
??????return?getApp().status.auth.success();
????}????//?第一步：更新用戶信息
????if?(currAuthStep?===?AuthStepType.ONE)?{??????//?已有密文信息，更新用戶信息
??????if?(e)?session.updateUser(e);??????//?更新到視圖層，展示對應(yīng)UI，等待獲取用戶信息
??????else?this.setData({?currAuthStep?});??????return;
????}????//?第二步：更新手機信息
????if?(currAuthStep?===?AuthStepType.TWO)?{??????//?已有密文信息，更新手機號
??????if?(e)?this.bindPhone(e);??????//?未有密文信息，彈出獲取窗口
??????else?this.setData({?currAuthStep?});??????return;
????}????console.warn('auth.nextStep?錯誤',?{?currAuthStep,?mustAuthStep?});
??},??
??//?...});復(fù)制代碼

那么我們的 <auth-flow></auth-flow> 中就可以根據(jù) currAuthStep 和 mustAuthStep 來去做不同的 UI 展示。需要注意的是使用 <user-container></user-container>、<phone-container></phone-container> 的時候連接上 nextStep(e) 函數(shù)。

示例偽代碼：

<view>

??<!-- 已完成授權(quán) -->
??<block>
????<view>已完成授權(quán)</view>
??</block>

??<!-- 未完成授權(quán)，第一步：Understand the front-end design and implementation of WeChat mini program login -->
??<block>
????<user-container>
??????<view>Understand the front-end design and implementation of WeChat mini program login</view>
????</user-container>
??</block>

??<!-- 未完成授權(quán)，第二步：Understand the front-end design and implementation of WeChat mini program login -->
??<block>
????<phone-container>
??????<view>Understand the front-end design and implementation of WeChat mini program login</view>
????</phone-container>
??</block>
??</view>復(fù)制代碼

3.2.2 權(quán)限攔截的處理

到這里，我們制作好了用來承載授權(quán)流程的組件 <auth-flow></auth-flow> ，那么接下來就是決定要使用它的時機了。

我們梳理需要授權(quán)的場景：

1. 點擊某個按鈕，例如：購買某個商品。

   對于這種場景，常見的是通過彈窗完成授權(quán)，用戶可以選擇關(guān)閉。

   

2. 瀏覽某個頁面，例如：訪問個人中心。

   對于這種場景，我們可以在點擊跳轉(zhuǎn)某個頁面的時候，進行攔截，彈窗處理。但這樣的缺點是，跳轉(zhuǎn)到目標(biāo)頁面的地方可能會很多，每個都攔截，難免會錯漏。而且當(dāng)目標(biāo)頁面作為「小程序落地頁面」的時候，就避免不了。

   這時候，我們可以通過重定向到授權(quán)頁面來完成授權(quán)流程，完成之后，再回來。

   

那么我們定義一個枚舉變量：

//?授權(quán)的展示形式export?enum?AuthDisplayMode?{??//?以彈窗形式
??POPUP?=?'button',??//?以頁面形式
??PAGE?=?'page',
}復(fù)制代碼

我們可以設(shè)計一個 mustAuth 方法，在點擊某個按鈕，或者頁面加載的時候，進行授權(quán)控制。

偽代碼示例：

class?Session?{??//?...
??
??mustAuth({
????mustAuthStep?=?AuthStepType.TWO,?//?需要授權(quán)的LEVEL，默認(rèn)需要獲取用戶資料
????popupCompName?=?'auth-popup',	//?授權(quán)彈窗組件的?id
????mode?=?AuthDisplayMode.POPUP,?//?默認(rèn)以彈窗模式
??}?=?{}):?Promise<void>?{????
????//?如果當(dāng)前的授權(quán)步驟已經(jīng)達標(biāo)，則返回成功
????if?(this.currentAuthStep()?>=?mustAuthStep)?return?Promise.resolve();????//?嘗試獲取當(dāng)前頁面的?<auth-popup></auth-popup>?組件實例
????const?pages?=?getCurrentPages();????const?curPage?=?pages[pages.length?-?1];????const?popupComp?=?curPage.selectComponent(`#${popupCompName}`);????//?組件不存在或者顯示指定頁面，跳轉(zhuǎn)到授權(quán)頁面
????if?(!popupComp?||?mode?===?AuthDisplayMode.PAGE)?{??????const?curRoute?=?curPage.route;??????//?跳轉(zhuǎn)到授權(quán)頁面，帶上當(dāng)前頁面路由，授權(quán)完成之后，回到當(dāng)前頁面。
??????wx.redirectTo({?url:?`authPage?backTo=${encodeURIComponent(curRoute)}`?});??????return?Promise.resolve();
????}????
????//?設(shè)置授權(quán)?LEVEL，然后調(diào)用?<auth-popup>?的?nextStep?方法，進行進一步的授權(quán)。
????popupComp.setMustAuthStep(mustAuthStep);
????popupComp.nextStep();????//?等待成功回調(diào)或者失敗回調(diào)
????return?new?Promise((resolve,?reject)?=>?{??????const?authStatus?=?getApp().status.auth;
??????authStatus.onceSuccess(resolve);
??????authStatus.onceFail(reject);
????});
??}??
??//?...}復(fù)制代碼</auth-popup></void>

那么我們就能在按鈕點擊，或者頁面加載的時候進行授權(quán)攔截：

Page({??onLoad()?{
????session.mustAuth().then(()?=>?{??????//?開始初始化頁面...
????})；
??}??
??onClick(e)?{
????session.mustAuth().then(()?=>?{??????//?開始處理回調(diào)邏輯...
????})；
??}
})復(fù)制代碼

當(dāng)然，如果項目使用了 TS 的話，或者支持 ES7 Decorator 特性的話，我們可以為 mustAuth 提供一個裝飾器版本：

export?function?mustAuth(option?=?{})?{??return?function(
????_target,
????_propertyName,
????descriptor,??)?{????//?劫持目標(biāo)方法
????const?method?=?descriptor.value;????
????//?重寫目標(biāo)方法
????descriptor.value?=?function(...args:?any[])?{??????return?session.mustAuth(option).then(()?=>?{????????//?登錄完成之后，重放原來方法
????????if?(method)?return?method.apply(this,?args);
??????});
????};
??};
}復(fù)制代碼

那么使用方式就簡單一些了：

Page({
??@mustAuth();??onLoad()?{????//?開始初始化頁面...
??}
??
??@mustAuth();??onClick(e)?{????//?開始處理回調(diào)邏輯...
??}
});復(fù)制代碼

3.3. 前后端交互協(xié)議整理

作為一套可復(fù)用的小程序登錄方案，當(dāng)然需要去定義好前后端的交互協(xié)議。

那么整套登錄流程下來，需要的接口有這么幾個：

1. 靜默登錄 silentLogin

   1. 入?yún)ⅲ?ol>
   2. code: 產(chǎn)自 wx.login()
2. 出參：
   1. token: 自定義登錄態(tài)憑證
   2. userInfo: 用戶信息
3. 說明：
   1. 后端利用 code 跟微信客戶端換取用戶標(biāo)識，然后注冊并登錄用戶，返回自定義登錄態(tài) token 給前端
   2. token 前端會存起來，每個請求都會帶上
   3. userInfo 需要包含nickname和phone字段，前端用于計算當(dāng)前用戶的授權(quán)階段。當(dāng)然這個狀態(tài)的記錄可以放在后端，但是我們認(rèn)為放在前端，會更加靈活。

五. 架構(gòu)圖

最后我們來梳理一下整體的「登錄服務(wù)」的架構(gòu)圖：

由「登錄服務(wù)」和「底層建設(shè)」組合提供的通用服務(wù)，業(yè)務(wù)層只需要去根據(jù)產(chǎn)品需求，定制授權(quán)的流程 <auth-flow></auth-flow> ，就能滿足大部分場景了。

六. 總結(jié)

本篇文章通過一些常見的登錄授權(quán)場景來展開來描述細(xì)節(jié)點。

整理了「登錄」、「授權(quán)」的概念。

然后分別針對「登錄」介紹了一些關(guān)鍵的技術(shù)實現(xiàn)：

1. Silent login
2. Handling of silent login asynchronous state
3. Fault-tolerant processing of custom login state expiration
4. WeChatsession_key Expired Fault-tolerant processing

As for "authorization", there will be the logic of designing the UI part, and it also needs to involve the splitting of components:

1. Component splitting and design
2. Processing of permission interception

Then, we sorted out the back-end interfaces that this login authorization scheme relies on, and gave the simplest reference protocol.

Finally, from the perspective of "with the goal of precipitating a set of universal mini program login solutions and services", we sorted out the layering at the architectural level.

1. Business customization layer
2. Login service layer
3. Underlying construction

Related free learning recommendations:WeChat Mini Program Development

The above is the detailed content of Understand the front-end design and implementation of WeChat mini program login. For more information, please follow other related articles on the PHP Chinese website!