Mon idée est de cliquer sur le bouton de connexion pour accéder à une page de transfert de connexion sur le front-end. Dans la logique back-end de cette page de transfert, le paramètre de code est obtenu à partir de l'API https://api.weixin.qq.com. /sns... Lors de l'accès au access_token des informations utilisateur, la relation correspondante entre le access_token et l'openid de l'utilisateur WeChat est enregistrée dans la base de données et un cookie avec la valeur du access_token est défini sur le front-end. Ensuite, toutes les opérations frontales portent ce cookie, et le back-end trouve l'openid correspondant via ce cookie, soumet diverses opérations via app_secret, access_token et d'autres paramètres sur le script du serveur, puis termine l'opération.
Y a-t-il quelque chose qui ne va pas dans ma façon de penser ? Je voudrais vous demander comment autorisez-vous la connexion WeChat dans le projet de séparation front-end et back-end ?
Si vous vous connectez avec une autorisation tierce. . . Vous devez disposer de votre propre système utilisateur. La base de données contient donc les tables openid, access_token et user_id de votre système utilisateur.
À moins que vous n'ayez besoin d'accéder à l'API WeChat pour les opérations frontales, vous devez apporter access_token. Dans ce cas, il existe deux façons, l'une consiste à écrire le access_token sur la page et l'autre à demander à l'utilisateur. api de votre serveur, puis votre serveur démarre à partir de la base de données. La base de données retire le access_token puis demande l'API WeChat. Ce dernier est généralement utilisé, car en plus du access_token, l'interface de connexion générale autorisée nécessite également appid et secret_code, et secret_code ne peut généralement pas être exposé.
Diverses opérations utilisateur peuvent être vérifiées à l'aide de jetons. Ce jeton est un jeton généré par votre système utilisateur. Ce jeton peut être placé dans un cookie.