1 登錄功能

我們參照接口文檔來開發登錄功能

• 基本信息

  請求路徑：/login請求方式：POST接口描述：該接口用于員工登錄Tlias智能學習輔助系統，登錄完畢后，系統下發JWT令牌。 
  

• 請求參數

  參數格式：application/json

  參數說明：

  名稱	類型	是否必須	備注
  username	string	必須	用戶名
  password	string	必須	密碼

  請求數據樣例：

  {"username": "jinyong","password": "123456"
  }
  

• 響應數據

  參數格式：application/json

  參數說明：

  名稱	類型	是否必須	默認值	備注	其他信息
  code	number	必須		響應碼, 1 成功 ; 0 失敗
  msg	string	非必須		提示信息
  data	string	必須		返回的數據 , jwt令牌

  響應數據樣例：

  {"code": 1,"msg": "success","data": "eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoi6YeR5bq4IiwiaWQiOjEsInVzZXJuYW1lIjoiamlueW9uZyIsImV4cCI6MTY2MjIwNzA0OH0.KkUc_CXJZJ8Dd063eImx4H9Ojfrr6XMJ-yVzaWCVZCo"
  }
  

登錄服務端的核心邏輯就是：接收前端請求傳遞的用戶名和密碼 ，然后再根據用戶名和密碼查詢用戶信息，如果用戶信息存在，則說明用戶輸入的用戶名和密碼正確。如果查詢到的用戶不存在，則說明用戶輸入的用戶名和密碼錯誤。

功能開發

LoginController

@RestController
public class LoginController {@Autowiredprivate EmpService empService;@PostMapping("/login")public Result login(@RequestBody Emp emp){Emp e = empService.login(emp);return  e != null ? Result.success():Result.error("用戶名或密碼錯誤");}
}

EmpService

public interface EmpService {/*** 用戶登錄* @param emp* @return*/public Emp login(Emp emp);//省略其他代碼...
}

EmpServiceImpl

