vue-nuxt 登錄鑒權的實現
介紹
來自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 登錄鑒權內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！