實戰(zhàn)：第一章：防止其他人通過用戶的url訪問用戶私人數(shù)據(jù)

解決思路：防止其他人通過用戶的url訪問用戶私人數(shù)據(jù)

思路一：url中放入userId，根據(jù)url中的usrId和session中保存的userId 進行匹配判斷是否是本人訪問，
這樣會將userId暴漏在url中，不安全。解決方案：url做成通用的，數(shù)據(jù)請求需要用戶自己主動觸發(fā)（百度的）（不建議使用）

思路二：訪問都需要登陸操作，session中放入userId， 記錄中放入userId，每次訪問的時候根據(jù)url中記錄id 得到數(shù)據(jù)，根據(jù)數(shù)據(jù)中的userId 和session中的userId 是否匹配判斷是否是用戶本人訪問？但是這樣就會導致需要查詢數(shù)據(jù)庫之后才可以得知結果，解決方案：redis替數(shù)據(jù)庫做用戶驗證。

思路三：用戶訪問訂單的請求地址時帶一個token，采用token，jwt加時間戳，放到每次請求的header中，拿到token進行校驗，判斷是否為該用戶自己的賬戶，如果是則進行請求，如果不是則提示，轉請求錯誤的頁面。（這個需要前端在用戶點擊發(fā)請求時將token帶上）

思路四：后臺系統(tǒng)層面做一個授權與鑒權。所以雖然URL一樣，但只有登陸授權過的用戶才能讓他看指定的數(shù)據(jù)。

思路五：在路由地方增加一個中間件，把需要驗證的路由全部走這個中間件。每次用戶登錄的時候生成一個比較長的hash碼（保證每個用戶不重復） session 保存這個 hash。每次請求的時候驗證這個 hash 就好了。每次登錄都不同，不純在泄漏問題。（和思路三類似，而且還多一個路由中間件）

思路六：拿瀏覽器的Cookie和緩存中用戶id的數(shù)據(jù)對比

實際解決方案：每個接口都有一個自定義的注解，注解里面設置第一次登錄保存用戶id，請求發(fā)到后臺接口直接從緩存中獲取用戶id，請求里其他參數(shù)可做對應表的關聯(lián)查詢獲取用戶id，拿二個用戶id做對比就行了。(有些接口參數(shù)列表有member_id也就是用戶登錄后的id,這種接口就直接獲取，沒有從緩存中拿)