This is the sixth day of my participation in the August Text Challenge.More challenges in August

There was a problem with the base64 decoding failure of IOS users.

Problem Description:

The user is authorized by Taobao. The authorization information given by Taobao is encrypted by base64 and then spelled in URL and returned to the front end. The front end takes value through URL, and then uses Base64 decoding to obtain data and bind goods. However, there is only one user, and the account cannot be bound all the time.

Front-end development using VUE, the core code is as follows:

import { Base64 } from 'js-base64'; .created() {
    const code = this.$route.query.code;
    
    if (res) {
        try {
            this.code = JSON.parse(Base64.decode(code)); }}}...Copy the code

Because there was only one case of the user with the problem, it was not suspected to be a problem with the code, and it was suspected to be related to the user’s authorization. After a large number of buried data and packet capture tests, it was found to be:

When this.$route.query is obtained at the front end, the “=” of the tail completion in base64 encryption is not fully obtained, resulting in decode failure and empty decryption value.

Reference: Records of iOS Base64 decoding problems

Solutions:

After base64 encryption, then encodeURI, front-end value, decodeURI first, and then Base64 decoding and json. parse deserialization, the core code is as follows:

import { Base64 } from 'js-base64'; .created() {
    const code = this.$route.query.code;
    
    if (res) {
        try {
            let decodeUrl = decodeURI(code); // decodeURI can avoid loss and translation
            this.code = JSON.parse(Base64.decode(decodeUrl)); }}}Copy the code

Note: This url transfer will fail on Both Android and ios

Summary: Since only one user had the problem, everyone else was fine and didn’t think about the code problem at first. Due to the length limitation of the divine plan buried point report, the reported data was not added completely, only to see that the added password in the URL could be obtained, but did not notice that the value was lost at the beginning. Finally, the backend colleagues suggested that this possibility was realized and optimized. At the beginning, I always thought that it was the user authorization problem, and there was something special about the returned authorization information that led to the failure. Embarrassingly, the user applied for another account later, but the authorization was still unsuccessful. Then I realized that it was not accidental. Harm, there are many bugs, only study hard ah!