@Slf4j
@Service
public class EmpServiceImpl implements EmpService {@Autowiredprivate EmpMapper empMapper;@Overridepublic Emp login(Emp emp) {//調用dao層功能：登錄Emp loginEmp = empMapper.getByUsernameAndPassword(emp);//返回查詢結果給Controllerreturn loginEmp;}   //省略其他代碼...
}

EmpMapper

@Mapper
public interface EmpMapper {@Select("select id, username, password, name, gender, image, job, entrydate, dept_id, create_time, update_time " +"from emp " +"where username=#{username} and password =#{password}")public Emp getByUsernameAndPassword(Emp emp);//省略其他代碼...
}

2 登錄校驗

2.1 問題分析

什么是登錄校驗？

• 所謂登錄校驗，指的是我們在服務器端接收到瀏覽器發送過來的請求之后，首先我們要對請求進行校驗。先要校驗一下用戶登錄了沒有，如果用戶已經登錄了，就直接執行對應的業務操作就可以了；如果用戶沒有登錄，此時就不允許他執行相關的業務操作，直接給前端響應一個錯誤的結果，最終跳轉到登錄頁面，要求他登錄成功之后，再來訪問對應的數據。
  首先我們在宏觀上先有一個認知：

前面在講解HTTP協議的時候，我們提到HTTP協議是無狀態協議。什么又是無狀態的協議？

所謂無狀態，指的是每一次請求都是獨立的，下一次請求并不會攜帶上一次請求的數據。而瀏覽器與服務器之間進行交互，基于HTTP協議也就意味著現在我們通過瀏覽器來訪問了登陸這個接口，實現了登陸的操作，接下來我們在執行其他業務操作時，服務器也并不知道這個員工到底登陸了沒有。因為HTTP協議是無狀態的，兩次請求之間是獨立的，所以是無法判斷這個員工到底登陸了沒有。

那應該怎么來實現登錄校驗的操作呢？具體的實現思路可以分為兩部分：

1. 在員工登錄成功后，需要將用戶登錄成功的信息存起來，記錄用戶已經登錄成功的標記。
2. 在瀏覽器發起請求時，需要在服務端進行統一攔截，攔截后進行登錄校驗。

我們要完成以上操作，會涉及到web開發中的兩個技術：

1. 會話技術
2. 統一攔截技術

而統一攔截技術現實方案也有兩種：

1. Servlet規范中的Filter過濾器
2. Spring提供的interceptor攔截器

2.2 會話技術

在web開發當中，會話指的就是瀏覽器與服務器之間的一次連接，我們就稱為一次會話。

在用戶打開瀏覽器第一次訪問服務器的時候，這個會話就建立了，直到有任何一方斷開連接，此時會話就結束了。在一次會話當中，是可以包含多次請求和響應的。

比如：打開了瀏覽器來訪問web服務器上的資源（瀏覽器不能關閉、服務器不能斷開）

• 第1次：訪問的是登錄的接口，完成登錄操作
• 第2次：訪問的是部門管理接口，查詢所有部門數據
• 第3次：訪問的是員工管理接口，查詢員工數據

只要瀏覽器和服務器都沒有關閉，以上3次請求都屬于一次會話當中完成的。

需要注意的是：會話是和瀏覽器關聯的，當有三個瀏覽器客戶端和服務器建立了連接時，就會有三個會話。同一個瀏覽器在未關閉之前請求了多次服務器，這多次請求是屬于同一個會話。比如：1、2、3這三個請求都是屬于同一個會話。當我們關閉瀏覽器之后，這次會話就結束了。而如果我們是直接把web服務器關了，那么所有的會話就都結束了。

知道了會話的概念了，接下來我們再來了解下會話跟蹤。

會話跟蹤：一種維護瀏覽器狀態的方法，服務器需要識別多次請求是否來自于同一瀏覽器，以便在同一次會話的多次請求間共享數據。

服務器會接收很多的請求，但是服務器是需要識別出這些請求是不是同一個瀏覽器發出來的。比如：1和2這兩個請求是不是同一個瀏覽器發出來的，3和5這兩個請求不是同一個瀏覽器發出來的。如果是同一個瀏覽器發出來的，就說明是同一個會話。如果是不同的瀏覽器發出來的，就說明是不同的會話。而識別多次請求是否來自于同一瀏覽器的過程，我們就稱為會話跟蹤。

我們使用會話跟蹤技術就是要完成在同一個會話中，多個請求之間進行共享數據。

為什么要共享數據呢？

由于HTTP是無狀態協議，在后面請求中怎么拿到前一次請求生成的數據呢？此時就需要在一次會話的多次請求之間進行數據共享

會話跟蹤技術有兩種：

1. Cookie（客戶端會話跟蹤技術）
   • 數據存儲在客戶端瀏覽器當中
2. Session（服務端會話跟蹤技術）
   • 數據存儲在儲在服務端
3. 令牌技術

Cookie

cookie 是客戶端會話跟蹤技術，它是存儲在客戶端瀏覽器的，我們使用 cookie 來跟蹤會話，我們就可以在瀏覽器第一次發起請求來請求服務器的時候，我們在服務器端來設置一個cookie。

比如第一次請求了登錄接口，登錄接口執行完成之后，我們就可以設置一個cookie，在 cookie 當中我們就可以來存儲用戶相關的一些數據信息。比如我可以在 cookie 當中來存儲當前登錄用戶的用戶名，用戶的ID。

服務器端在給客戶端在響應數據的時候，會自動的將 cookie 響應給瀏覽器，瀏覽器接收到響應回來的 cookie 之后，會自動的將 cookie 的值存儲在瀏覽器本地。接下來在后續的每一次請求當中，都會將瀏覽器本地所存儲的 cookie 自動地攜帶到服務端。

接下來在服務端我們就可以獲取到 cookie 的值。我們可以去判斷一下這個 cookie 的值是否存在，如果不存在這個cookie，就說明客戶端之前是沒有訪問登錄接口的；如果存在 cookie 的值，就說明客戶端之前已經登錄完成了。這樣我們就可以基于 cookie 在同一次會話的不同請求之間來共享數據。

剛才在介紹流程的時候，用了 3 個自動：

• 服務器會 自動 的將 cookie 響應給瀏覽器。

• 瀏覽器接收到響應回來的數據之后，會 自動 的將 cookie 存儲在瀏覽器本地。

• 在后續的請求當中，瀏覽器會 自動 的將 cookie 攜帶到服務器端。

為什么這一切都是自動化進行的？

是因為 cookie 它是 HTP 協議當中所支持的技術，而各大瀏覽器廠商都支持了這一標準。在 HTTP 協議官方給我們提供了一個響應頭和請求頭：

• 響應頭 Set-Cookie ：設置Cookie數據的

• 請求頭 Cookie：攜帶Cookie數據的

優缺點

• 優點：HTTP協議中支持的技術（像Set-Cookie 響應頭的解析以及 Cookie 請求頭數據的攜帶，都是瀏覽器自動進行的，是無需我們手動操作的）
• 缺點：
  • 移動端APP(Android、IOS)中無法使用Cookie
  • 不安全，用戶可以自己禁用Cookie
  • Cookie不能跨域

Session

前面介紹的時候，我們提到Session，它是服務器端會話跟蹤技術，所以它是存儲在服務器端的。而 Session 的底層其實就是基于我們剛才所介紹的 Cookie 來實現的。

• 獲取Session
  • 如果我們現在要基于 Session 來進行會話跟蹤，瀏覽器在第一次請求服務器的時候，我們就可以直接在服務器當中來獲取到會話對象Session。如果是第一次請求Session ，會話對象是不存在的，這個時候服務器會自動的創建一個會話對象Session 。而每一個會話對象Session ，它都有一個ID（示意圖中Session后面括號中的1，就表示ID），我們稱之為 Session 的ID。

• 響應Cookie (JSESSIONID)
  • 服務器端在給瀏覽器響應數據的時候，它會將 Session 的 ID 通過 Cookie 響應給瀏覽器。其實在響應頭當中增加了一個 Set-Cookie 響應頭。這個 Set-Cookie 響應頭對應的值是不是cookie？ cookie 的名字是固定的 JSESSIONID 代表的服務器端會話對象 Session 的 ID。瀏覽器會自動識別這個響應頭，然后自動將Cookie存儲在瀏覽器本地。

• 查找Session
  • 在后續的每一次請求當中，都會將 Cookie 的數據獲取出來，并且攜帶到服務端。接下來服務器拿到JSESSIONID這個 Cookie 的值，也就是 Session 的ID。拿到 ID 之后，就會從眾多的 Session 當中來找到當前請求對應的會話對象Session。

優缺點

• 優點：Session是存儲在服務端的，安全
• 缺點：
  • 服務器集群環境下無法直接使用Session
  • 移動端APP(Android、IOS)中無法使用Cookie
  • 用戶可以自己禁用Cookie
  • Cookie不能跨域

PS：Session 底層是基于Cookie實現的會話跟蹤，如果Cookie不可用，則該方案，也就失效了。

首先第一點，我們現在所開發的項目，一般都不會只部署在一臺服務器上，因為一臺服務器會存在一個很大的問題，就是單點故障。所謂單點故障，指的就是一旦這臺服務器掛了，整個應用都沒法訪問了。

• 所以在現在的企業項目開發當中，最終部署的時候都是以集群的形式來進行部署，也就是同一個項目它會部署多份。比如這個項目我們現在就部署了 3 份。

• 而用戶在訪問的時候，到底訪問這三臺其中的哪一臺？其實用戶在訪問的時候，他會訪問一臺前置的服務器，我們叫負載均衡服務器，我們在后面項目當中會詳細講解。目前大家先有一個印象負載均衡服務器，它的作用就是將前端發起的請求均勻的分發給后面的這三臺服務器。

此時假如我們通過 session 來進行會話跟蹤，可能就會存在這樣一個問題。用戶打開瀏覽器要進行登錄操作，此時會發起登錄請求。登錄請求到達負載均衡服務器，將這個請求轉給了第一臺 Tomcat 服務器。

Tomcat 服務器接收到請求之后，要獲取到會話對象session。獲取到會話對象 session 之后，要給瀏覽器響應數據，最終在給瀏覽器響應數據的時候，就會攜帶這么一個 cookie 的名字，就是 JSESSIONID ，下一次再請求的時候，是不是又會將 Cookie 攜帶到服務端？

好。此時假如又執行了一次查詢操作，要查詢部門的數據。這次請求到達負載均衡服務器之后，負載均衡服務器將這次請求轉給了第二臺 Tomcat 服務器，此時他就要到第二臺 Tomcat 服務器當中。根據JSESSIONID 也就是對應的 session 的 ID 值，要找對應的 session 會話對象。

我想請問在第二臺服務器當中有沒有這個ID的會話對象 Session， 是沒有的。此時是不是就出現問題了？我同一個瀏覽器發起了 2 次請求，結果獲取到的不是同一個會話對象，這就是Session這種會話跟蹤方案它的缺點，在服務器集群環境下無法直接使用Session。

令牌技術

這里我們所提到的令牌，其實它就是一個用戶身份的標識，看似很高大上，很神秘，其實本質就是一個字符串。

如果通過令牌技術來跟蹤會話，我們就可以在瀏覽器發起請求。在請求登錄接口的時候，如果登錄成功，我就可以生成一個令牌，令牌就是用戶的合法身份憑證。接下來我在響應數據的時候，我就可以直接將令牌響應給前端。

接下來我們在前端程序當中接收到令牌之后，就需要將這個令牌存儲起來。這個存儲可以存儲在 cookie 當中，也可以存儲在其他的存儲空間(比如：localStorage)當中。

接下來，在后續的每一次請求當中，都需要將令牌攜帶到服務端。攜帶到服務端之后，接下來我們就需要來校驗令牌的有效性。如果令牌是有效的，就說明用戶已經執行了登錄操作，如果令牌是無效的，就說明用戶之前并未執行登錄操作。

此時，如果是在同一次會話的多次請求之間，我們想共享數據，我們就可以將共享的數據存儲在令牌當中就可以了。

優缺點

• 優點：
  • 支持PC端、移動端
  • 解決集群環境下的認證問題
  • 減輕服務器的存儲壓力（無需在服務器端存儲）
• 缺點：需要自己實現（包括令牌的生成、令牌的傳遞、令牌的校驗）

2.3 JWT令牌

介紹

JWT全稱：JSON Web Token （官網：https://jwt.io/）

定義了一種簡潔的、自包含的格式，用于在通信雙方以json數據格式安全的傳輸信息。由于數字簽名的存在，這些信息是可靠的。

JWT的組成： （JWT令牌由三個部分組成，三個部分之間使用英文的點來分割）

• 第一部分：Header(頭）， 記錄令牌類型、簽名算法等。 例如：{“alg”:“HS256”,“type”:“JWT”}

• 第二部分：Payload(有效載荷），攜帶一些自定義信息、默認信息等。 例如：{“id”:“1”,“username”:“Tom”}

• 第三部分：Signature(簽名），防止Token被篡改、確保安全性。將header、payload，并加入指定秘鑰，通過指定簽名算法計算而來。

JWT是如何將原始的JSON格式數據，轉變為字符串的呢？

其實在生成JWT令牌時，會對JSON格式的數據進行一次編碼：進行base64編碼

Base64：是一種基于64個可打印的字符來表示二進制數據的編碼方式。既然能編碼，那也就意味著也能解碼。所使用的64個字符分別是A到Z、a到z、 0- 9，一個加號，一個斜杠，加起來就是64個字符。任何數據經過base64編碼之后，最終就會通過這64個字符來表示。當然還有一個符號，那就是等號。等號它是一個補位的符號

需要注意的是Base64是編碼方式，而不是加密方式。

JWT令牌最典型的應用場景就是登錄認證：

1. 在瀏覽器發起請求來執行登錄操作，此時會訪問登錄的接口，如果登錄成功之后，我們需要生成一個jwt令牌，將生成的 jwt令牌返回給前端。
2. 前端拿到jwt令牌之后，會將jwt令牌存儲起來。在后續的每一次請求中都會將jwt令牌攜帶到服務端。
3. 服務端統一攔截請求之后，先來判斷一下這次請求有沒有把令牌帶過來，如果沒有帶過來，直接拒絕訪問，如果帶過來了，還要校驗一下令牌是否是有效。如果有效，就直接放行進行請求的處理。

在JWT登錄認證的場景中我們發現，整個流程當中涉及到兩步操作：

1. 在登錄成功之后，要生成令牌。
2. 每一次請求當中，要接收令牌并對令牌進行校驗。

稍后我們再來學習如何來生成jwt令牌，以及如何來校驗jwt令牌。

生成和校驗

需要先引入JWT的依賴：

<!-- JWT依賴-->
<dependency><groupId>io.jsonwebtoken</groupId><artifactId>jjwt</artifactId><version>0.9.1</version>
</dependency>

在引入完JWT來賴后，就可以調用工具包中提供的API來完成JWT令牌的生成和校驗

工具類：Jwts
生成JWT代碼實現：

@Test
public void genJwt(){Map<String,Object> claims = new HashMap<>();claims.put("id",1);claims.put("username","Tom");String jwt = Jwts.builder().setClaims(claims) //自定義內容(載荷)          .signWith(SignatureAlgorithm.HS256, "itheima") //簽名算法        .setExpiration(new Date(System.currentTimeMillis() + 24*3600*1000)) //有效期 24小時   .compact();System.out.println(jwt);
}

生成了字符串eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoi6YeR5bq4IiwiaWQiOjEsInVzZXJuYW1lIjoiamlueW9uZyIsImV4cCI6MTcxNTY2MTEzOH0.qMKWXGdb0LJPeVj1TYy7FkArM-rOD3t3yhW8zKuGsXo

實現了JWT令牌的生成，下面我們接著使用Java代碼來校驗JWT令牌(解析生成的令牌)：

@Test
public void parseJwt(){Claims claims = Jwts.parser().setSigningKey("itheima")//指定簽名密鑰（必須保證和生成令牌時使用相同的簽名密鑰）  .parseClaimsJws("eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjcyNzI5NzMwfQ.fHi0Ub8npbyt71UqLXDdLyipptLgxBUg_mSuGJtXtBk").getBody();System.out.println(claims);
}

登錄下發令牌

JWT令牌的生成和校驗的基本操作我們已經學習完了，接下來我們就需要在案例當中通過JWT令牌技術來跟蹤會話。具體的思路我們前面已經分析過了，主要就是兩步操作：

1. 生成令牌
   • 在登錄成功之后來生成一個JWT令牌，并且把這個令牌直接返回給前端
2. 校驗令牌
   • 攔截前端請求，從請求中獲取到令牌，對令牌進行解析校驗

那我們首先來完成：登錄成功之后生成JWT令牌，并且把令牌返回給前端。

實現步驟：

1. 引入JWT工具類
   • 在項目工程下創建com.itheima.utils包，并把提供JWT工具類復制到該包下
2. 登錄完成后，調用工具類生成JWT令牌并返回

JWT工具類

public class JwtUtils {private static String signKey = "itheima";//簽名密鑰private static Long expire = 43200000L; //有效時間/*** 生成JWT令牌* @param claims JWT第二部分負載 payload 中存儲的內容* @return*/public static String generateJwt(Map<String, Object> claims){String jwt = Jwts.builder().addClaims(claims)//自定義信息（有效載荷）.signWith(SignatureAlgorithm.HS256, signKey)//簽名算法（頭部）.setExpiration(new Date(System.currentTimeMillis() + expire))//過期時間.compact();return jwt;}/*** 解析JWT令牌* @param jwt JWT令牌* @return JWT第二部分負載 payload 中存儲的內容*/public static Claims parseJWT(String jwt){Claims claims = Jwts.parser().setSigningKey(signKey)//指定簽名密鑰.parseClaimsJws(jwt)//指定令牌Token.getBody();return claims;}
}

登錄成功，生成JWT令牌并返回

@RestController
@Slf4j
public class LoginController {//依賴業務層對象@Autowiredprivate EmpService empService;@PostMapping("/login")public Result login(@RequestBody Emp emp) {//調用業務層：登錄功能Emp loginEmp = empService.login(emp);//判斷：登錄用戶是否存在if(loginEmp !=null ){//自定義信息Map<String , Object> claims = new HashMap<>();claims.put("id", loginEmp.getId());claims.put("username",loginEmp.getUsername());claims.put("name",loginEmp.getName());//使用JWT工具類，生成身份令牌String token = JwtUtils.generateJwt(claims);return Result.success(token);}return Result.error("用戶名或密碼錯誤");}
}

重啟服務，打開postman測試登錄接口：

2.4 過濾器Filter

剛才通過瀏覽器的開發者工具，我們可以看到在后續的請求當中，都會在請求頭中攜帶JWT令牌到服務端，而服務端需要統一攔截所有的請求，從而判斷是否攜帶的有合法的JWT令牌。
那怎么樣來統一攔截到所有的請求校驗令牌的有效性呢？這里我們會學習兩種解決方案：

1. Filter過濾器
2. Interceptor攔截器

我們首先來學習過濾器Filter。
什么是Filter？

• Filter表示過濾器，是 JavaWeb三大組件(Servlet、Filter、Listener)之一。

• 過濾器可以把對資源的請求攔截下來，從而實現一些特殊的功能

  • 使用了過濾器之后，要想訪問web服務器上的資源，必須先經過濾器，過濾器處理完畢之后，才可以訪問對應的資源。

• 過濾器一般完成一些通用的操作，比如：登錄校驗、統一編碼處理、敏感字符處理等。
  
  下面我們通過Filter快速入門程序掌握過濾器的基本使用操作：

• 第1步，定義過濾器 ：1.定義一個類，實現 Filter 接口，并重寫其所有方法。

• 第2步，配置過濾器：Filter類上加 @WebFilter 注解，配置攔截資源的路徑。引導類上加 @ServletComponentScan 開啟Servlet組件支持。

在定義完Filter之后，Filter其實并不會生效，還需要完成Filter的配置，Filter的配置非常簡單，只需要在Filter類上添加一個注解：@WebFilter，并指定屬性urlPatterns，通過這個屬性指定過濾器要攔截哪些請求

當我們在Filter類上面加了@WebFilter注解之后，接下來我們還需要在啟動類上面加上一個注解@ServletComponentScan，通過這個@ServletComponentScan注解來開啟SpringBoot項目對于Servlet組件的支持。

@ServletComponentScan
@SpringBootApplication
public class TliasWebManagementApplication {public static void main(String[] args) {SpringApplication.run(TliasWebManagementApplication.class, args);}}

@WebFilter(urlPatterns = "/*") //配置過濾器要攔截的請求路徑（ /* 表示攔截瀏覽器的所有請求 ）
public class DemoFilter implements Filter {@Override    // init方法在Filter被加載時調用，只會被執行一次public void init(FilterConfig filterConfig) throws ServletException {System.out.println("init 初始化方法執行了");}@Override       // doFilter方法在每次請求時被調用，可以對請求進行處理public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {System.out.println("Demo 攔截到了請求...放行前邏輯");// 調用FilterChain的doFilter方法，讓請求繼續向下執行filterChain.doFilter(servletRequest, servletResponse);System.out.println("DemoFilter   放行后邏輯.....");}@Override     // destroy方法在Filter被卸載時調用，只會被執行一次public void destroy() {System.out.println("destroy 銷毀方法執行了");}
}

• init方法：過濾器的初始化方法。在web服務器啟動的時候會自動的創建Filter過濾器對象，在創建過濾器對象的時候會自動調用init初始化方法，這個方法只會被調用一次。

• doFilter方法：這個方法是在每一次攔截到請求之后都會被調用，所以這個方法是會被調用多次的，每攔截到一次請求就會調用一次doFilter()方法。

• destroy方法： 是銷毀的方法。當我們關閉服務器的時候，它會自動的調用銷毀方法destroy，而這個銷毀方法也只會被調用一次。

注意事項：

? 在過濾器Filter中，如果不執行放行操作，將無法訪問后面的資源。 放行操作：chain.doFilter(request, response);

攔截路徑

執行流程我們搞清楚之后，接下來再來介紹一下過濾器的攔截路徑，Filter可以根據需求，配置不同的攔截資源路徑：

攔截路徑	urlPatterns值	含義
攔截具體路徑	/login	只有訪問 /login 路徑時，才會被攔截
目錄攔截	/emps/*	訪問/emps下的所有資源，都會被攔截
攔截所有	/*	訪問所有資源，都會被攔截

過濾器鏈

最后我們在來介紹下過濾器鏈，什么是過濾器鏈呢？所謂過濾器鏈指的是在一個web應用程序當中，可以配置多個過濾器，多個過濾器就形成了一個過濾器鏈。

比如：在我們web服務器當中，定義了兩個過濾器，這兩個過濾器就形成了一個過濾器鏈。

而這個鏈上的過濾器在執行的時候會一個一個的執行，會先執行第一個Filter，放行之后再來執行第二個Filter，如果執行到了最后一個過濾器放行之后，才會訪問對應的web資源。

訪問完web資源之后，按照我們剛才所介紹的過濾器的執行流程，還會回到過濾器當中來執行過濾器放行后的邏輯，而在執行放行后的邏輯的時候，順序是反著的。

先要執行過濾器2放行之后的邏輯，再來執行過濾器1放行之后的邏輯，最后在給瀏覽器響應數據。

以上就是當我們在web應用當中配置了多個過濾器，形成了這樣一個過濾器鏈以及過濾器鏈的執行順序。下面我們通過idea來驗證下過濾器鏈。

驗證步驟：

1. 在filter包下再來新建一個Filter過濾器類：AbcFilter
2. 在AbcFilter過濾器中編寫放行前和放行后邏輯
3. 配置AbcFilter過濾器攔截請求路徑為：/*
4. 重啟SpringBoot服務，查看DemoFilter、AbcFilter的執行日志

通過控制臺日志的輸出，大家發現AbcFilter先執行DemoFilter后執行，這是為什么呢？

其實是和過濾器的類名有關系。以注解方式配置的Filter過濾器，它的執行優先級是按時過濾器類名的自動排序確定的，類名排名越靠前，優先級越高。

假如我們想讓DemoFilter先執行，怎么辦呢？答案就是修改類名。

測試：修改AbcFilter類名為XbcFilter，運行程序查看控制臺日志

登錄校驗-Filter

分析

過濾器Filter的快速入門以及使用細節我們已經介紹完了，接下來最后一步，我們需要使用過濾器Filter來完成案例當中的登錄校驗功能。

我們先來回顧下前面分析過的登錄校驗的基本流程：

• 要進入到后臺管理系統，我們必須先完成登錄操作，此時就需要訪問登錄接口login。

• 登錄成功之后，我們會在服務端生成一個JWT令牌，并且把JWT令牌返回給前端，前端會將JWT令牌存儲下來。

• 在后續的每一次請求當中，都會將JWT令牌攜帶到服務端，請求到達服務端之后，要想去訪問對應的業務功能，此時我們必須先要校驗令牌的有效性。

• 對于校驗令牌的這一塊操作，我們使用登錄校驗的過濾器，在過濾器當中來校驗令牌的有效性。如果令牌是無效的，就響應一個錯誤的信息，也不會再去放行訪問對應的資源了。如果令牌存在，并且它是有效的，此時就會放行去訪問對應的web資源，執行相應的業務操作。

大概清楚了在Filter過濾器的實現步驟了，那在正式開發登錄校驗過濾器之前，我們思考兩個問題：

1. 所有的請求，攔截到了之后，都需要校驗令牌嗎？

   • 答案：登錄請求例外

2. 攔截到請求后，什么情況下才可以放行，執行業務操作？

   • 答案：有令牌，且令牌校驗通過(合法)；否則都返回未登錄錯誤結果

我們分析出具體的操作步驟：

1. 獲取請求url
2. 判斷請求url中是否包含login，如果包含，說明是登錄操作，放行
3. 獲取請求頭中的令牌（token）
4. 判斷令牌是否存在，如果不存在，返回錯誤結果（未登錄）
5. 解析token，如果解析失敗，返回錯誤結果（未登錄）
6. 放行

登錄校驗過濾器：LoginCheckFilter

package com.itheima.filter;import com.alibaba.fastjson.JSONObject;
import com.itheima.pojo.Result;
import com.itheima.utils.JwtUtils;
import jakarta.servlet.*;
import jakarta.servlet.annotation.WebFilter;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.util.StringUtils;import java.io.IOException;@Slf4j
@WebFilter(urlPatterns = "/*")  //攔截所有請求
public class LoginCheckFilter implements Filter {@Overridepublic void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {HttpServletRequest req = (HttpServletRequest) servletRequest;HttpServletResponse resp = (HttpServletResponse) servletResponse;//1.獲取請求url。String url = req.getRequestURL().toString();log.info("請求的url: {}",url);//2.判斷請求url中是否包含login，如果包含，說明是登錄操作，放行。if(url.contains("login")){log.info("登錄操作, 放行...");filterChain.doFilter(req, resp);return;}//3.獲取請求頭中的令牌（token）。String jwt = req.getHeader("token");//4.判斷令牌是否存在，如果不存在，返回錯誤結果（未登錄）。if(!StringUtils.hasLength(jwt)){log.info("請求頭token為空,返回未登錄的信息");Result error = Result.error("NOT_LOGIN");//手動轉換 對象-->json -------- 阿里巴巴fastJSON  依賴String notLogin = JSONObject.toJSONString(error);resp.getWriter().write(notLogin);return;}//5.解析token，如果解析失敗，返回錯誤結果（未登錄）。try {JwtUtils.parseJWT(jwt);  //解析token  try catch快捷鍵ctrl + alt + t} catch (Exception e) {//jwt解析失敗e.printStackTrace();log.info("解析令牌失敗, 返回未登錄錯誤信息");Result error = Result.error("NOT_LOGIN");//手動轉換 對象-->json --------> 阿里巴巴fastJSON  依賴String notLogin = JSONObject.toJSONString(error);resp.getWriter().write(notLogin);return;}//6.放行。log.info("令牌合法, 放行");filterChain.doFilter(req, resp);}}

在上述過濾器的功能實現中，我們使用到了一個第三方json處理的工具包fastjson。我們要想使用，需要引入如下依賴：

<dependency><groupId>com.alibaba</groupId><artifactId>fastjson</artifactId><version>1.2.76</version>
</dependency>

登錄校驗的過濾器我們編寫完成了，接下來我們就可以重新啟動服務來做一個測試：

測試前先把之前所編寫的測試使用的過濾器，暫時注釋掉。直接將@WebFilter注解給注釋掉即可。

• 測試1：未登錄是否可以訪問部門管理頁面

  首先，進入開發者工具，Application清空Cookie， 關閉瀏覽器，重新打開瀏覽器，在地址欄中輸入：http://localhost:90/#/system/dept

  由于用戶沒有登錄，登錄校驗過濾器返回錯誤信息，前端頁面根據返回的錯誤信息結果，自動跳轉到登錄頁面了

2.5 攔截器Interceptor

學習完了過濾器Filter之后，接下來我們繼續學習攔截器Interseptor。

攔截器我們主要分為三個方面進行講解：

1. 介紹下什么是攔截器，并通過快速入門程序上手攔截器
2. 攔截器的使用細節
3. 通過攔截器Interceptor完成登錄校驗功能

我們先學習第一塊內容：攔截器快速入門

什么是攔截器？

• 是一種動態攔截方法調用的機制，類似于過濾器。
• 攔截器是Spring框架中提供的，用來動態攔截控制器方法的執行。

攔截器的作用：

• 攔截請求，在指定方法調用前后，根據業務需要執行預先設定的代碼。

在攔截器當中，我們通常也是做一些通用性的操作，比如：我們可以通過攔截器來攔截前端發起的請求，將登錄校驗的邏輯全部編寫在攔截器當中。在校驗的過程當中，如發現用戶登錄了(攜帶JWT令牌且是合法令牌)，就可以直接放行，去訪問spring當中的資源。如果校驗時發現并沒有登錄或是非法令牌，就可以直接給前端響應未登錄的錯誤信息。

下面我們通過快速入門程序，來學習下攔截器的基本使用。攔截器的使用步驟和過濾器類似，也分為兩步：

1. 定義攔截器

2. 注冊配置攔截器

自定義攔截器：

在com.itheima.interceptor下，實現HandlerInterceptor接口，并重寫其所有方法

• preHandle方法：目標資源方法執行前執行。 返回true：放行 返回false：不放行

• postHandle方法：目標資源方法執行后執行

• afterCompletion方法：視圖渲染完畢后執行，最后執行

package com.itheima.interceptor;import com.alibaba.fastjson.JSONObject;
import com.itheima.pojo.Result;
import com.itheima.utils.JwtUtils;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;
import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;@Slf4j
@Component // 該注解用于將該類交由Spring管理，并自動實例化
public class LoginCheckInterceptor implements HandlerInterceptor {//快捷鍵：Ctrl + O 跳轉到方法@Override  // 該方法在請求處理之前執行，返回true表示繼續執行后續的攔截器，返回false表示中斷執行，不再執行后續的攔截器public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception {System.out.println("LoginCheckInterceptor preHandle");//1.獲取請求url。String url = req.getRequestURL().toString();log.info("請求的url: {}",url);//2.判斷請求url中是否包含login，如果包含，說明是登錄操作，放行。if(url.contains("login")){log.info("登錄操作, 放行...");return true;}//3.獲取請求頭中的令牌（token）。String jwt = req.getHeader("token");//4.判斷令牌是否存在，如果不存在，返回錯誤結果（未登錄）。if(!StringUtils.hasLength(jwt)){log.info("請求頭token為空,返回未登錄的信息");Result error = Result.error("NOT_LOGIN");//手動轉換 對象-->json -------- 阿里巴巴fastJSON  依賴String notLogin = JSONObject.toJSONString(error);resp.getWriter().write(notLogin);return false;}//5.解析token，如果解析失敗，返回錯誤結果（未登錄）。try {JwtUtils.parseJWT(jwt);  //解析token  try catch快捷鍵ctrl + alt + t} catch (Exception e) {//jwt解析失敗e.printStackTrace();log.info("解析令牌失敗, 返回未登錄錯誤信息");Result error = Result.error("NOT_LOGIN");//手動轉換 對象-->json --------> 阿里巴巴fastJSON  依賴String notLogin = JSONObject.toJSONString(error);resp.getWriter().write(notLogin);return false;}//6.放行。log.info("令牌合法, 放行");return true;}@Override    // 該方法在請求處理之后執行，但是在視圖渲染之前，可以對ModelAndView進行操作public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {System.out.println("LoginCheckInterceptor postHandle");HandlerInterceptor.super.postHandle(request, response, handler, modelAndView);}@Override  // 該方法在整個請求結束之后，也就是在視圖渲染完成之后執行，可以用于清理資源等public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {System.out.println("LoginCheckInterceptor afterCompletion");HandlerInterceptor.super.afterCompletion(request, response, handler, ex);}
}

Interceptor詳解

攔截器的入門程序完成之后，接下來我們來介紹攔截器的使用細節。攔截器的使用細節我們主要介紹兩個部分：

1. 攔截器的攔截路徑配置
2. 攔截器的執行流程

首先我們先來看攔截器的攔截路徑的配置，在注冊配置攔截器的時候，我們要指定攔截器的攔截路徑，通過addPathPatterns("要攔截路徑")方法，就可以指定要攔截哪些資源。

在入門程序中我們配置的是/**，表示攔截所有資源，而在配置攔截器時，不僅可以指定要攔截哪些資源，還可以指定不攔截哪些資源，只需要調用excludePathPatterns("不攔截路徑")方法，指定哪些資源不需要攔截。

在攔截器中除了可以設置/**攔截所有資源外，還有一些常見攔截路徑設置：

攔截路徑	含義	舉例
/*	一級路徑	能匹配/depts，/emps，/login，不能匹配 /depts/1
/**	任意級路徑	能匹配/depts，/depts/1，/depts/1/2
/depts/*	/depts下的一級路徑	能匹配/depts/1，不能匹配/depts/1/2，/depts
/depts/**	/depts下的任意級路徑	能匹配/depts，/depts/1，/depts/1/2，不能匹配/emps/1

下面主要來演示下/**與/*的區別：

• 修改攔截器配置，把攔截路徑設置為/*

package com.itheima.config;import com.itheima.interceptor.LoginCheckInterceptor;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;@Configuration // 1. 導入配置類
public class WebConfig implements WebMvcConfigurer {// 1. 自動注入 LoginInterceptor@Autowiredprivate LoginCheckInterceptor loginCheckInterceptor;// 2. 注冊攔截器@Overridepublic void addInterceptors(InterceptorRegistry registry) {registry.addInterceptor(loginCheckInterceptor).addPathPatterns("/**").excludePathPatterns("/login");  // 注冊攔截器，攔截所有請求}
}
控制臺沒有輸出攔截器中的日志信息，說明`/*`沒有匹配到攔截路徑`/emp/1` 。

執行流程

介紹完攔截路徑的配置之后，接下來我們再來介紹攔截器的執行流程。通過執行流程，大家就能夠清晰的知道過濾器與攔截器的執行時機。

• 當我們打開瀏覽器來訪問部署在web服務器當中的web應用時，此時我們所定義的過濾器會攔截到這次請求。攔截到這次請求之后，它會先執行放行前的邏輯，然后再執行放行操作。而由于我們當前是基于springboot開發的，所以放行之后是進入到了spring的環境當中，也就是要來訪問我們所定義的controller當中的接口方法。

• Tomcat并不識別所編寫的Controller程序，但是它識別Servlet程序，所以在Spring的Web環境中提供了一個非常核心的Servlet：DispatcherServlet（前端控制器），所有請求都會先進行到DispatcherServlet，再將請求轉給Controller。

• 當我們定義了攔截器后，會在執行Controller的方法之前，請求被攔截器攔截住。執行preHandle()方法，這個方法執行完成后需要返回一個布爾類型的值，如果返回true，就表示放行本次操作，才會繼續訪問controller中的方法；如果返回false，則不會放行（controller中的方法也不會執行）。

• 在controller當中的方法執行完畢之后，再回過來執行postHandle()這個方法以及afterCompletion() 方法，然后再返回給DispatcherServlet，最終再來執行過濾器當中放行后的這一部分邏輯的邏輯。執行完畢之后，最終給瀏覽器響應數據。

• 開啟LoginCheckInterceptor攔截器

@Component
public class LoginCheckInterceptor implements HandlerInterceptor {@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {System.out.println("preHandle .... ");return true; //true表示放行}@Overridepublic void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {System.out.println("postHandle ... ");}@Overridepublic void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {System.out.println("afterCompletion .... ");}
}

@Configuration  
public class WebConfig implements WebMvcConfigurer {//攔截器對象@Autowiredprivate LoginCheckInterceptor loginCheckInterceptor;@Overridepublic void addInterceptors(InterceptorRegistry registry) {//注冊自定義攔截器對象registry.addInterceptor(loginCheckInterceptor).addPathPatterns("/**")//攔截所有請求.excludePathPatterns("/login");//不攔截登錄請求}
}

• 開啟DemoFilter過濾器

@WebFilter(urlPatterns = "/*") 
public class DemoFilter implements Filter {@Overridepublic void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {System.out.println("DemoFilter   放行前邏輯.....");//放行請求filterChain.doFilter(servletRequest,servletResponse);System.out.println("DemoFilter   放行后邏輯.....");}
}

以上就是攔截器的執行流程。通過執行流程分析，大家應該已經清楚了過濾器和攔截器之間的區別，其實它們之間的區別主要是兩點：

• 接口規范不同：過濾器需要實現Filter接口，而攔截器需要實現HandlerInterceptor接口。
• 攔截范圍不同：過濾器Filter會攔截所有的資源，而Interceptor只會攔截Spring環境中的資源。

登錄校驗- Interceptor

講解完了攔截器的基本操作之后，接下來我們需要完成最后一步操作：通過攔截器來完成案例當中的登錄校驗功能。

登錄校驗的業務邏輯以及操作步驟我們前面已經分析過了，和登錄校驗Filter過濾器當中的邏輯是完全一致的。現在我們只需要把這個技術方案由原來的過濾器換成攔截器interceptor就可以了。

登錄校驗攔截器

package com.itheima.interceptor;import com.alibaba.fastjson.JSONObject;
import com.itheima.pojo.Result;
import com.itheima.utils.JwtUtils;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;
import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;@Slf4j
@Component // 該注解用于將該類交由Spring管理，并自動實例化
public class LoginCheckInterceptor implements HandlerInterceptor {//快捷鍵：Ctrl + O 跳轉到方法@Override  // 該方法在請求處理之前執行，返回true表示繼續執行后續的攔截器，返回false表示中斷執行，不再執行后續的攔截器public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception {System.out.println("LoginCheckInterceptor preHandle...");//1.獲取請求url。String url = req.getRequestURL().toString();log.info("請求的url: {}",url);//2.判斷請求url中是否包含login，如果包含，說明是登錄操作，放行。if(url.contains("login")){log.info("登錄操作, 放行...");return true;}//3.獲取請求頭中的令牌（token）。String jwt = req.getHeader("token");//4.判斷令牌是否存在，如果不存在，返回錯誤結果（未登錄）。if(!StringUtils.hasLength(jwt)){log.info("請求頭token為空,返回未登錄的信息");Result error = Result.error("NOT_LOGIN");//手動轉換 對象-->json -------- 阿里巴巴fastJSON  依賴String notLogin = JSONObject.toJSONString(error);resp.getWriter().write(notLogin);return false;}//5.解析token，如果解析失敗，返回錯誤結果（未登錄）。try {JwtUtils.parseJWT(jwt);  //解析token  try catch快捷鍵ctrl + alt + t} catch (Exception e) {//jwt解析失敗e.printStackTrace();log.info("解析令牌失敗, 返回未登錄錯誤信息");Result error = Result.error("NOT_LOGIN");//手動轉換 對象-->json --------> 阿里巴巴fastJSON  依賴String notLogin = JSONObject.toJSONString(error);resp.getWriter().write(notLogin);return false;}//6.放行。log.info("令牌合法, 放行");return true;}@Override    // 該方法在請求處理之后執行，但是在視圖渲染之前，可以對ModelAndView進行操作public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {System.out.println("LoginCheckInterceptor postHandle...");HandlerInterceptor.super.postHandle(request, response, handler, modelAndView);}@Override  // 該方法在整個請求結束之后，也就是在視圖渲染完成之后執行，可以用于清理資源等public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {System.out.println("LoginCheckInterceptor afterCompletion...");HandlerInterceptor.super.afterCompletion(request, response, handler, ex);}
}

注冊配置攔截器

@Configuration  
public class WebConfig implements WebMvcConfigurer {//攔截器對象@Autowiredprivate LoginCheckInterceptor loginCheckInterceptor;@Overridepublic void addInterceptors(InterceptorRegistry registry) {//注冊自定義攔截器對象registry.addInterceptor(loginCheckInterceptor).addPathPatterns("/**").excludePathPatterns("/login");}
}

登錄校驗的攔截器編寫完成后，接下來我們就可以重新啟動服務來做一個測試： （關閉登錄校驗Filter過濾器）

• 測試1：未登錄是否可以訪問部門管理頁面

  首先關閉瀏覽器，重新打開瀏覽器，在地址欄中輸入：http://localhost:90/#/system/dept

  由于用戶沒有登錄，校驗機制返回錯誤信息，前端頁面根據返回的錯誤信息結果，自動跳轉到登錄頁面了

我更換使用了火狐瀏覽器，這樣不用考慮是否原瀏覽器Cookie沒清空。

3 異常處理

3.1 當前問題

3.1 當前問題

登錄功能和登錄校驗功能我們都實現了，下面我們學習下今天最后一塊技術點：異常處理。首先我們先來看一下系統出現異常之后會發生什么現象，再來介紹異常處理的方案。

我們打開瀏覽器，訪問系統中的新增部門操作，系統中已經有了 “學工部” 這個部門，我們再來增加一個學工部，看看會發生什么現象。

上述錯誤信息的含義是，dept部門表的name字段的值 學工部 重復了，因為在數據庫表dept中已經有了學工部，我們之前設計這張表時，為name字段建議了唯一約束，所以該字段的值是不能重復的。

而當我們再添加學工部，這個部門時，就違反了唯一約束，此時就會報錯。

接下來我們需要思考的是出現異常之后，當前案例項目的異常是怎么處理的？

• 答案：沒有做任何的異常處理
  當我們沒有做任何的異常處理時，我們三層架構處理異常的方案：

• Mapper接口在操作數據庫的時候出錯了，此時異常會往上拋(誰調用Mapper就拋給誰)，會拋給service。

• service 中也存在異常了，會拋給controller。

• 而在controller當中，我們也沒有做任何的異常處理，所以最終異常會再往上拋。最終拋給框架之后，框架就會返回一個JSON格式的數據，里面封裝的就是錯誤的信息，但是框架返回的JSON格式的數據并不符合我們的開發規范。

3.2 解決方案

那么在三層構架項目中，出現了異常，該如何處理?

• 方案一：在所有Controller的所有方法中進行try…catch處理
  • 缺點：代碼臃腫（不推薦）
• 方案二：全局異常處理器
  • 好處：簡單、優雅（推薦）

3.3 全局異常處理器

我們該怎么樣定義全局異常處理器？

• 定義全局異常處理器非常簡單，就是定義一個類，在類上加上一個注解@RestControllerAdvice，加上這個注解就代表我們定義了一個全局異常處理器。
• 在全局異常處理器當中，需要定義一個方法來捕獲異常，在這個方法上需要加上注解@ExceptionHandler。通過@ExceptionHandler注解當中的value屬性來指定我們要捕獲的是哪一類型的異常。

package com.itheima.exception;import com.itheima.pojo.Result;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;/*** 全局異常處理器*/
@RestControllerAdvice
public class GlobalExceptionHandler {@ExceptionHandler(Exception.class)  //捕獲所有異常public Result ex(Exception e) {e.printStackTrace();return Result.error("操作錯誤，請聯系管理員");}
}
//@RestControllerAdvice = @ControllerAdvice + @ResponseBody

@RestControllerAdvice = @ControllerAdvice + @ResponseBody

處理異常的方法返回值會轉換為json后再響應給前端

以上就是全局異常處理器的使用，主要涉及到兩個注解：

• @RestControllerAdvice //表示當前類為全局異常處理器
• @ExceptionHandler //指定可以捕獲哪種類型的異常進行處理