Comment résoudre le problème de séparation du front-end et du back-end dans la connexion autorisée à Vue WeChat

Cet article présente principalement une solution détaillée et élégante pour séparer le front-end et le back-end de la connexion autorisée à Vue WeChat. Le contenu est assez bon. Je vais le partager avec vous maintenant et le donner comme référence.

La connexion autorisée WeChat est un scénario très courant. En utilisant la connexion autorisée WeChat, nous pouvons facilement obtenir certaines informations de l'utilisateur et créer une base de données pour lier l'identité de l'utilisateur via l'openid unique de l'utilisateur pour le compte officiel.

Le mécanisme de connexion autorisée par WeChat ne sera pas décrit en détail ici. Les documents officiels de WeChat l'ont déjà détaillé. La brève description consiste à accéder à la page autorisée de WeChat. Après que l'utilisateur ait cliqué pour confirmer, WeChat le fera. Accédez à la page de rappel. À ce moment, l'URL de la page de rappel portera le paramètre code, via le paramètre code, le backend peut échanger le code contre le support openid ou les informations utilisateur

Dans un projet Vue, c'est le cas. généralement une application SPA, c'est-à-dire que toutes les pages sont identiques. Le HTML est généralement développé avec le front-end et le back-end complètement séparés. Les fichiers statiques purs générés après l'empaquetage de Vue peuvent même ne pas passer par le serveur, ce n'est donc pas très. élégant pour faire des sauts dans le back-end. Cet article présente WeChat pour de tels scénarios Connexion autorisée

Pour une application Vue SPA, nous pouvons généralement avoir de nombreuses pages sur le compte officiel WeChat. configurer plusieurs menus. Plusieurs menus correspondent à la page de routage de Vue, mais ils peuvent ne pas l'être. Chaque page nécessite l'autorisation de l'utilisateur pour entrer. Certaines pages doivent être prévisualisées par les utilisateurs sans se connecter. Pour le moment, nous pouvons utiliser vue router pour l'implémenter. Interception de routage frontal

 router.beforeEach(async (to, from, next) => {
 if (to.matched.some(recode => recode.meta.noAuth)) {
  next()
 } else {
  // store已存在用户信息直接进入页面
  if (store.state.userInfo.nickname) {
   next()
   return
  }
  const code = getUrl(window.location.href).code // 截取url上的code ,可能没有,则返回''空字符串
  let res = await api.post('/imsl/user/user-auth', [code]) // 获取用户信息,后端可首先通过cookie,session等判断,没有信息则通过code获取
  console.log(res)
  // 返回用户信息
  if (res.code === 200 && res.data.is_auth) {
   store.commit('setUserInfo', res.data)
   next()
  } else {
   // 此状态根据业务需求 可能不存在
   if (res.code === 201) {
    const openid = res.data.openid
    console.log(openid)
    store.commit('setOpenid', openid)
    localStorage.setItem('openid', openid)
    next('/enlist-info')
   }
   // 上面的获取用户信息接口,如果cookie,session拿不到用户信息,且传递的code为空,则跳转到微信授权页面
   if (res.code === 202) {
    console.log(window.location.origin)
    console.log(to.fullPath)
    // 这个redirectUrl用 当前页路径或者tof.fullPath(将要进入的路径)
    let redirectUrl = window.location.href
    redirectUrl = encodeURIComponent(redirectUrl)
    console.log(redirectUrl)
    const appid='wxdff0642c2120ea39'
    window.location.href = `https://open.weixin.qq.com/connect/oauth2/authorize?appid=${appid}&redirect_uri=${redirectUrl}&response_type=code&scope=snsapi_userinfo&state=123#wechat_redirect`
   }
  }
 }
})

