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

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

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

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

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

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

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

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

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