介紹

來自mentor的梳理，做個總結(jié)和記錄

鏈接

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

開始

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

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

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

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

nuxt/auth 有幾個schemes 方案，比如看這個 nuxt-dist/auth/schemes/local.js
這里有幾個默認選項：

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

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

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

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

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

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

這個方法里的

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

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

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

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

繼續(xù)往代碼中走

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

微信登錄，手機號登錄，賬號登陸…

autoFetch

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

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

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

如果要完全禁用獲取用戶信息，請設(shè)置endpoints.user: false. 這意味著永遠不會調(diào)用用戶信息端點，但也意味著前端對用戶一無所知；this.$auth.user將{}。

ps: 由于需要對接口進行替換，user會自動去查詢，造成的報錯不利于開發(fā)，可以通過注釋，一步一步向下開發(fā)。

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

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

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

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

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

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

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

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

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

nuxt-dist會自動打包生成配置

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

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

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

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

最新評論