介紹

來(lái)自mentor的梳理，做個(gè)總結(jié)和記錄

鏈接

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

開(kāi)始

根據(jù)這個(gè)文檔描述，在使用@nuxt/auth 后，如果沒(méi)有顯示指定cookie: false, 則auth token 會(huì)被默認(rèn)存儲(chǔ)在 cookie 里 （前面localstorage 也是一樣）
所以在 login接口成功后，token 就會(huì)以 auth._token.{provider} 的形式存儲(chǔ)

之后接口在請(qǐng)求時(shí)從cookie里拿token并作為接口憑證 發(fā)送給服務(wù)端。

目錄結(jié)構(gòu)

nuxt-dist 是每次npm run dev 或者 npm run build 后 webpack生成的文件，這里面的代碼可以看做是我們最后實(shí)際調(diào)用的代碼 (也可以直接在這里修改和debug，但每次重新跑項(xiàng)目就會(huì)還原)。

nuxt/auth 有幾個(gè)schemes 方案，比如看這個(gè) nuxt-dist/auth/schemes/local.js
這里有幾個(gè)默認(rèn)選項(xiàng)：

在我們寫(xiě)的代碼里，是用 $auth.loginWith 調(diào)用的方式，而實(shí)際上，loginWith最終還是調(diào)用的是 login

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

nuxt-dist 是每次npm run dev 或者 npm run build 后 webpack生成的文件，這里面的代碼可以看做是我們最后實(shí)際調(diào)用的代碼 (也可以直接在這里修改和debug，但每次重新跑項(xiàng)目就會(huì)還原)。
nuxt/auth 有幾個(gè)schemes 方案，比如看這個(gè) nuxt-dist/auth/schemes/local.js
這里有幾個(gè)默認(rèn)選項(xiàng)：

在我們寫(xiě)的代碼里，是用 $auth.loginWith 調(diào)用的方式，而實(shí)際上，loginWith最終還是調(diào)用的是 login

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

方法里的this.name， 就是auth.strategy, 也就是 local， local1 那些， 并且在上面 loginWith 方法里的 setStrategy() 將 auth.strategy 信息存到本地。
成功后，tokenRequired 默認(rèn)為true, 調(diào)用了 this.$auth.setToken, 這個(gè)方法在auth/schemes/auth.js 里

這個(gè)方法里的

在這個(gè)方法里，_key 被組裝成了._token.local
這個(gè)方法在 auth/storage.js 里

最終這個(gè)方法調(diào)用了 setCookie 和 serLocalStorage 方法， 把token存在coookie 和 localstorage里
而在setCookie里，再次組裝，加上了cookir.prefix ，默認(rèn)是auth

最終經(jīng)過(guò)序列化后，存儲(chǔ)在cookie里。
后續(xù)axios則直接在cookir里拿，并隨請(qǐng)求發(fā)送。

整個(gè)登錄和鑒權(quán)邏輯基本就是這樣。

繼續(xù)往代碼中走

nuxt.config.js 中還可以配置多個(gè) auth: {strategies: {local

微信登錄，手機(jī)號(hào)登錄，賬號(hào)登陸…

autoFetch

https://auth.nuxtjs.org/schemes/local
Fetch User
uth 模塊不保存有關(guān)用戶的信息，因此需要有一種方法來(lái)獲取用戶的信息，例如頁(yè)面重新加載。這就是用戶端點(diǎn)的用途。默認(rèn)情況下，這也會(huì)在成功登錄后調(diào)用。

如果user.autoFetch為 true （默認(rèn)），則endpoints.user在成功登錄后立即發(fā)送請(qǐng)求 。該端點(diǎn)應(yīng)使用特定用戶的 JSON 信息進(jìn)行響應(yīng)，該信息直接分配給user 屬性。

如果您希望直接從登錄會(huì)話返回用戶信息，請(qǐng)配置user.autoFetch為 false，從loginWith響應(yīng)中獲取用戶信息 ，并將其傳遞給setUser.

如果要完全禁用獲取用戶信息，請(qǐng)?jiān)O(shè)置endpoints.user: false. 這意味著永遠(yuǎn)不會(huì)調(diào)用用戶信息端點(diǎn)，但也意味著前端對(duì)用戶一無(wú)所知；this.$auth.user將{}。

ps: 由于需要對(duì)接口進(jìn)行替換，user會(huì)自動(dòng)去查詢，造成的報(bào)錯(cuò)不利于開(kāi)發(fā)，可以通過(guò)注釋，一步一步向下開(kāi)發(fā)。

user: {
          autoFetch: false,
      },

proxy配置

項(xiàng)目的后端接口基于后端低代碼平臺(tái)和java接口，接口開(kāi)頭的名稱不一致，可以通過(guò)proxy來(lái)處理，也可以解決跨域問(wèn)題。

	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 // 表示是否跨域
      }
    },

