目錄

• 介紹
• 連結
• 開始
• 繼續往程式碼中走
• proxy配置
• 請求攔截
• 處理不同字首的介面
• 動態路由的配置
• 重定向及auth許可權

介紹

來自mentor的梳理，做個總結和記錄

連結

https://auth.nuxt.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 資訊存到本地。

這個方法裡的

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

最終這個方法呼叫了 setCookie 和 serLocalStorage 方法， 把token存在coookie 和 localstorage裡
而在setCookie裡，再次組裝，加上了cookir.phttp://www.cppcns.comrefix ，預設是auth

最終經過序列化後，儲存在cookie裡。
後續axios則直接在cookir裡拿，並隨請求傳送。

整個登入和鑑權邏輯基本就是這樣。

繼續往程式碼中走

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

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

autoFetch

https://auth.nuxtjs.org/schemes/local
Fetch User
uth 模組不儲存有關使用者的資訊，因此需要有一種方法來獲取使用者的資訊，例如頁面重新載入。這就是使用者端點的用途。預設情況下，這也會在成功登入後呼叫。

如果user.autoFetch為 true （預設），則endpoints.usetCbMBnnJNwr在成功登入後立即傳送請求 。該端點應使用特定使用者的 JSON 資訊進行響應，該資訊直接分配給user 屬性。

如果您希望直接從登入會話返回使用者資訊，請配置user.autoFetch為 false，從loginWith響應中獲取使用者資訊 ，並將其傳遞給setUser.

如果要完全禁用獲取使用者資訊，請設定endpoints.user: false. 這意味著永遠不會呼叫使用者資訊端點，但也意味著前端對使用者一無所知；this.$auth.user將{}。

ps: 由於需要對介面進行替換，user會自動去查詢，造成的報錯不利於開發，可以通過註釋，一步一步向下開發。

user: {
          autoFetch: false,},

proxy配置

專案的後端介面基於後端低程式碼平臺和介面，介面開頭的名稱不一致，可以通過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',

請求攔截

	axios: {
    // // baseURL:''
    proxy: true,

處理不同字首的介面

dev 用於本地dev環境，部署至伺服器不能這麼用。
你定義一個檔案，比如叫 apiPrefix.js
這個檔案裡，你枚舉出所有不同的介面和他們字首的對應關係

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

這樣等於說顯式的把你所有的需要用到字首的介面，都列舉出來了。
在axios的請求攔截裡，根據當前的請求url，去遍歷temp,判斷出是屬於哪個字首的，然後組裝上去。
對於那些在這個temp裡無法找到歸屬的請求，那就是預設不需要加字首的，直接放過好了。

這樣的好處有三個，
一是你維護的時候，能一眼看出，你的哪些介面，是需要加什麼樣字首的
二是，你在頁面發起請求的時候，能保證同樣的呼叫方式，不需要在每個url上改動。
三是如果後續批量字首修改，你改的容易

如果生產環境需要呼叫其他伺服器介面，那肯定也是要有一定規則的，有規則的話，我們匹配規則然後修改。
或者是一部分介面。那這樣的話，我們也可以用上述這種類似的方法，無非是變成了

const temp = {
http://10.0.0.1/api: ['/front/login',http://10.0.0.1/api2: ['/testhttp://www.cppcns.com',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. 檔案。

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

重定向及auth許可權

https://auth.nuxtjs.org/guide/middleware
這裡說的是 auth的許可權驗證 可以放在全域性 也可以放在每個路由裡。也可以關閉，以便中介軟體跳過檢查。最後它還介紹了一種用法，guest 模式，就是說訪問這個路由不必非得登入，但是如果是登入使用者訪問此頁面，則會被重定向到 redirect.home 所設定的路由

場景
有些場景需要登陸狀態下才能訪問，不然就www.cppcns.com會被重定向到/login頁面，現在做了處理，就可以通過設定auth：false，來處理一些頁面，讓他不用重定向到login，如我現在所遇到的一個頁面，是通過後臺生成一個註冊連結，然後才能註冊的，這個頁面不需要token資訊。

到此這篇關於vue-nuxt 登入鑑權的實現的文章就介紹到這了,更多相關vue-nuxt 登入鑑權內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！