更改介面卡選項為什麼為空
先提一下啥是有狀態登入
單一tomcat的情況下:編碼的流程如下
前端提交表單裡使用者的輸入的賬號密碼
後臺接受,查資料庫,
在資料庫中找到使用者的資訊後,把使用者的資訊存放到session裡面,返回給使用者cookie
以後使用者的請求都會自動攜帶著cookie去訪問後臺,後臺根據使用者的cookie辨識使用者的身份
但是有缺點
如果有千千萬的使用者都往session裡面存放資訊,
session很難跨伺服器,也就是說,使用者每次請求,都必須訪問同一臺tomcat,新的tomcat不認識使用者的cookie
無狀態登入
對於服務端,不再儲存任何使用者的資訊,對於他們來說,所有的使用者地位平等
對於使用者,他們需要自己攜帶著資訊去訪問服務端,攜帶的資訊可以被所有服務端辨認,所以,對於使用者,所有的服務地位平等
具體如何實現呢?
使用者登入,服務端返回給使用者的個人資訊+token令牌
前端為了自己使用方便,將使用者的個人資訊快取進瀏覽器(因為後端只是給了他一個token)
使用者攜帶自己的token去訪問服務端
認證透過,把使用者請求的資料返回給客戶端
以後不論使用者請求哪個微服務,都攜帶著token
微服務對token進行解密,判斷他是否有效
JWT(Json Web Token)生成規則#
整個登入。授權。鑑權的過程token的安全性至關重要,而JWT就是一門有關於如何生成一個不可仿造的token的規範
他是JSON風格輕量級的授權和身份認證規範,可實現無狀態、分散式的Web應用授權,而且它不是技術,和語言無關,java有對這個規範的實現 叫做
jjwt
—— 點選進入jjwt的github專案
由JWT演算法得到的token格式如上圖,
由頭部,載荷,簽名三部分組成
頭部
由兩部分組成,alg表示使用的加密演算法 typ表示使用的token的型別
載荷,存放使用者相關的資訊
Copy// 下面是它已經定義好的載荷部分key,也允許我們自定義載荷部分keyiss: jwt簽發者sub: jwt所面向的使用者aud: 接收jwt的一方exp: jwt的過期時間,這個過期時間必須要大於簽發時間nbf: 定義在什麼時間之前,該jwt都是不可用的。iat: jwt的簽發時間jti: jwt的唯一身份標識,主要用來作為一次性token,從而回避重放攻擊。
第三部分的簽名是由 頭+載荷+鹽 三部分加密組成
從圖可以看出,頭部和載荷被串改後,生成的編碼會發生改變,因此保證了token的安全 ,還有,載荷部分可解密,因此不要往裡面放入敏感的資訊(比如密碼 )
只要金鑰不洩露,別人就無法偽造任何資訊
jwt的互動過程
RSA非對稱加密算演算法
由美國麻 省理工 學院三 位學者 Riv est、Sh amir 及Adleman 研 究發 展出 一套 可是 際使用 的公 開金 秘密 碼系 統,那 就是
RSA(Rivest-Shamir-Adleman)密碼系統
jwt(是一種非對稱加密演算法) JWT不一定非要搭配RSA演算法,但是擁有RSA演算法公鑰私鑰的特性,會使我們的業務邏輯變得簡單,做到校驗變少
對稱加密,如AES(Advanced Encryption Standard) 高階加密標準
基本原理:將明文分成N個組,然後使用金鑰對各個組進行加密,形成各自的密文,最後把所有的分組密文進行合併,形成最終的密文。
優勢:演算法公開、計算量小、加密速度快、加密效率高
缺陷:雙方都使用同樣金鑰,安全性得不到保證
非對稱加密,如RSA
基本原理:同時生成兩把金鑰:私鑰和公鑰,私鑰隱秘儲存,公鑰可以下發給信任客戶端
私鑰加密,持有私鑰或公鑰才可以解密
公鑰加密,持有私鑰才可解密
優點:安全,難以破解
缺點:演算法比較耗時
不可逆加密,如MD5,SHA
使用JJWT實現JWT
JJWT(java json web token)
座標
Copy
建立jwt令牌
token最終會頒發給前端,這時候就得去和前端的哥們商量它想要什麼資訊
Copy// 生成令牌,主要是用它生成載荷JwtBuilder builder = Jwts。builder() // 設定頭部,使用hs256加密, + key,也就是鹽 。signWith(SignatureAlgorithm。HS256,“changwu”) // 新增載荷 。setId(“666”) // 使用者id 。setSubject(“張三”) // 使用者名稱 。setExpiration(new Date(new Date()。getTime()+60*1000)) // 過期時間 。setIssuedAt(new Date())// 登入時間 // 新增自定義的鍵值對 。claim(“role”,“admin”); System。out。println(builder。compact());
經過它處理的token長這個樣子, 三部組成
CopyXXX。YYY。ZZZ
解析token
能成功解析出結果的前提是兩次的鹽是一樣的才行
CopyClaims map = Jwts。parser()。setSigningKey(“changwu”) 。parseClaimsJws(“eyJhbGciOiJIUzI1NiJ9。eyJqdGkiOiI2NjYiLCJzdWIiOiLlvKDkuIkiLCJleHAiOjE1NjU2MTg1MjUsImlhdCI6MTU2NTYxODQ2NSwicm9sZSI6ImFkbWluIn0。GDVfLq-ehSnMCRoxVcziXkirjOg34SUUPBK5vAEHu80”) 。getBody();System。out。println(“使用者id” + map。getId());System。out。println(“使用者名稱” + map。getSubject());System。out。println(“token過期時間” + new SimpleDateFormat(“yyyy-MM-dd HH:mm:ss”)。format(map。getExpiration()));System。out。println(“使用者登入時間” + new SimpleDateFormat(“yyyy-MM-dd HH:mm:ss”)。format(map。getIssuedAt()));System。out。println(“使用者的角色是:”+map。get(“role”));
攔截器
注意哦,使用的是SpringMvc的攔截器,而不是Servlet的過濾器
攔截器的體系架構
在攔截器的體系中,我們常用的是上面的來兩個
HandlerInterceptor: 是頂級介面如下:
雖然是介面, 但是擁有jdk8的特性,是預設的方法,所以允許我們挑選它的部分方法實現而不會報錯
prehandler: 請求到達控制器之間被回撥,可以在這裡進行設定編碼,安全控制,許可權校驗, 一般全部返回ture,表示放行
postHandler: 控制器處理請求之後生成了ModelAndView,但是未進行渲染,提供了修改ModelAndView的機會
afterCompletion: 返回給使用者ModelAndView之後執行, 用於收尾工作
第二個是HandlerInterceptorAdapter如下圖
這個介面卡方法全是空實現,同樣可以滿足我們的需求,但是它同時實現了AsyncHandlerInterceptor,擁有了一個新的方法,afterConcrruentHandingStarted(request,response,handler)
這個方法會在Controller方法非同步執行時開始執行, 而Interceptor的postHandle方法則是需要等到Controller的非同步執行完才能執行
編碼實現
其實到這裡該如何做已經清晰明瞭
使用者登入,授權
授權得很簡單
使用者傳送登入請求提交form表單
後端根據使用者名稱密碼查詢使用者的資訊
把使用者的資訊封裝進jwt的載荷部分
返回給前端token
使用者再次請求,鑑權
後臺會有很多方法需要指定許可權的人才能訪問,
所謂鑑定許可權,其實就是把前端放在請求頭中的token資訊解析出來,如果解析成功了,說明使用者的合法的,否則就提示前端使用者沒有許可權
把token從請求頭中解析出來的過程,其實是在大量的重複性工作,所以我們放在攔截器中實現
使用攔截器兩步走
第一步,繼承HandlerInterAdapter,選擇重寫它的方法
設計的邏輯,這個方法肯定要返回true, 因為後臺的方法中肯定存在大量的不需要任何許可權就能訪問的方法
所以這個方法的作用就是,解析出請求頭中的使用者的許可權資訊,重新放回到request中,
這樣每個需要進行許可權驗證的請求,就不需要再進行解析請求頭,而是直接使用當前回撥方法的處理結果
Copy@Componentpublic class RequestInterceptor extends HandlerInterceptorAdapter {@AutowiredJwtUtil jwtUtil; // 在請求進入處理器之前回調這個方法@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 獲取請求頭String header = request。getHeader(“Authorization”);// 請求頭不為空進行解析if (StringUtils。isNotBlank(header)) { // 按照我們和前端約定的格式進行處理 if (header。startsWith(“Bearer ”)){ // 得到令牌 String token = header。substring(7); // 驗證令牌 try{ // 令牌的解析這裡一定的try起來,因為它解析錯誤的令牌時,會報錯 // 當然你也可以在自定義的jwtUtil中把異常 try起來,這裡就不用寫了 Claims claims = jwtUtil。parseJWT(token); String roles =(String) claims。get(“roles”); System。err。println(“roles==”+roles); if (roles!=null&&“admin”。equals(roles)){ request。setAttribute(“role_admin”,token); } if (roles!=null&&“user”。equals(roles)){ request。setAttribute(“role_user”,token); } }catch (Exception e){ throw new RuntimeException(“令牌不存在”); } }} return true;}}
這樣 控制器中的方法需要進行許可權驗證時,就免去了解析的麻煩,直接從request中獲取即可
第二步,將攔截器註冊進容器
Copy@Configurationpublic class InterceptorConfig extends WebMvcConfigurationSupport {@AutowiredRequestInterceptor requestInterceptor;// 註冊攔截器protected void addInterceptors(InterceptorRegistry registry) { registry。addInterceptor(requestInterceptor) 。addPathPatterns(“/**”) 。excludePathPatterns(“/user/login/**”);}}
作者: 賜我白日夢
出處:https://www。cnblogs。com/ZhuChangwu/p/11345098。html