table of Contents
1. Third-party application scan code to bind official account
1. Webpage authorization
WeChat developer documentation
The two business scenarios here are
mainly implemented through silent authorization. The authorization link can only be opened on the WeChat client. The main reason is to rely on the callback url in the WeChat authorization link to meet the business scenario.
1. Third-party application scan code to bind official account
The front end first generates a QR code based on the WeChat webpage authorization link (the callback page needs to bring the current user id). After WeChat scans the code, it will automatically request the link, and then jump to the callback page (this page can display basic corporate information and The current user information, and then add a binding button), when you click the binding, the code and userId obtained will be sent to the backend, and the backend will bind.
2. The WeChat terminal authorizes the binding of third-party accounts, and the subsequent authorization is free of login
There are probably two schemes to achieve
The first is to use the front end to jump to the page (there will be multiple jumps)
Click on the link: If the token returned from the backend is expired or not at this time, send a request to the WeChat authorization link (callback url is the application login page). After entering the login page, call the backend to query the token interface according to the code returned by WeChat. The code queries the openid of the current WeChat user, and then sees whether it has been bound to the application account. If it is bound, the token will be calculated directly and returned; if the front-end judges that there is a token, it will jump to the application homepage at this time, otherwise stay on the login page; On the login page, after calling the login verification completion interface, the front end calls the WeChat authorization link again (the callback url is the application home page). After entering the home page, the front end calls the back end to bind the current user according to the code returned by WeChat. You don’t need to log in if you click on the link under the same WeChat account, so that you can log in after one authorization.
The second is to implement redirection through the back-end (originally this method was used for development and testing, but due to environmental mapping issues and some objective reasons, debugging was abandoned and changed to the first method. This method is completely unaware when the user jumps)
Click the link: Regardless of the link, the front end sends a request directly to the WeChat authorization link (the callback url is the backend redirection interface). The backend obtains the openid in the redirection interface according to the code returned by WeChat, and then determines whether there is a bound account. If yes, redirect to the home page and bring the token, if not, redirect to the login page; subsequent login page operations are similar to the first one.
This solution has not been debugged. The only thing I am not sure about is that when the backend redirects to the homepage, it should also wake up a series of interfaces that will be triggered when entering the homepage normally? Theoretically speaking, because the mapping problem was not tested at that time, if you think there are too many jumps, you can try this solution.