Le code ci-dessus explique essentiellement un processus d'autorisation. Tout d'abord, lorsque nous configurons la route vue, nous définissons si cette route nécessite une connexion, c'est-à-dire que nous ajoutons un noAuth : true attribut à la méta du routeur. Ceci sert à gérer les pages qui ne nécessitent pas de connexion. Il est jugé via router.beforeEach Si ce n'est pas requis Page de connexion : noAuth, alors directement next() laissez-le entrer dans la page correspondante. qui nécessitent une connexion, laissez le backend coopérer. À ce stade, le backend écrit une interface pour obtenir les informations utilisateur, et le frontend appelle directement l'interface pour obtenir les informations utilisateur. L'interface, bien sûr, n'a pas besoin d'être appelée sur chaque page. .Après l'avoir obtenu une fois, les informations utilisateur peuvent être stockées dans vuex, donc en jugeant s'il y a des informations utilisateur dans vuex, si les informations utilisateur existent déjà, entrez dans la page. S'il n'y a pas d'informations utilisateur, appelez-la L'interface pour. le backend pour obtenir les informations sur l'utilisateur. En parlant de cela, nous revenons enfin au sujet de cet article. Les informations sur l'utilisateur sont obtenues via une connexion autorisée à WeChat. Ici, vous pouvez en discuter avec ? le backend. , une fois que l'utilisateur a lié son identité, le backend peut enregistrer le statut de connexion de l'utilisateur en définissant des cookies, des jetons, etc. S'il existe un statut pertinent, le backend peut renvoyer directement les informations de l'utilisateur si c'est la première fois. entrez, ou entre les cookies et les jetons, la classe a expiré, alors l'autorisation WeChat sera appelée pour se connecter à ce moment. Comme mentionné dans le code ci-dessus, elle est divisée en trois situations,

1. Grâce aux cookies, aux jetons, etc., le backend obtient directement les informations de l'utilisateur, à ce moment, vous obtiendrez les informations de l'utilisateur et entrerez directement dans la page, et en même temps stockerez les informations de l'utilisateur dans vuex

2. S'il n'y a aucune information utilisateur, il n'y a pas de cookie ou de jeton pour le moment, vous devez alors réinvoquer l'autorisation WeChat pour vous connecter. Les deux codes de retour code=201 et code=202 donnés ci-dessus, lorsque code=2. , le front-end passe directement à la page d'autorisation WeChat, et redirectUri est la page à entrer. Que se passera-t-il à ce moment-là ? Une fois que l'utilisateur aura cliqué, il reviendra à cette page. La différence est que l'URL contient déjà le code. Le front-end obtient le code par interception de chaîne et l'envoie au back-end. Le client peut échanger des informations sur l'openid et l'utilisateur via le code

. Résumé :

1. Avant et après l'adoption du projet Méthode de séparation complète de bout en bout, c'est-à-dire que les fichiers statiques purs emballés sont placés sur le serveur . Lors de l'accès à index.html

2. , le backend n'intercepte pas au niveau de l'interface et il n'est pas nécessaire que le backend accède à la page de connexion d'autorisation WeChat, le front-end. le routage intercepte le saut et la méthode d'implémentation est la suivante : 3.

3. Le front-end intercepte la page qui nécessite que l'identité de l'utilisateur entre via la fonction de hook router.beforeEach de vue- routeur et l'appelle à ce moment-là. Obtenez l'interface d'informations sur l'utilisateur. Le backend détermine d'abord l'utilisateur en obtenant des cookies, des jetons, etc. S'il n'y a pas d'informations pertinentes, il renvoie 201 ou 202. Lorsque 202 est renvoyé, le frontend passe au Page d'autorisation WeChat. La redirecturi est l'URL de la page à saisir. Après la sous-autorisation, WeChat portera le code sur l'url et reviendra à la page actuelle. url et le transmet au back-end. Le back-end traite le code pour obtenir les informations utilisateur OpenID, etc. réaliser une connexion autorisée

Ce qui précède est l'intégralité du contenu de ceci. Article. J'espère qu'il sera utile à l'étude de tout le monde. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois !

Recommandations associées :

Comment résoudre le problème de page blanche après le routage du packaging en mode Historique sous Vue

Utilisation de $refs dans Vue

À propos de l'implémentation des fonctions de vérification de formulaire vue et vue-validator

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!