Authorization vs Login

In this article I carefully talked about the small program login related knowledge. So why does the user need to authorize the developer after logging in? Logging in is essentially telling developers a unique USER ID that the widget can identify whenever the user enters the app. Sometimes, however, developers may need to know more about the user than just recognize it. For example, to build a small app for shopping, the developer might need to know the user’s phone number so that they can text the user when the order is shipped. In order to obtain some additional attribute information about the user, user authorization is required. Wechat has good privacy protection for users. If developers want to obtain users’ information, wechat will let users know by authorization popup. Only when users know and agree, developers can obtain information other than the user’S ID.

Wechat in the way of authorization comparison

Several authorization methods commonly used in wechat are as follows:

  1. Direct invocation of specific API invokes popup authorization: For apis that require authorization, if the developer directly invokes this API, wechat will pop up an authorization popup first, asking the user to confirm, and the result will be returned only after the user authorizes, otherwise the call will fail.
  2. Authorize in advance through wx.authorize: Authorize in advance through the Wx. authorize API, and record the results whether the user permits or not. The user does not need to confirm again when calling the API that requires this authorization.
  3. Click the button to invoke authorization: For the user’s sensitive information, user’s mobile phone number and other information, the developer cannot actively invoke the pop-up window, but the user must actively click the button to authorize, and the sensitive information also needs to cooperate with the back-end for symmetric encryption and decryption, so as to get the data; If the user has rejected, clicking the button again will still pop up.

For the first two authorization methods, actually very similar: the user authorization once, unless ** user manually delete the applets, ** otherwise the authorization information will be saved (whether denied or allowed), the subsequent call to the REQUIRED permission API will not pop up again. The differences between the first two authorization modes are as follows: The second mode can manually control the time of the first popup window, while the first mode can only call the specific API. (There is a pitfall where developers can pop up licenses during the startup phase of the mini-application, creating a bad user experience.) The first two authorization methods are very different from the third one. The first two authorization methods are invoked by the developer, and the third authorization method is activated by the user after clicking a button. The first two kinds of authorization information are saved (cleared when the user manually deletes the applet) to ensure that the authorization window does not pop up later. The third kind of authorization information is reauthorized by the user with each click. The information obtained by the first two types of authorization is in plain text. The information obtained by the third type of authorization can be used only after the server decrypts the information.

Decryption of sensitive information

For the API that obtains sensitive user information, such as mobile phone number, the applets client obtains the encrypted mobile phone number. The applets client needs to send the encrypted data to the applets server, and the server decrypts the data with the session_key obtained during user login to obtain the decrypted information. Session_key has the following characteristics:

  1. When wx.login is invoked, the user’s session_key may be updated, making the old session_key invalid. (The refresh mechanism has the shortest period. If the same user invokes wx.login several times in a short period, the session_key may not be refreshed every time.) Developers should only call wx.login when it is clear that they need to log back in and update the session_key stored on the server through auth.code2session.
  2. Wechat will not inform developers of the expiry date of session_key. We renew the session_key based on the user’s behavior with the applet. The more frequently users use applets, the longer the session_key validity period.
  3. If the session_key is invalid, the developer can obtain the valid session_key by executing the login process again. The wx.checkSession interface can be used to verify that the session_key is valid, thus avoiding repeated login processes by applets.
  4. When implementing a custom login state, developers can use the session_key validity period as their own login state validity period or implement a custom validity policy.

According to the above description, we can see that the decryption process should be:

A common pit

The above scenario looks good. The client checks the session validity to determine whether to log in again, thus ensuring that the session_key is valid. As long as the session_key is valid, the decryption will succeed. However, in reality, even if checkSession succeeds, decryption will occasionally fail. The specific reasons can be discussed, but it is true that there are a lot of such jokes in the wechat developer community, such asthis. Finally, the practical process becomes this:Why checkSession succeeds but decryption fails? I have a guess about this, but there is no solid evidence and no reliable statement on the Internet. If you know the reason, you are welcome to communicate with me further.

Refer to the project

Specific implementation can refer to my mall small program project. Project Experience Address: Experience code: Code