請(qǐng)求攔截

	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環(huán)境，部署至服務(wù)器不能這么用。
你定義一個(gè)文件，比如叫 apiPrefix.js
這個(gè)文件里，你枚舉出所有不同的接口和他們前綴的對(duì)應(yīng)關(guān)系

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

這樣等于說(shuō)顯式的把你所有的需要用到前綴的接口，都列舉出來(lái)了。
在axios的請(qǐng)求攔截里，根據(jù)當(dāng)前的請(qǐng)求url，去遍歷temp, 判斷出是屬于哪個(gè)前綴的，然后組裝上去。
對(duì)于那些在這個(gè)temp里無(wú)法找到歸屬的請(qǐng)求，那就是默認(rèn)不需要加前綴的，直接放過(guò)好了。

這樣的好處有三個(gè)，
一是你維護(hù)的時(shí)候，能一眼看出，你的哪些接口，是需要加什么樣前綴的
二是，你在頁(yè)面發(fā)起請(qǐng)求的時(shí)候，能保證同樣的調(diào)用方式，不需要在每個(gè)url上改動(dòng)。
三是如果后續(xù)批量前綴修改，你改的容易

如果生產(chǎn)環(huán)境需要調(diào)用其他服務(wù)器接口，那肯定也是要有一定規(guī)則的，有規(guī)則的話，我們匹配規(guī)則然后修改。
或者是一部分接口。那這樣的話，我們也可以用上述這種類似的方法，無(wú)非是變成了

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']
}

將前綴范圍，擴(kuò)展到包含協(xié)議和域名

動(dòng)態(tài)路由的配置

https://www.nuxtjs.cn/guide/routing
你會(huì)發(fā)現(xiàn)名稱為 users-id 的路由路徑帶有 :id? 參數(shù)，表示該路由是可選的。如果你想將它設(shè)置為必選的路由，需要在 users/_id 目錄內(nèi)創(chuàng)建一個(gè) index.vue 文件。

nuxt-dist會(huì)自動(dòng)打包生成配置

重定向及auth權(quán)限

https://auth.nuxtjs.org/guide/middleware
這里說(shuō)的是 auth的權(quán)限驗(yàn)證 可以放在全局 也可以放在每個(gè)路由里。也可以關(guān)閉，以便中間件跳過(guò)檢查。最后它還介紹了一種用法，guest 模式，就是說(shuō)訪問(wèn)這個(gè)路由不必非得登錄，但是如果是登錄用戶訪問(wèn)此頁(yè)面，則會(huì)被重定向到 redirect.home 所設(shè)置的路由

場(chǎng)景
有些場(chǎng)景需要登陸狀態(tài)下才能訪問(wèn)，不然就會(huì)被重定向到/login頁(yè)面，現(xiàn)在做了處理，就可以通過(guò)設(shè)置auth：false，來(lái)處理一些頁(yè)面，讓他不用重定向到login，如我現(xiàn)在所遇到的一個(gè)頁(yè)面，是通過(guò)后臺(tái)生成一個(gè)注冊(cè)鏈接，然后才能注冊(cè)的，這個(gè)頁(yè)面不需要token信息。

到此這篇關(guān)于vue-nuxt 登錄鑒權(quán)的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)vue-nuxt 登錄鑒權(quán)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論