vue-nuxt 登录鉴权的实现

目录
  • 介绍
  • 链接
  • 开始
  • 继续往代码中走
  • proxy配置
  • 请求拦截
  • 处理不同前缀的接口
  • 动态路由的配置
  • 重定向及auth权限

介绍

来自mentor的梳理,做个总结和记录

链接

https://auth.nuxtjs.org/api/options/#cookie

开始

根据这个文档描述,在使用@nuxt/auth 后,如果没有显示指定cookie: false, 则auth token 会被默认存储在 cookie 里 (前面localstorage 也是一样)
所以在 login接口成功后,token 就会以 auth._token.{provider} 的形式存储

之后接口在请求时从cookie里拿token并作为接口凭证 发送给服务端。

目录结构

nuxt-dist 是每次npm run dev 或者 npm run build 后 webpack生成的文件,这里面的代码可以看做是我们最后实际调用的代码 (也可以直接在这里修改和debug,但每次重新跑项目就会还原)。

nuxt/auth 有几个schemes 方案,比如看这个 nuxt-dist/auth/schemes/local.js
这里有几个默认选项:

在我们写的代码里,是用 $auth.loginWith 调用的方式,而实际上,loginWith最终还是调用的是 login

那看下login, 还是在 nuxt-dist/auth/schemes/local.js里

nuxt-dist 是每次npm run dev 或者 npm run build 后 webpack生成的文件,这里面的代码可以看做是我们最后实际调用的代码 (也可以直接在这里修改和debug,但每次重新跑项目就会还原)。
nuxt/auth 有几个schemes 方案,比如看这个 nuxt-dist/auth/schemes/local.js
这里有几个默认选项:

在我们写的代码里,是用 $auth.loginWith 调用的方式,而实际上,loginWith最终还是调用的是 login

那看下login, 还是在 nuxt-dist/auth/schemes/local.js里

方法里的this.name, 就是auth.strategy, 也就是 local, local1 那些, 并且在上面 loginWith 方法里的 setStrategy() 将 auth.strategy 信息存到本地。
成功后,tokenRequired 默认为true, 调用了 this.$auth.setToken, 这个方法在auth/schemes/auth.js 里

这个方法里的

在这个方法里,_key 被组装成了._token.local
这个方法在 auth/storage.js 里

最终这个方法调用了 setCookie 和 serLocalStorage 方法, 把token存在coookie 和 localstorage里
而在setCookie里,再次组装,加上了cookir.prefix ,默认是auth

最终经过序列化后,存储在cookie里。
后续axios则直接在cookir里拿,并随请求发送。

整个登录和鉴权逻辑基本就是这样。

继续往代码中走

nuxt.config.js 中还可以配置多个 auth: {strategies: {local

微信登录,手机号登录,账号登陆…

autoFetch

https://auth.nuxtjs.org/schemes/local
Fetch User
uth 模块不保存有关用户的信息,因此需要有一种方法来获取用户的信息,例如页面重新加载。这就是用户端点的用途。默认情况下,这也会在成功登录后调用。

如果user.autoFetch为 true (默认),则endpoints.user在成功登录后立即发送请求 。该端点应使用特定用户的 JSON 信息进行响应,该信息直接分配给user 属性。

如果您希望直接从登录会话返回用户信息,请配置user.autoFetch为 false,从loginWith响应中获取用户信息 ,并将其传递给setUser.

如果要完全禁用获取用户信息,请设置endpoints.user: false. 这意味着永远不会调用用户信息端点,但也意味着前端对用户一无所知;this.$auth.user将{}。

ps: 由于需要对接口进行替换,user会自动去查询,造成的报错不利于开发,可以通过注释,一步一步向下开发。

user: {
          autoFetch: false,
      },

proxy配置

项目的后端接口基于后端低代码平台和java接口,接口开头的名称不一致,可以通过proxy来处理,也可以解决跨域问题。

	axios: {
    // // baseURL:''
    proxy: true,
    prefix: '/',
    // credentials: false,
  },
   proxy: {
    '/biz': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/biz': '/biz/',
        changeOrigin: true // 表示是否跨域
      }
    },
    '/front': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/front': '/api/front',
        changeOrigin: true // 表示是否跨域
      }
    },

请求拦截

	axios: {
    // // baseURL:''
    proxy: true,
    prefix: '/',
    // credentials: false,
  },
   proxy: {
    '/biz': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/biz': '/biz/',
        changeOrigin: true // 表示是否跨域
      }
    },
    '/front': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/front': '/api/front',
        changeOrigin: true // 表示是否跨域
      }
    },

处理不同前缀的接口

dev 用于本地dev环境,部署至服务器不能这么用。
你定义一个文件,比如叫 apiPrefix.js
这个文件里,你枚举出所有不同的接口和他们前缀的对应关系

const temp = {
api: ['/front/login', ‘xxxxxx', ‘xxxxx'],
api2: ['/test', ‘xxxxxx'],
xxx: […]
}

这样等于说显式的把你所有的需要用到前缀的接口,都列举出来了。
在axios的请求拦截里,根据当前的请求url,去遍历temp, 判断出是属于哪个前缀的,然后组装上去。
对于那些在这个temp里无法找到归属的请求,那就是默认不需要加前缀的,直接放过好了。

这样的好处有三个,
一是你维护的时候,能一眼看出,你的哪些接口,是需要加什么样前缀的
二是,你在页面发起请求的时候,能保证同样的调用方式,不需要在每个url上改动。
三是如果后续批量前缀修改,你改的容易

如果生产环境需要调用其他服务器接口,那肯定也是要有一定规则的,有规则的话,我们匹配规则然后修改。
或者是一部分接口。那这样的话,我们也可以用上述这种类似的方法,无非是变成了

const temp = {
http://10.0.0.1/api: ['/front/login', ‘xxxxxx', ‘xxxxx'],
http://10.0.0.1/api2: ['/test', ‘xxxxxx'],
http://10.0.0.1/xxx: […],
…
http://10.0.1.111/api: ['/sth/xxx']
}

将前缀范围,扩展到包含协议和域名

动态路由的配置

https://www.nuxtjs.cn/guide/routing
你会发现名称为 users-id 的路由路径带有 :id? 参数,表示该路由是可选的。如果你想将它设置为必选的路由,需要在 users/_id 目录内创建一个 index.vue 文件。

nuxt-dist会自动打包生成配置

重定向及auth权限

https://auth.nuxtjs.org/guide/middleware
这里说的是 auth的权限验证 可以放在全局 也可以放在每个路由里。也可以关闭,以便中间件跳过检查。最后它还介绍了一种用法,guest 模式,就是说访问这个路由不必非得登录,但是如果是登录用户访问此页面,则会被重定向到 redirect.home 所设置的路由

场景
有些场景需要登陆状态下才能访问,不然就会被重定向到/login页面,现在做了处理,就可以通过设置auth:false,来处理一些页面,让他不用重定向到login,如我现在所遇到的一个页面,是通过后台生成一个注册链接,然后才能注册的,这个页面不需要token信息。

到此这篇关于vue-nuxt 登录鉴权的实现的文章就介绍到这了,更多相关vue-nuxt 登录鉴权内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • vue-nuxt 登录鉴权的实现

    目录 介绍 链接 开始 继续往代码中走 proxy配置 请求拦截 处理不同前缀的接口 动态路由的配置 重定向及auth权限 介绍 来自mentor的梳理,做个总结和记录 链接 https://auth.nuxtjs.org/api/options/#cookie 开始 根据这个文档描述,在使用@nuxt/auth 后,如果没有显示指定cookie: false, 则auth token 会被默认存储在 cookie 里 (前面localstorage 也是一样) 所以在 login接口成功后,t

  • 详解nuxt路由鉴权(express模板)

    这里我们以用户登录鉴权为例 express依赖express-session中间件实现session功能 若我们不加载express-session组件 router.get('/user/login', function (req, res) { console.log(req,req.session) }) 会发现不存在session对象 引入express-session组件 // server/index.js文件 ... import session from 'express-ses

  • vue element后台鉴权流程分析

    前言: 最近项目遇到一个管理系统,感觉权限配置挺有意思,记录一下流程实现的过程,便于自己学习以及整理思路,部分思路整合在代码的注释中: 路由拦截鉴权常用的两种方法 1:路由拦截:单纯给路由加字段标识符,通过路由拦截实现 2:动态路由:第二种是通过路由的拆分另外需要后端的配合去实现的动态路由配置 比较: 路由拦截实现方式比较简单,只需要简单的在router.beforeEach中根据路由配置信息过滤页面是否有权限前往改组件,若相对于的权限不够则不前往相应的组件 动态路由实现相对比较复杂,并且需要后

  • 一步步教会你微信小程序的登录鉴权

    前言 为了方便小程序应用使用微信登录态进行授权登录,微信小程序提供了登录授权的开放接口.乍一看文档,感觉文档上讲的非常有道理,但是实现起来又真的是摸不着头脑,不知道如何管理和维护登录态.本文就来手把手的教会大家在业务里如何接入和维护微信登录态,下面话不多说了,来一起看看详细的介绍吧. 接入流程 这里官方文档上的流程图已经足够清晰,我们直接就该图展开详述和补充. 首先大家看到这张图,肯定会注意到小程序进行通信交互的不止是小程序前端和我们自己的服务端,微信第三方服务端也参与其中,那么微信服务端在其中

  • 基于PHP实现JWT登录鉴权的示例代码

    目录 一.什么是JWT 1.简介 2.JWT的组成 3.JWT验证流程和特点 二.相关问题 三.PHP实现 1.引入依赖 2.功能实现 3.封装工具类如下 一.什么是JWT 1.简介 JWT(JSON Web Token)是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准. 简单的说,JWT就是一种Token的编码算法,服务器端负责根据一个密码和算法生成Token,然后发给客户端,客户端只负责后面每次请求都在HTTP header里面带上这个Token,服务器负责验证这个Token

  • 详解如何使用Vuex实现Vue后台管理中的角色鉴权

    目录 前言 功能分析 实现思路 代码实现 vuex中定义user模块,存储用户信息以及用户侧边导航数据 router中路由meta中新增roles 定义当前路由可以访问的所有的角色 router新增路由前置首位 做权限拦截 侧边导航页面 使用 getters中的 authMenus 循环侧边导航 最后一步 登录页登录时调用 请求登录的action即可大功告成 总结 前言 一直以来,我们使用vue做后台管理时,不同角色的权限功能,都是我们老大难的问题,本篇文章我将手把你带你实现vue后台管理中的用

  • React路由鉴权的实现方法

    前言 上一篇文章中有同学提到路由鉴权,由于时间关系没有写,本文将针对这一特性对 vue 和 react 做专门说明,希望同学看了以后能够受益匪浅,对你的项目能够有所帮助,本文借鉴了很多大佬的文章篇幅也是比较长的. 背景 单独项目中是希望根据登录人来看下这个人是不是有权限进入当前页面.虽然服务端做了进行接口的权限,但是每一个路由加载的时候都要去请求这个接口太浪费了.有时候是通过SESSIONID来校验登陆权限的. 在正式开始 react 路由鉴权之前我们先看一下vue的路由鉴权是如何工作的: 一.

  • springCloud gateWay 统一鉴权的实现代码

    目录 一,统一鉴权 1.1鉴权逻辑 1.2代码实现 一,统一鉴权 内置的过滤器已经可以完成大部分的功能,但是对于企业开发的一些业务功能处理,还是需要我们自己 编写过滤器来实现的,那么我们一起通过代码的形式自定义一个过滤器,去完成统一的权限校验. 1.1 鉴权逻辑 开发中的鉴权逻辑: 当客户端第一次请求服务时,服务端对用户进行信息认证(登录) 认证通过,将用户信息进行加密形成token,返回给客户端,作为登录凭证 以后每次请求,客户端都携带认证的token 服务端对token进行解密,判断是否有效

  • nuxt框架中路由鉴权之Koa和Session的用法

    引子 博客的后台管理页面需要有登录系统,所以考虑做一下路由鉴权,实现方式也是 Nuxt 官网给出栗子来改写,顺便也将前后端路由给统一了. 路由拦截 前端方面主要通过利用 Nuxt 的中间件来做路由拦截,这里也是需要 Vuex 状态树来做. middleware middleware/auth.js export default function ({ store, redirect }) { if (!store.state.user) { return redirect('/login') }

  • Vue中axios的封装(报错、鉴权、跳转、拦截、提示)

    统一捕获接口报错 弹窗提示 报错重定向 基础鉴权 表单序列化 实现的功能 统一捕获接口报错 : 用的axios内置的拦截器 弹窗提示: 引入 Element UI 的 Message 组件 报错重定向: 路由钩子 基础鉴权: 服务端过期时间戳和token,还有借助路由的钩子 表单序列化: 我这边直接用 qs (npm模块),你有时间也可以自己写 用法及封装 用法 // 服务层 , import默认会找该目录下index.js的文件,这个可能有小伙伴不知道 // 可以去了解npm的引入和es6引入

随机推荐