前言

與開(kāi)發(fā)接口比起來(lái)，登錄認(rèn)證功能對(duì)于新手來(lái)說(shuō)理解起來(lái)更難，但是登錄又是每個(gè)系統(tǒng)中必不可少的功能，很多系統(tǒng)中的功能，沒(méi)有登錄是無(wú)法使用的，比如商場(chǎng)中的購(gòu)物車，你不用賬號(hào)登錄，根本不知道購(gòu)物車中有啥。本篇博客主題就是登錄認(rèn)證。 最終我們要實(shí)現(xiàn)的效果就是用戶必須登錄之后，才可以訪問(wèn)后臺(tái)系統(tǒng)中的功能。

需求

在登錄界面中，我們可以輸入用戶的用戶名以及密碼，然后點(diǎn)擊 “登錄” 按鈕就要請(qǐng)求服務(wù)器，服務(wù)端判斷用戶輸入的用戶名或者密碼是否正確。如果正確，則返回成功結(jié)果，前端跳轉(zhuǎn)至系統(tǒng)首頁(yè)面。

接口文檔

基本信息

請(qǐng)求路徑：/login

請(qǐng)求方式：POST

接口描述：該接口用于員工登錄系統(tǒng)，登錄完畢后，系統(tǒng)下發(fā)JWT令牌。 

請(qǐng)求參數(shù)
參數(shù)格式：application/json

參數(shù)說(shuō)明：

請(qǐng)求數(shù)據(jù)樣例：

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

響應(yīng)數(shù)據(jù)
參數(shù)格式：application/json

參數(shù)說(shuō)明：

響應(yīng)數(shù)據(jù)樣例：

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

思路分析

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

功能開(kāi)發(fā)

LoginController

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

EmpService

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

EmpServiceImpl

@Slf4j
@Service
public class EmpServiceImpl implements EmpService {
    @Autowired
    private EmpMapper empMapper;
    @Override
    public Emp login(Emp emp) {
        //調(diào)用dao層功能：登錄
        Emp loginEmp = empMapper.getByUsernameAndPassword(emp);
        //返回查詢結(jié)果給Controller
        return 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);
    //省略其他代碼...
}

問(wèn)題分析

我們已經(jīng)完成了基礎(chǔ)登錄功能的開(kāi)發(fā)，在我們登錄成功后就可以進(jìn)入到后臺(tái)管理系統(tǒng)中進(jìn)行數(shù)據(jù)的操作。

但是真正的登錄功能應(yīng)該是：登陸后才能訪問(wèn)后端系統(tǒng)頁(yè)面，不登陸則跳轉(zhuǎn)登陸頁(yè)面進(jìn)行登陸。

為什么會(huì)出現(xiàn)這個(gè)問(wèn)題？其實(shí)原因很簡(jiǎn)單，就是因?yàn)獒槍?duì)于我們當(dāng)前所開(kāi)發(fā)的部門(mén)管理、員工管理以及文件上傳等相關(guān)接口來(lái)說(shuō)，我們?cè)诜?wù)器端并沒(méi)有做任何的判斷，沒(méi)有去判斷用戶是否登錄了。所以無(wú)論用戶是否登錄，都可以訪問(wèn)部門(mén)管理以及員工管理的相關(guān)數(shù)據(jù)。所以我們目前所開(kāi)發(fā)的登錄功能，它只是徒有其表。而我們要想解決這個(gè)問(wèn)題，我們就需要完成一步非常重要的操作：登錄校驗(yàn)。

什么是登錄校驗(yàn)？

所謂登錄校驗(yàn)，指的是我們?cè)诜?wù)器端接收到瀏覽器發(fā)送過(guò)來(lái)的請(qǐng)求之后，首先我們要對(duì)請(qǐng)求進(jìn)行校驗(yàn)。先要校驗(yàn)一下用戶登錄了沒(méi)有，如果用戶已經(jīng)登錄了，就直接執(zhí)行對(duì)應(yīng)的業(yè)務(wù)操作就可以了；如果用戶沒(méi)有登錄，此時(shí)就不允許他執(zhí)行相關(guān)的業(yè)務(wù)操作，直接給前端響應(yīng)一個(gè)錯(cuò)誤的結(jié)果，最終跳轉(zhuǎn)到登錄頁(yè)面，要求他登錄成功之后，再來(lái)訪問(wèn)對(duì)應(yīng)的數(shù)據(jù)。

了解完什么是登錄校驗(yàn)之后，接下來(lái)我們分析一下登錄校驗(yàn)大概的實(shí)現(xiàn)思路。

首先我們?cè)诤暧^上先有一個(gè)認(rèn)知：
前面在講解HTTP協(xié)議的時(shí)候，我們提到HTTP協(xié)議是無(wú)狀態(tài)協(xié)議。什么又是無(wú)狀態(tài)的協(xié)議？

所謂無(wú)狀態(tài)，指的是每一次請(qǐng)求都是獨(dú)立的，下一次請(qǐng)求并不會(huì)攜帶上一次請(qǐng)求的數(shù)據(jù)。而瀏覽器與服務(wù)器之間進(jìn)行交互，基于HTTP協(xié)議也就意味著現(xiàn)在我們通過(guò)瀏覽器來(lái)訪問(wèn)了登陸這個(gè)接口，實(shí)現(xiàn)了登陸的操作，接下來(lái)我們?cè)趫?zhí)行其他業(yè)務(wù)操作時(shí)，服務(wù)器也并不知道這個(gè)員工到底登陸了沒(méi)有。因?yàn)镠TTP協(xié)議是無(wú)狀態(tài)的，兩次請(qǐng)求之間是獨(dú)立的，所以是無(wú)法判斷這個(gè)員工到底登陸了沒(méi)有。

那應(yīng)該怎么來(lái)實(shí)現(xiàn)登錄校驗(yàn)的操作呢？具體的實(shí)現(xiàn)思路可以分為兩部分：

• 在員工登錄成功后，需要將用戶登錄成功的信息存起來(lái)，記錄用戶已經(jīng)登錄成功的標(biāo)記。
• 在瀏覽器發(fā)起請(qǐng)求時(shí)，需要在服務(wù)端進(jìn)行統(tǒng)一攔截，攔截后進(jìn)行登錄校驗(yàn)。

想要判斷員工是否已經(jīng)登錄，我們需要在員工登錄成功之后，存儲(chǔ)一個(gè)登錄成功的標(biāo)記，接下來(lái)在每一個(gè)接口方法執(zhí)行之前，先做一個(gè)條件判斷，判斷一下這個(gè)員工到底登錄了沒(méi)有。如果是登錄了，就可以執(zhí)行正常的業(yè)務(wù)操作，如果沒(méi)有登錄，會(huì)直接給前端返回一個(gè)錯(cuò)誤的信息，前端拿到這個(gè)錯(cuò)誤信息之后會(huì)自動(dòng)的跳轉(zhuǎn)到登錄頁(yè)面。
我們程序中所開(kāi)發(fā)的查詢功能、刪除功能、添加功能、修改功能，都需要使用以上套路進(jìn)行登錄校驗(yàn)。此時(shí)就會(huì)出現(xiàn)：相同代碼邏輯，每個(gè)功能都需要編寫(xiě)，就會(huì)造成代碼非常繁瑣。
為了簡(jiǎn)化這塊操作，我們可以使用一種技術(shù)：統(tǒng)一攔截技術(shù)。
通過(guò)統(tǒng)一攔截的技術(shù)，我們可以來(lái)攔截瀏覽器發(fā)送過(guò)來(lái)的所有的請(qǐng)求，攔截到這個(gè)請(qǐng)求之后，就可以通過(guò)請(qǐng)求來(lái)獲取之前所存入的登錄標(biāo)記，在獲取到登錄標(biāo)記且標(biāo)記為登錄成功，就說(shuō)明員工已經(jīng)登錄了。如果已經(jīng)登錄，我們就直接放行(意思就是可以訪問(wèn)正常的業(yè)務(wù)接口了)。

我們要完成以上操作，會(huì)涉及到web開(kāi)發(fā)中的兩個(gè)技術(shù)：

• 會(huì)話技術(shù)
• 統(tǒng)一攔截技術(shù)

而統(tǒng)一攔截技術(shù)現(xiàn)實(shí)方案也有兩種：

• Servlet規(guī)范中的Filter過(guò)濾器
• Spring提供的interceptor攔截器

下面我們先學(xué)習(xí)會(huì)話技術(shù)，然后再學(xué)習(xí)統(tǒng)一攔截技術(shù)。

會(huì)話技術(shù)介紹

什么是會(huì)話？

• 在我們?nèi)粘Ｉ町?dāng)中，會(huì)話指的就是談話、交談。
• 在web開(kāi)發(fā)當(dāng)中，會(huì)話指的就是瀏覽器與服務(wù)器之間的一次連接，我們就稱為一次會(huì)話。

在用戶打開(kāi)瀏覽器第一次訪問(wèn)服務(wù)器的時(shí)候，這個(gè)會(huì)話就建立了，直到有任何一方斷開(kāi)連接，此時(shí)會(huì)話就結(jié)束了。在一次會(huì)話當(dāng)中，是可以包含多次請(qǐng)求和響應(yīng)的。
比如：打開(kāi)了瀏覽器來(lái)訪問(wèn)web服務(wù)器上的資源（瀏覽器不能關(guān)閉、服務(wù)器不能斷開(kāi)）

• 第1次：訪問(wèn)的是登錄的接口，完成登錄操作
• 第2次：訪問(wèn)的是部門(mén)管理接口，查詢所有部門(mén)數(shù)據(jù)
• 第3次：訪問(wèn)的是員工管理接口，查詢員工數(shù)據(jù)

只要瀏覽器和服務(wù)器都沒(méi)有關(guān)閉，以上3次請(qǐng)求都屬于一次會(huì)話當(dāng)中完成的。

需要注意的是：會(huì)話是和瀏覽器關(guān)聯(lián)的，當(dāng)有三個(gè)瀏覽器客戶端和服務(wù)器建立了連接時(shí)，就會(huì)有三個(gè)會(huì)話。同一個(gè)瀏覽器在未關(guān)閉之前請(qǐng)求了多次服務(wù)器，這多次請(qǐng)求是屬于同一個(gè)會(huì)話。比如：1、2、3這三個(gè)請(qǐng)求都是屬于同一個(gè)會(huì)話。當(dāng)我們關(guān)閉瀏覽器之后，這次會(huì)話就結(jié)束了。而如果我們是直接把web服務(wù)器關(guān)了，那么所有的會(huì)話就都結(jié)束了。

知道了會(huì)話的概念了，接下來(lái)我們?cè)賮?lái)了解下會(huì)話跟蹤。

會(huì)話跟蹤：一種維護(hù)瀏覽器狀態(tài)的方法，服務(wù)器需要識(shí)別多次請(qǐng)求是否來(lái)自于同一瀏覽器，以便在同一次會(huì)話的多次請(qǐng)求間共享數(shù)據(jù)。

服務(wù)器會(huì)接收很多的請(qǐng)求，但是服務(wù)器是需要識(shí)別出這些請(qǐng)求是不是同一個(gè)瀏覽器發(fā)出來(lái)的。比如：1和2這兩個(gè)請(qǐng)求是不是同一個(gè)瀏覽器發(fā)出來(lái)的，3和5這兩個(gè)請(qǐng)求不是同一個(gè)瀏覽器發(fā)出來(lái)的。如果是同一個(gè)瀏覽器發(fā)出來(lái)的，就說(shuō)明是同一個(gè)會(huì)話。如果是不同的瀏覽器發(fā)出來(lái)的，就說(shuō)明是不同的會(huì)話。而識(shí)別多次請(qǐng)求是否來(lái)自于同一瀏覽器的過(guò)程，我們就稱為會(huì)話跟蹤。

我們使用會(huì)話跟蹤技術(shù)就是要完成在同一個(gè)會(huì)話中，多個(gè)請(qǐng)求之間進(jìn)行共享數(shù)據(jù)。

為什么要共享數(shù)據(jù)呢？
由于HTTP是無(wú)狀態(tài)協(xié)議，在后面請(qǐng)求中怎么拿到前一次請(qǐng)求生成的數(shù)據(jù)呢？此時(shí)就需要在一次會(huì)話的多次請(qǐng)求之間進(jìn)行數(shù)據(jù)共享。

會(huì)話跟蹤技術(shù)有三種：

• Cookie（客戶端會(huì)話跟蹤技術(shù)）

• 數(shù)據(jù)存儲(chǔ)在客戶端瀏覽器當(dāng)中

• Session（服務(wù)端會(huì)話跟蹤技術(shù)）

• 數(shù)據(jù)存儲(chǔ)在儲(chǔ)在服務(wù)端

• 令牌技術(shù)

會(huì)話跟蹤技術(shù)一：Cookie

cookie 是客戶端會(huì)話跟蹤技術(shù)，它是存儲(chǔ)在客戶端瀏覽器的，我們使用 cookie 來(lái)跟蹤會(huì)話，我們就可以在瀏覽器第一次發(fā)起請(qǐng)求來(lái)請(qǐng)求服務(wù)器的時(shí)候，我們?cè)诜?wù)器端來(lái)設(shè)置一個(gè)cookie。

比如第一次請(qǐng)求了登錄接口，登錄接口執(zhí)行完成之后，我們就可以設(shè)置一個(gè)cookie，在 cookie 當(dāng)中我們就可以來(lái)存儲(chǔ)用戶相關(guān)的一些數(shù)據(jù)信息。比如我可以在 cookie 當(dāng)中來(lái)存儲(chǔ)當(dāng)前登錄用戶的用戶名，用戶的ID。

服務(wù)器端在給客戶端在響應(yīng)數(shù)據(jù)的時(shí)候，會(huì)自動(dòng)的將 cookie 響應(yīng)給瀏覽器，瀏覽器接收到響應(yīng)回來(lái)的 cookie 之后，會(huì)自動(dòng)的將 cookie 的值存儲(chǔ)在瀏覽器本地。接下來(lái)在后續(xù)的每一次請(qǐng)求當(dāng)中，都會(huì)將瀏覽器本地所存儲(chǔ)的 cookie 自動(dòng)地?cái)y帶到服務(wù)端。

接下來(lái)在服務(wù)端我們就可以獲取到 cookie 的值。我們可以去判斷一下這個(gè) cookie 的值是否存在，如果不存在這個(gè)cookie，就說(shuō)明客戶端之前是沒(méi)有訪問(wèn)登錄接口的；如果存在 cookie 的值，就說(shuō)明客戶端之前已經(jīng)登錄完成了。這樣我們就可以基于 cookie 在同一次會(huì)話的不同請(qǐng)求之間來(lái)共享數(shù)據(jù)。

我剛才在介紹流程的時(shí)候，用了 3 個(gè)自動(dòng)：

• 服務(wù)器會(huì) 自動(dòng) 的將 cookie 響應(yīng)給瀏覽器。
• 瀏覽器接收到響應(yīng)回來(lái)的數(shù)據(jù)之后，會(huì) 自動(dòng) 的將 cookie 存儲(chǔ)在瀏覽器本地。
• 在后續(xù)的請(qǐng)求當(dāng)中，瀏覽器會(huì) 自動(dòng) 的將 cookie 攜帶到服務(wù)器端。

為什么這一切都是自動(dòng)化進(jìn)行的？

是因?yàn)?cookie 它是 HTP 協(xié)議當(dāng)中所支持的技術(shù)，而各大瀏覽器廠商都支持了這一標(biāo)準(zhǔn)。在 HTTP 協(xié)議官方給我們提供了一個(gè)響應(yīng)頭和請(qǐng)求頭：

• 響應(yīng)頭 Set-Cookie ：設(shè)置Cookie數(shù)據(jù)的
• 請(qǐng)求頭 Cookie：攜帶Cookie數(shù)據(jù)的

代碼測(cè)試

@Slf4j
@RestController
public class SessionController {
    //設(shè)置Cookie
    @GetMapping("/c1")
    public Result cookie1(HttpServletResponse response){
        response.addCookie(new Cookie("login_username","xc")); //設(shè)置Cookie/響應(yīng)Cookie
        return Result.success();
    }
    //獲取Cookie
    @GetMapping("/c2")
    public Result cookie2(HttpServletRequest request){
        Cookie[] cookies = request.getCookies();
        for (Cookie cookie : cookies) {
            if(cookie.getName().equals("login_username")){
                System.out.println("login_username: "+cookie.getValue()); //輸出name為login_username的cookie
            }
        }
        return Result.success();
    }
}    

A. 訪問(wèn)c1接口，設(shè)置Cookie，http://localhost:8080/c1
我們可以看到，設(shè)置的cookie，通過(guò)響應(yīng)頭Set-Cookie響應(yīng)給瀏覽器，并且瀏覽器會(huì)將Cookie，存儲(chǔ)在瀏覽器端。

B. 訪問(wèn)c2接口 http://localhost:8080/c2，此時(shí)瀏覽器會(huì)自動(dòng)的將Cookie攜帶到服務(wù)端，是通過(guò)請(qǐng)求頭Cookie，攜帶的。

優(yōu)缺點(diǎn)

• 優(yōu)點(diǎn)：HTTP協(xié)議中支持的技術(shù)（像Set-Cookie 響應(yīng)頭的解析以及 Cookie 請(qǐng)求頭數(shù)據(jù)的攜帶，都是瀏覽器自動(dòng)進(jìn)行的，是無(wú)需我們手動(dòng)操作的）
• 缺點(diǎn)：
  • 移動(dòng)端APP(Android、IOS)中無(wú)法使用Cookie
  • 不安全，用戶可以自己禁用Cookie
  • Cookie不能跨域

跨域介紹：

• 現(xiàn)在的項(xiàng)目，大部分都是前后端分離的，前后端最終也會(huì)分開(kāi)部署，前端部署在服務(wù)器 192.168.150.200 上，端口 80，后端部署在 192.168.150.100上，端口 8080
• 我們打開(kāi)瀏覽器直接訪問(wèn)前端工程，訪問(wèn)url：http://192.168.150.200/login.html
• 然后在該頁(yè)面發(fā)起請(qǐng)求到服務(wù)端，而服務(wù)端所在地址不再是localhost，而是服務(wù)器的IP地址192.168.150.100，假設(shè)訪問(wèn)接口地址為：http://192.168.150.100:8080/login
• 那此時(shí)就存在跨域操作了，因?yàn)槲覀兪窃?http://192.168.150.200/login.html 這個(gè)頁(yè)面上訪問(wèn)了http://192.168.150.100:8080/login 接口
• 此時(shí)如果服務(wù)器設(shè)置了一個(gè)Cookie，這個(gè)Cookie是不能使用的，因?yàn)镃ookie無(wú)法跨域

區(qū)分跨域的維度：

• 協(xié)議
• IP/協(xié)議
• 端口

只要上述的三個(gè)維度有任何一個(gè)維度不同，那就是跨域操作

舉例：

? http://192.168.150.200/login.html ----------> https://192.168.150.200/login [協(xié)議不同，跨域]

? http://192.168.150.200/login.html ----------> http://192.168.150.100/login [IP不同，跨域]

? http://192.168.150.200/login.html ----------> http://192.168.150.200:8080/login [端口不同，跨域]

? http://192.168.150.200/login.html ----------> http://192.168.150.200/login [不跨域]

會(huì)話跟蹤技術(shù)二：Session

前面介紹的時(shí)候，我們提到Session，它是服務(wù)器端會(huì)話跟蹤技術(shù)，所以它是存儲(chǔ)在服務(wù)器端的。而 Session 的底層其實(shí)就是基于我們剛才所介紹的 Cookie 來(lái)實(shí)現(xiàn)的。

獲取Session

如果我們現(xiàn)在要基于 Session 來(lái)進(jìn)行會(huì)話跟蹤，瀏覽器在第一次請(qǐng)求服務(wù)器的時(shí)候，我們就可以直接在服務(wù)器當(dāng)中來(lái)獲取到會(huì)話對(duì)象Session。如果是第一次請(qǐng)求Session ，會(huì)話對(duì)象是不存在的，這個(gè)時(shí)候服務(wù)器會(huì)自動(dòng)的創(chuàng)建一個(gè)會(huì)話對(duì)象Session 。而每一個(gè)會(huì)話對(duì)象Session ，它都有一個(gè)ID（示意圖中Session后面括號(hào)中的1，就表示ID），我們稱之為 Session 的ID。

響應(yīng)Cookie (JSESSIONID)

接下來(lái)，服務(wù)器端在給瀏覽器響應(yīng)數(shù)據(jù)的時(shí)候，它會(huì)將 Session 的 ID 通過(guò) Cookie 響應(yīng)給瀏覽器。其實(shí)在響應(yīng)頭當(dāng)中增加了一個(gè) Set-Cookie 響應(yīng)頭。這個(gè) Set-Cookie 響應(yīng)頭對(duì)應(yīng)的值是不是cookie？ cookie 的名字是固定的 JSESSIONID 代表的服務(wù)器端會(huì)話對(duì)象 Session 的 ID。瀏覽器會(huì)自動(dòng)識(shí)別這個(gè)響應(yīng)頭，然后自動(dòng)將Cookie存儲(chǔ)在瀏覽器本地。

查找Session

接下來(lái)，在后續(xù)的每一次請(qǐng)求當(dāng)中，都會(huì)將 Cookie 的數(shù)據(jù)獲取出來(lái)，并且攜帶到服務(wù)端。接下來(lái)服務(wù)器拿到JSESSIONID這個(gè) Cookie 的值，也就是 Session 的ID。拿到 ID 之后，就會(huì)從眾多的 Session 當(dāng)中來(lái)找到當(dāng)前請(qǐng)求對(duì)應(yīng)的會(huì)話對(duì)象Session。

這樣我們是不是就可以通過(guò) Session 會(huì)話對(duì)象在同一次會(huì)話的多次請(qǐng)求之間來(lái)共享數(shù)據(jù)了？好，這就是基于 Session 進(jìn)行會(huì)話跟蹤的流程。

代碼測(cè)試

@Slf4j
@RestController
public class SessionController {
    @GetMapping("/s1")
    public Result session1(HttpSession session){
        log.info("HttpSession-s1: {}", session.hashCode());
        session.setAttribute("loginUser", "tom"); //往session中存儲(chǔ)數(shù)據(jù)
        return Result.success();
    }
    @GetMapping("/s2")
    public Result session2(HttpServletRequest request){
        HttpSession session = request.getSession();
        log.info("HttpSession-s2: {}", session.hashCode());
        Object loginUser = session.getAttribute("loginUser"); //從session中獲取數(shù)據(jù)
        log.info("loginUser: {}", loginUser);
        return Result.success(loginUser);
    }
}

A. 訪問(wèn) s1 接口，http://localhost:8080/s1

請(qǐng)求完成之后，在響應(yīng)頭中，就會(huì)看到有一個(gè)Set-Cookie的響應(yīng)頭，里面響應(yīng)回來(lái)了一個(gè)Cookie，就是JSESSIONID，這個(gè)就是服務(wù)端會(huì)話對(duì)象 Session 的ID。

B. 訪問(wèn) s2 接口，http://localhost:8080/s2

接下來(lái)，在后續(xù)的每次請(qǐng)求時(shí)，都會(huì)將Cookie的值，攜帶到服務(wù)端，那服務(wù)端呢，接收到Cookie之后，會(huì)自動(dòng)的根據(jù)JSESSIONID的值，找到對(duì)應(yīng)的會(huì)話對(duì)象Session。

優(yōu)缺點(diǎn)

• 優(yōu)點(diǎn)：Session是存儲(chǔ)在服務(wù)端的，安全
• 缺點(diǎn)：
  • 服務(wù)器集群環(huán)境下無(wú)法直接使用Session
  • 移動(dòng)端APP(Android、IOS)中無(wú)法使用Cookie
  • 用戶可以自己禁用Cookie
  • Cookie不能跨域

PS：Session 底層是基于Cookie實(shí)現(xiàn)的會(huì)話跟蹤，如果Cookie不可用，則該方案，也就失效了。

服務(wù)器集群環(huán)境為何無(wú)法使用Session？

首先第一點(diǎn)，我們現(xiàn)在所開(kāi)發(fā)的項(xiàng)目，一般都不會(huì)只部署在一臺(tái)服務(wù)器上，因?yàn)橐慌_(tái)服務(wù)器會(huì)存在一個(gè)很大的問(wèn)題，就是單點(diǎn)故障。所謂單點(diǎn)故障，指的就是一旦這臺(tái)服務(wù)器掛了，整個(gè)應(yīng)用都沒(méi)法訪問(wèn)了。

所以在現(xiàn)在的企業(yè)項(xiàng)目開(kāi)發(fā)當(dāng)中，最終部署的時(shí)候都是以集群的形式來(lái)進(jìn)行部署，也就是同一個(gè)項(xiàng)目它會(huì)部署多份。比如這個(gè)項(xiàng)目我們現(xiàn)在就部署了 3 份。

而用戶在訪問(wèn)的時(shí)候，到底訪問(wèn)這三臺(tái)其中的哪一臺(tái)？其實(shí)用戶在訪問(wèn)的時(shí)候，他會(huì)訪問(wèn)一臺(tái)前置的服務(wù)器，我們叫負(fù)載均衡服務(wù)器，我們?cè)诤竺骓?xiàng)目當(dāng)中會(huì)詳細(xì)講解。目前大家先有一個(gè)印象負(fù)載均衡服務(wù)器，它的作用就是將前端發(fā)起的請(qǐng)求均勻的分發(fā)給后面的這三臺(tái)服務(wù)器。

此時(shí)假如我們通過(guò) session 來(lái)進(jìn)行會(huì)話跟蹤，可能就會(huì)存在這樣一個(gè)問(wèn)題。用戶打開(kāi)瀏覽器要進(jìn)行登錄操作，此時(shí)會(huì)發(fā)起登錄請(qǐng)求。登錄請(qǐng)求到達(dá)負(fù)載均衡服務(wù)器，將這個(gè)請(qǐng)求轉(zhuǎn)給了第一臺(tái) Tomcat 服務(wù)器。

Tomcat 服務(wù)器接收到請(qǐng)求之后，要獲取到會(huì)話對(duì)象session。獲取到會(huì)話對(duì)象 session 之后，要給瀏覽器響應(yīng)數(shù)據(jù)，最終在給瀏覽器響應(yīng)數(shù)據(jù)的時(shí)候，就會(huì)攜帶這么一個(gè) cookie 的名字，就是 JSESSIONID ，下一次再請(qǐng)求的時(shí)候，是不是又會(huì)將 Cookie 攜帶到服務(wù)端？

好。此時(shí)假如又執(zhí)行了一次查詢操作，要查詢部門(mén)的數(shù)據(jù)。這次請(qǐng)求到達(dá)負(fù)載均衡服務(wù)器之后，負(fù)載均衡服務(wù)器將這次請(qǐng)求轉(zhuǎn)給了第二臺(tái) Tomcat 服務(wù)器，此時(shí)他就要到第二臺(tái) Tomcat 服務(wù)器當(dāng)中。根據(jù)JSESSIONID 也就是對(duì)應(yīng)的 session 的 ID 值，要找對(duì)應(yīng)的 session 會(huì)話對(duì)象。

我想請(qǐng)問(wèn)在第二臺(tái)服務(wù)器當(dāng)中有沒(méi)有這個(gè)ID的會(huì)話對(duì)象 Session， 是沒(méi)有的。此時(shí)是不是就出現(xiàn)問(wèn)題了？我同一個(gè)瀏覽器發(fā)起了 2 次請(qǐng)求，結(jié)果獲取到的不是同一個(gè)會(huì)話對(duì)象，這就是Session這種會(huì)話跟蹤方案它的缺點(diǎn)，在服務(wù)器集群環(huán)境下無(wú)法直接使用Session。

大家會(huì)看到上面這兩種傳統(tǒng)的會(huì)話技術(shù)，在現(xiàn)在的企業(yè)開(kāi)發(fā)當(dāng)中是不是會(huì)存在很多的問(wèn)題。 為了解決這些問(wèn)題，在現(xiàn)在的企業(yè)開(kāi)發(fā)當(dāng)中，基本上都會(huì)采用第三種方案，通過(guò)令牌技術(shù)來(lái)進(jìn)行會(huì)話跟蹤。接下來(lái)我們就來(lái)介紹一下令牌技術(shù)，來(lái)看一下令牌技術(shù)又是如何跟蹤會(huì)話的。

會(huì)話跟蹤技術(shù)三：令牌技術(shù)

這里我們所提到的令牌，其實(shí)它就是一個(gè)用戶身份的標(biāo)識(shí)，看似很高大上，很神秘，其實(shí)本質(zhì)就是一個(gè)字符串。

如果通過(guò)令牌技術(shù)來(lái)跟蹤會(huì)話，我們就可以在瀏覽器發(fā)起請(qǐng)求。在請(qǐng)求登錄接口的時(shí)候，如果登錄成功，我就可以生成一個(gè)令牌，令牌就是用戶的合法身份憑證。接下來(lái)我在響應(yīng)數(shù)據(jù)的時(shí)候，我就可以直接將令牌響應(yīng)給前端。

接下來(lái)我們?cè)谇岸顺绦虍?dāng)中接收到令牌之后，就需要將這個(gè)令牌存儲(chǔ)起來(lái)。這個(gè)存儲(chǔ)可以存儲(chǔ)在 cookie 當(dāng)中，也可以存儲(chǔ)在其他的存儲(chǔ)空間(比如：localStorage)當(dāng)中。

接下來(lái)，在后續(xù)的每一次請(qǐng)求當(dāng)中，都需要將令牌攜帶到服務(wù)端。攜帶到服務(wù)端之后，接下來(lái)我們就需要來(lái)校驗(yàn)令牌的有效性。如果令牌是有效的，就說(shuō)明用戶已經(jīng)執(zhí)行了登錄操作，如果令牌是無(wú)效的，就說(shuō)明用戶之前并未執(zhí)行登錄操作。

此時(shí)，如果是在同一次會(huì)話的多次請(qǐng)求之間，我們想共享數(shù)據(jù)，我們就可以將共享的數(shù)據(jù)存儲(chǔ)在令牌當(dāng)中就可以了。

優(yōu)缺點(diǎn)

• 優(yōu)點(diǎn)：
  • 支持PC端、移動(dòng)端
  • 解決集群環(huán)境下的認(rèn)證問(wèn)題
  • 減輕服務(wù)器的存儲(chǔ)壓力（無(wú)需在服務(wù)器端存儲(chǔ)）
• 缺點(diǎn)：需要自己實(shí)現(xiàn)（包括令牌的生成、令牌的傳遞、令牌的校驗(yàn)）

針對(duì)于這三種方案，現(xiàn)在企業(yè)開(kāi)發(fā)當(dāng)中使用的最多的就是第三種令牌技術(shù)進(jìn)行會(huì)話跟蹤。而前面的這兩種傳統(tǒng)的方案，現(xiàn)在企業(yè)項(xiàng)目開(kāi)發(fā)當(dāng)中已經(jīng)很少使用了。所以在我們的課程當(dāng)中，我們也將會(huì)采用令牌技術(shù)來(lái)解決案例項(xiàng)目當(dāng)中的會(huì)話跟蹤問(wèn)題。

詳解JWT令牌 介紹

JWT全稱：JSON Web Token （官網(wǎng)：https://jwt.io/）

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

簡(jiǎn)潔：是指jwt就是一個(gè)簡(jiǎn)單的字符串。可以在請(qǐng)求參數(shù)或者是請(qǐng)求頭當(dāng)中直接傳遞。

自包含：指的是jwt令牌，看似是一個(gè)隨機(jī)的字符串，但是我們是可以根據(jù)自身的需求在jwt令牌中存儲(chǔ)自定義的數(shù)據(jù)內(nèi)容。如：可以直接在jwt令牌中存儲(chǔ)用戶的相關(guān)信息。

簡(jiǎn)單來(lái)講，jwt就是將原始的json數(shù)據(jù)格式進(jìn)行了安全的封裝，這樣就可以直接基于jwt在通信雙方安全的進(jìn)行信息傳輸了。

JWT的組成： （JWT令牌由三個(gè)部分組成，三個(gè)部分之間使用英文的點(diǎn)來(lái)分割）

• 第一部分：Header(頭）， 記錄令牌類型、簽名算法等。 例如：{“alg”:“HS256”,“type”:“JWT”}
• 第二部分：Payload(有效載荷），攜帶一些自定義信息、默認(rèn)信息等。 例如：{“id”:“1”,“username”:“Tom”}
• 第三部分：Signature(簽名），防止Token被篡改、確保安全性。將header、payload，并加入指定秘鑰，通過(guò)指定簽名算法計(jì)算而來(lái)。

簽名的目的就是為了防jwt令牌被篡改，而正是因?yàn)閖wt令牌最后一個(gè)部分?jǐn)?shù)字簽名的存在，所以整個(gè)jwt 令牌是非常安全可靠的。一旦jwt令牌當(dāng)中任何一個(gè)部分、任何一個(gè)字符被篡改了，整個(gè)令牌在校驗(yàn)的時(shí)候都會(huì)失敗，所以它是非常安全可靠的。

JWT是如何將原始的JSON格式數(shù)據(jù)，轉(zhuǎn)變?yōu)樽址哪兀?/p>

其實(shí)在生成JWT令牌時(shí)，會(huì)對(duì)JSON格式的數(shù)據(jù)進(jìn)行一次編碼：進(jìn)行base64編碼

Base64：是一種基于64個(gè)可打印的字符來(lái)表示二進(jìn)制數(shù)據(jù)的編碼方式。既然能編碼，那也就意味著也能解碼。所使用的64個(gè)字符分別是A到Z、a到z、 0- 9，一個(gè)加號(hào)，一個(gè)斜杠，加起來(lái)就是64個(gè)字符。任何數(shù)據(jù)經(jīng)過(guò)base64編碼之后，最終就會(huì)通過(guò)這64個(gè)字符來(lái)表示。當(dāng)然還有一個(gè)符號(hào)，那就是等號(hào)。等號(hào)它是一個(gè)補(bǔ)位的符號(hào)

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

JWT令牌最典型的應(yīng)用場(chǎng)景就是登錄認(rèn)證：

• 在瀏覽器發(fā)起請(qǐng)求來(lái)執(zhí)行登錄操作，此時(shí)會(huì)訪問(wèn)登錄的接口，如果登錄成功之后，我們需要生成一個(gè)jwt令牌，將生成的 jwt令牌返回給前端。
• 前端拿到j(luò)wt令牌之后，會(huì)將jwt令牌存儲(chǔ)起來(lái)。在后續(xù)的每一次請(qǐng)求中都會(huì)將jwt令牌攜帶到服務(wù)端。
• 服務(wù)端統(tǒng)一攔截請(qǐng)求之后，先來(lái)判斷一下這次請(qǐng)求有沒(méi)有把令牌帶過(guò)來(lái)，如果沒(méi)有帶過(guò)來(lái)，直接拒絕訪問(wèn)，如果帶過(guò)來(lái)了，還要校驗(yàn)一下令牌是否是有效。如果有效，就直接放行進(jìn)行請(qǐng)求的處理。

在JWT登錄認(rèn)證的場(chǎng)景中我們發(fā)現(xiàn)，整個(gè)流程當(dāng)中涉及到兩步操作：

• 在登錄成功之后，要生成令牌。
• 每一次請(qǐng)求當(dāng)中，要接收令牌并對(duì)令牌進(jìn)行校驗(yàn)。

稍后我們?cè)賮?lái)學(xué)習(xí)如何來(lái)生成jwt令牌，以及如何來(lái)校驗(yàn)jwt令牌。

生成和校驗(yàn)

簡(jiǎn)單介紹了JWT令牌以及JWT令牌的組成之后，接下來(lái)我們就來(lái)學(xué)習(xí)基于Java代碼如何生成和校驗(yàn)JWT令牌。

首先我們先來(lái)實(shí)現(xiàn)JWT令牌的生成。要想使用JWT令牌，需要先引入JWT的依賴：

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

在引入完JWT來(lái)賴后，就可以調(diào)用工具包中提供的API來(lái)完成JWT令牌的生成和校驗(yàn)
工具類：Jwts

生成JWT代碼實(shí)現(xiàn)：

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

運(yùn)行測(cè)試方法：

eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjcyNzI5NzMwfQ.fHi0Ub8npbyt71UqLXDdLyipptLgxBUg_mSuGJtXtBk

輸出的結(jié)果就是生成的JWT令牌,，通過(guò)英文的點(diǎn)分割對(duì)三個(gè)部分進(jìn)行分割，我們可以將生成的令牌復(fù)制一下，然后打開(kāi)JWT的官網(wǎng)，將生成的令牌直接放在Encoded位置，此時(shí)就會(huì)自動(dòng)的將令牌解析出來(lái)。

第一部分解析出來(lái)，看到JSON格式的原始數(shù)據(jù)，所使用的簽名算法為HS256。

第二個(gè)部分是我們自定義的數(shù)據(jù)，之前我們自定義的數(shù)據(jù)就是id，還有一個(gè)exp代表的是我們所設(shè)置的過(guò)期時(shí)間。

由于前兩個(gè)部分是base64編碼，所以是可以直接解碼出來(lái)。但最后一個(gè)部分并不是base64編碼，是經(jīng)過(guò)簽名算法計(jì)算出來(lái)的，所以最后一個(gè)部分是不會(huì)解析的。

實(shí)現(xiàn)了JWT令牌的生成，下面我們接著使用Java代碼來(lái)校驗(yàn)JWT令牌(解析生成的令牌)：

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

運(yùn)行測(cè)試方法：

{id=1, exp=1672729730}

令牌解析后，我們可以看到id和過(guò)期時(shí)間，如果在解析的過(guò)程當(dāng)中沒(méi)有報(bào)錯(cuò)，就說(shuō)明解析成功了。

下面我們做一個(gè)測(cè)試：把令牌header中的數(shù)字9變?yōu)?，運(yùn)行測(cè)試方法后發(fā)現(xiàn)報(bào)錯(cuò)：

原h(huán)eader： eyJhbGciOiJIUzI1NiJ9

修改為： eyJhbGciOiJIUzI1NiJ8

結(jié)論：篡改令牌中的任何一個(gè)字符，在對(duì)令牌進(jìn)行解析時(shí)都會(huì)報(bào)錯(cuò)，所以JWT令牌是非常安全可靠的。

我們繼續(xù)測(cè)試：修改生成令牌的時(shí)指定的過(guò)期時(shí)間，修改為1分鐘

@Test
public void genJwt(){
    Map<String,Object> claims = new HashMap<>();
    claims.put(“id”,1);
    claims.put(“username”,“Tom”);
    String jwt = Jwts.builder()
        .setClaims(claims) //自定義內(nèi)容(載荷)          
        .signWith(SignatureAlgorithm.HS256, “xc”) //簽名算法        
        .setExpiration(new Date(System.currentTimeMillis() + 60*1000)) //有效期60秒   
        .compact();
    System.out.println(jwt);
    //輸出結(jié)果：eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjczMDA5NzU0fQ.RcVIR65AkGiax-ID6FjW60eLFH3tPTKdoK7UtE4A1ro
}
@Test
public void parseJwt(){
    Claims claims = Jwts.parser()
        .setSigningKey("xc")//指定簽名密鑰
.parseClaimsJws("eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjczMDA5NzU0fQ.RcVIR65AkGiax-ID6FjW60eLFH3tPTKdoK7UtE4A1ro")
        .getBody();
    System.out.println(claims);
}

等待1分鐘之后運(yùn)行測(cè)試方法發(fā)現(xiàn)也報(bào)錯(cuò)了，說(shuō)明：JWT令牌過(guò)期后，令牌就失效了，解析的為非法令牌。

通過(guò)以上測(cè)試，我們?cè)谑褂肑WT令牌時(shí)需要注意：

• JWT校驗(yàn)時(shí)使用的簽名秘鑰，必須和生成JWT令牌時(shí)使用的秘鑰是配套的。
• 如果JWT令牌解析校驗(yàn)時(shí)報(bào)錯(cuò)，則說(shuō)明 JWT令牌被篡改 或 失效了，令牌非法。

登錄下發(fā)令牌

JWT令牌的生成和校驗(yàn)的基本操作我們已經(jīng)學(xué)習(xí)完了，接下來(lái)我們就需要在案例當(dāng)中通過(guò)JWT令牌技術(shù)來(lái)跟蹤會(huì)話。具體的思路我們前面已經(jīng)分析過(guò)了，主要就是兩步操作：

• 生成令牌

• 在登錄成功之后來(lái)生成一個(gè)JWT令牌，并且把這個(gè)令牌直接返回給前端

• 校驗(yàn)令牌

• 攔截前端請(qǐng)求，從請(qǐng)求中獲取到令牌，對(duì)令牌進(jìn)行解析校驗(yàn)

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

JWT令牌怎么返回給前端呢？此時(shí)我們就需要再來(lái)看一下接口文檔當(dāng)中關(guān)于登錄接口的描述（主要看響應(yīng)數(shù)據(jù)）：

• 響應(yīng)數(shù)據(jù)

參數(shù)格式：application/json

參數(shù)說(shuō)明：

響應(yīng)數(shù)據(jù)樣例：

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

備注說(shuō)明

用戶登錄成功后，系統(tǒng)會(huì)自動(dòng)下發(fā)JWT令牌，然后在后續(xù)的每次請(qǐng)求中，都需要在請(qǐng)求頭header中攜帶到服務(wù)端，請(qǐng)求頭的名稱為 token ，值為 登錄時(shí)下發(fā)的JWT令牌。

如果檢測(cè)到用戶未登錄，則會(huì)返回如下固定錯(cuò)誤信息：

{
    "code": 0,
    "msg": "NOT_LOGIN",
    "data": null
}

解讀完接口文檔中的描述了，目前我們先來(lái)完成令牌的生成和令牌的下發(fā)，我們只需要生成一個(gè)令牌返回給前端就可以了。

實(shí)現(xiàn)步驟：

• 引入JWT工具類

• 在項(xiàng)目工程下創(chuàng)建com.example.utils包，并把提供JWT工具類復(fù)制到該包下

• 登錄完成后，調(diào)用工具類生成JWT令牌并返回

JWT工具類

public class JwtUtils {
    private static String signKey = "xc";//簽名密鑰
    private static Long expire = 43200000L; //有效時(shí)間
    /**
     * 生成JWT令牌
     * @param claims JWT第二部分負(fù)載 payload 中存儲(chǔ)的內(nèi)容
     * @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))//過(guò)期時(shí)間
                .compact();
        return jwt;
    }
    /**
     * 解析JWT令牌
     * @param jwt JWT令牌
     * @return JWT第二部分負(fù)載 payload 中存儲(chǔ)的內(nèi)容
     */
    public static Claims parseJWT(String jwt){
        Claims claims = Jwts.parser()
                .setSigningKey(signKey)//指定簽名密鑰
                .parseClaimsJws(jwt)//指定令牌Token
                .getBody();
        return claims;
    }
}

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

@RestController
@Slf4j
public class LoginController {
    //依賴業(yè)務(wù)層對(duì)象
    @Autowired
    private EmpService empService;
    @PostMapping("/login")
    public Result login(@RequestBody Emp emp) {
        //調(diào)用業(yè)務(wù)層：登錄功能
        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("用戶名或密碼錯(cuò)誤");
    }
}

服務(wù)器響應(yīng)的JWT令牌存儲(chǔ)在本地瀏覽器哪里了呢？
在當(dāng)前案例中，JWT令牌存儲(chǔ)在瀏覽器的本地存儲(chǔ)空間local storage中了。 local storage是瀏覽器的本地存儲(chǔ)，在移動(dòng)端也是支持的。

過(guò)濾器Filter

剛才通過(guò)瀏覽器的開(kāi)發(fā)者工具，我們可以看到在后續(xù)的請(qǐng)求當(dāng)中，都會(huì)在請(qǐng)求頭中攜帶JWT令牌到服務(wù)端，而服務(wù)端需要統(tǒng)一攔截所有的請(qǐng)求，從而判斷是否攜帶的有合法的JWT令牌。
那怎么樣來(lái)統(tǒng)一攔截到所有的請(qǐng)求校驗(yàn)令牌的有效性呢？這里我們會(huì)學(xué)習(xí)兩種解決方案：

• Filter過(guò)濾器
• Interceptor攔截器

我們首先來(lái)學(xué)習(xí)過(guò)濾器Filter。

快速入門(mén)

什么是Filter？

• Filter表示過(guò)濾器，是 JavaWeb三大組件(Servlet、Filter、Listener)之一。
• 過(guò)濾器可以把對(duì)資源的請(qǐng)求攔截下來(lái)，從而實(shí)現(xiàn)一些特殊的功能
  • 使用了過(guò)濾器之后，要想訪問(wèn)web服務(wù)器上的資源，必須先經(jīng)過(guò)濾器，過(guò)濾器處理完畢之后，才可以訪問(wèn)對(duì)應(yīng)的資源。
• 過(guò)濾器一般完成一些通用的操作，比如：登錄校驗(yàn)、統(tǒng)一編碼處理、敏感字符處理等。

下面我們通過(guò)Filter快速入門(mén)程序掌握過(guò)濾器的基本使用操作：

• 第1步，定義過(guò)濾器 ：1.定義一個(gè)類，實(shí)現(xiàn) Filter 接口，并重寫(xiě)其所有方法。
• 第2步，配置過(guò)濾器：Filter類上加 @WebFilter 注解，配置攔截資源的路徑。引導(dǎo)類上加 @ServletComponentScan 開(kāi)啟Servlet組件支持。

定義過(guò)濾器

//定義一個(gè)類，實(shí)現(xiàn)一個(gè)標(biāo)準(zhǔn)的Filter過(guò)濾器的接口
public class DemoFilter implements Filter {
    @Override //初始化方法, 只調(diào)用一次
    public void init(FilterConfig filterConfig) throws ServletException {
        System.out.println("init 初始化方法執(zhí)行了");
    }
    @Override //攔截到請(qǐng)求之后調(diào)用, 調(diào)用多次
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("Demo 攔截到了請(qǐng)求...放行前邏輯");
        //放行
        chain.doFilter(request,response);
    }
    @Override //銷毀方法, 只調(diào)用一次
    public void destroy() {
        System.out.println("destroy 銷毀方法執(zhí)行了");
    }
}

• init方法：過(guò)濾器的初始化方法。在web服務(wù)器啟動(dòng)的時(shí)候會(huì)自動(dòng)的創(chuàng)建Filter過(guò)濾器對(duì)象，在創(chuàng)建過(guò)濾器對(duì)象的時(shí)候會(huì)自動(dòng)調(diào)用init初始化方法，這個(gè)方法只會(huì)被調(diào)用一次。
• doFilter方法：這個(gè)方法是在每一次攔截到請(qǐng)求之后都會(huì)被調(diào)用，所以這個(gè)方法是會(huì)被調(diào)用多次的，每攔截到一次請(qǐng)求就會(huì)調(diào)用一次doFilter()方法。
• destroy方法： 是銷毀的方法。當(dāng)我們關(guān)閉服務(wù)器的時(shí)候，它會(huì)自動(dòng)的調(diào)用銷毀方法destroy，而這個(gè)銷毀方法也只會(huì)被調(diào)用一次。

在定義完Filter之后，F(xiàn)ilter其實(shí)并不會(huì)生效，還需要完成Filter的配置，F(xiàn)ilter的配置非常簡(jiǎn)單，只需要在Filter類上添加一個(gè)注解：@WebFilter，并指定屬性u(píng)rlPatterns，通過(guò)這個(gè)屬性指定過(guò)濾器要攔截哪些請(qǐng)求

@WebFilter(urlPatterns = "/*") //配置過(guò)濾器要攔截的請(qǐng)求路徑（ /* 表示攔截瀏覽器的所有請(qǐng)求 ）
public class DemoFilter implements Filter {
    @Override //初始化方法, 只調(diào)用一次
    public void init(FilterConfig filterConfig) throws ServletException {
        System.out.println("init 初始化方法執(zhí)行了");
    }
    @Override //攔截到請(qǐng)求之后調(diào)用, 調(diào)用多次
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("Demo 攔截到了請(qǐng)求...放行前邏輯");
        //放行
        chain.doFilter(request,response);
    }
    @Override //銷毀方法, 只調(diào)用一次
    public void destroy() {
        System.out.println("destroy 銷毀方法執(zhí)行了");
    }
}

當(dāng)我們?cè)贔ilter類上面加了@WebFilter注解之后，接下來(lái)我們還需要在啟動(dòng)類上面加上一個(gè)注解@ServletComponentScan，通過(guò)這個(gè)@ServletComponentScan注解來(lái)開(kāi)啟SpringBoot項(xiàng)目對(duì)于Servlet組件的支持。

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

注意事項(xiàng)：
? 在過(guò)濾器Filter中，如果不執(zhí)行放行操作，將無(wú)法訪問(wèn)后面的資源。 放行操作：chain.doFilter(request, response);

現(xiàn)在我們已完成了Filter過(guò)濾器的基本使用，下面我們將學(xué)習(xí)Filter過(guò)濾器在使用過(guò)程中的一些細(xì)節(jié)。

Filter詳解

Filter過(guò)濾器的快速入門(mén)程序我們已經(jīng)完成了，接下來(lái)我們就要詳細(xì)的介紹一下過(guò)濾器Filter在使用中的一些細(xì)節(jié)。主要介紹以下3個(gè)方面的細(xì)節(jié)：

• 過(guò)濾器的執(zhí)行流程
• 過(guò)濾器的攔截路徑配置
• 過(guò)濾器鏈

執(zhí)行流程
首先我們先來(lái)看下過(guò)濾器的執(zhí)行流程：

過(guò)濾器當(dāng)中我們攔截到了請(qǐng)求之后，如果希望繼續(xù)訪問(wèn)后面的web資源，就要執(zhí)行放行操作，放行就是調(diào)用 FilterChain對(duì)象當(dāng)中的doFilter()方法，在調(diào)用doFilter()這個(gè)方法之前所編寫(xiě)的代碼屬于放行之前的邏輯。

在放行后訪問(wèn)完 web 資源之后還會(huì)回到過(guò)濾器當(dāng)中，回到過(guò)濾器之后如有需求還可以執(zhí)行放行之后的邏輯，放行之后的邏輯我們寫(xiě)在doFilter()這行代碼之后。

@WebFilter(urlPatterns = "/*") 
public class DemoFilter implements Filter {
    @Override //初始化方法, 只調(diào)用一次
    public void init(FilterConfig filterConfig) throws ServletException {
        System.out.println("init 初始化方法執(zhí)行了");
    }
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        System.out.println("DemoFilter   放行前邏輯.....");
        //放行請(qǐng)求
        filterChain.doFilter(servletRequest,servletResponse);
        System.out.println("DemoFilter   放行后邏輯.....");
    }
    @Override //銷毀方法, 只調(diào)用一次
    public void destroy() {
        System.out.println("destroy 銷毀方法執(zhí)行了");
    }
}

攔截路徑
執(zhí)行流程我們搞清楚之后，接下來(lái)再來(lái)介紹一下過(guò)濾器的攔截路徑，F(xiàn)ilter可以根據(jù)需求，配置不同的攔截資源路徑：

下面我們來(lái)測(cè)試"攔截具體路徑"：

@WebFilter(urlPatterns = "/login")  //攔截/login具體路徑
public class DemoFilter implements Filter {
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        System.out.println("DemoFilter   放行前邏輯.....");
        //放行請(qǐng)求
        filterChain.doFilter(servletRequest,servletResponse);
        System.out.println("DemoFilter   放行后邏輯.....");
    }
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        Filter.super.init(filterConfig);
    }
    @Override
    public void destroy() {
        Filter.super.destroy();
    }
}

測(cè)試1：訪問(wèn)部門(mén)管理請(qǐng)求，發(fā)現(xiàn)過(guò)濾器沒(méi)有攔截請(qǐng)求

測(cè)試2：訪問(wèn)登錄請(qǐng)求/login，發(fā)現(xiàn)過(guò)濾器攔截請(qǐng)求

下面我們來(lái)測(cè)試"目錄攔截"：

@WebFilter(urlPatterns = "/depts/*") //攔截所有以/depts開(kāi)頭，后面是什么無(wú)所謂
public class DemoFilter implements Filter {
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        System.out.println("DemoFilter   放行前邏輯.....");
        //放行請(qǐng)求
        filterChain.doFilter(servletRequest,servletResponse);
        System.out.println("DemoFilter   放行后邏輯.....");
    }
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        Filter.super.init(filterConfig);
    }
    @Override
    public void destroy() {
        Filter.super.destroy();
    }
}

測(cè)試1：訪問(wèn)部門(mén)管理請(qǐng)求，發(fā)現(xiàn)過(guò)濾器攔截了請(qǐng)求

測(cè)試2：訪問(wèn)登錄請(qǐng)求/login，發(fā)現(xiàn)過(guò)濾器沒(méi)有攔截請(qǐng)求

過(guò)濾器鏈
最后我們?cè)趤?lái)介紹下過(guò)濾器鏈，什么是過(guò)濾器鏈呢？所謂過(guò)濾器鏈指的是在一個(gè)web應(yīng)用程序當(dāng)中，可以配置多個(gè)過(guò)濾器，多個(gè)過(guò)濾器就形成了一個(gè)過(guò)濾器鏈。

比如：在我們web服務(wù)器當(dāng)中，定義了兩個(gè)過(guò)濾器，這兩個(gè)過(guò)濾器就形成了一個(gè)過(guò)濾器鏈。

而這個(gè)鏈上的過(guò)濾器在執(zhí)行的時(shí)候會(huì)一個(gè)一個(gè)的執(zhí)行，會(huì)先執(zhí)行第一個(gè)Filter，放行之后再來(lái)執(zhí)行第二個(gè)Filter，如果執(zhí)行到了最后一個(gè)過(guò)濾器放行之后，才會(huì)訪問(wèn)對(duì)應(yīng)的web資源。

訪問(wèn)完web資源之后，按照我們剛才所介紹的過(guò)濾器的執(zhí)行流程，還會(huì)回到過(guò)濾器當(dāng)中來(lái)執(zhí)行過(guò)濾器放行后的邏輯，而在執(zhí)行放行后的邏輯的時(shí)候，順序是反著的。

先要執(zhí)行過(guò)濾器2放行之后的邏輯，再來(lái)執(zhí)行過(guò)濾器1放行之后的邏輯，最后在給瀏覽器響應(yīng)數(shù)據(jù)。

以上就是當(dāng)我們?cè)趙eb應(yīng)用當(dāng)中配置了多個(gè)過(guò)濾器，形成了這樣一個(gè)過(guò)濾器鏈以及過(guò)濾器鏈的執(zhí)行順序。下面我們通過(guò)idea來(lái)驗(yàn)證下過(guò)濾器鏈。

驗(yàn)證步驟：

• 在filter包下再來(lái)新建一個(gè)Filter過(guò)濾器類：AbcFilter
• 在AbcFilter過(guò)濾器中編寫(xiě)放行前和放行后邏輯
• 配置AbcFilter過(guò)濾器攔截請(qǐng)求路徑為：/*
• 重啟SpringBoot服務(wù)，查看DemoFilter、AbcFilter的執(zhí)行日志

AbcFilter過(guò)濾器

@WebFilter(urlPatterns = "/*")
public class AbcFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("Abc 攔截到了請(qǐng)求... 放行前邏輯");
        //放行
        chain.doFilter(request,response);
        System.out.println("Abc 攔截到了請(qǐng)求... 放行后邏輯");
    }
}

DemoFilter過(guò)濾器

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

打開(kāi)瀏覽器訪問(wèn)登錄接口：

通過(guò)控制臺(tái)日志的輸出，大家發(fā)現(xiàn)AbcFilter先執(zhí)行DemoFilter后執(zhí)行，這是為什么呢？

其實(shí)是和過(guò)濾器的類名有關(guān)系。以注解方式配置的Filter過(guò)濾器，它的執(zhí)行優(yōu)先級(jí)是按時(shí)過(guò)濾器類名的自動(dòng)排序確定的，類名排名越靠前，優(yōu)先級(jí)越高。

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

測(cè)試：修改AbcFilter類名為XbcFilter，運(yùn)行程序查看控制臺(tái)日志

@WebFilter(urlPatterns = "/*")
public class XbcFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("Xbc 攔截到了請(qǐng)求...放行前邏輯");
        //放行
        chain.doFilter(request,response);
        System.out.println("Xbc 攔截到了請(qǐng)求...放行后邏輯");
    }
}

到此，關(guān)于過(guò)濾器的使用細(xì)節(jié)，我們已經(jīng)全部介紹完畢了。

登錄校驗(yàn)-Filter 分析

過(guò)濾器Filter的快速入門(mén)以及使用細(xì)節(jié)我們已經(jīng)介紹完了，接下來(lái)最后一步，我們需要使用過(guò)濾器Filter來(lái)完成案例當(dāng)中的登錄校驗(yàn)功能。

我們先來(lái)回顧下前面分析過(guò)的登錄校驗(yàn)的基本流程：

• 要進(jìn)入到后臺(tái)管理系統(tǒng)，我們必須先完成登錄操作，此時(shí)就需要訪問(wèn)登錄接口login。
• 登錄成功之后，我們會(huì)在服務(wù)端生成一個(gè)JWT令牌，并且把JWT令牌返回給前端，前端會(huì)將JWT令牌存儲(chǔ)下來(lái)。
• 在后續(xù)的每一次請(qǐng)求當(dāng)中，都會(huì)將JWT令牌攜帶到服務(wù)端，請(qǐng)求到達(dá)服務(wù)端之后，要想去訪問(wèn)對(duì)應(yīng)的業(yè)務(wù)功能，此時(shí)我們必須先要校驗(yàn)令牌的有效性。
• 對(duì)于校驗(yàn)令牌的這一塊操作，我們使用登錄校驗(yàn)的過(guò)濾器，在過(guò)濾器當(dāng)中來(lái)校驗(yàn)令牌的有效性。如果令牌是無(wú)效的，就響應(yīng)一個(gè)錯(cuò)誤的信息，也不會(huì)再去放行訪問(wèn)對(duì)應(yīng)的資源了。如果令牌存在，并且它是有效的，此時(shí)就會(huì)放行去訪問(wèn)對(duì)應(yīng)的web資源，執(zhí)行相應(yīng)的業(yè)務(wù)操作。

大概清楚了在Filter過(guò)濾器的實(shí)現(xiàn)步驟了，那在正式開(kāi)發(fā)登錄校驗(yàn)過(guò)濾器之前，我們思考兩個(gè)問(wèn)題：

• 所有的請(qǐng)求，攔截到了之后，都需要校驗(yàn)令牌嗎？

• 答案：登錄請(qǐng)求例外

• 攔截到請(qǐng)求后，什么情況下才可以放行，執(zhí)行業(yè)務(wù)操作？

• 答案：**有令牌，且令牌校驗(yàn)通過(guò)(合法)；否則都返回未登錄錯(cuò)誤結(jié)果

具體流程

我們要完成登錄校驗(yàn)，主要是利用Filter過(guò)濾器實(shí)現(xiàn)，而Filter過(guò)濾器的流程步驟：

基于上面的業(yè)務(wù)流程，我們分析出具體的操作步驟：

• 獲取請(qǐng)求url
• 判斷請(qǐng)求url中是否包含login，如果包含，說(shuō)明是登錄操作，放行
• 獲取請(qǐng)求頭中的令牌（token）
• 判斷令牌是否存在，如果不存在，返回錯(cuò)誤結(jié)果（未登錄）
• 解析token，如果解析失敗，返回錯(cuò)誤結(jié)果（未登錄）
• 放行

代碼實(shí)現(xiàn)
分析清楚了以上的問(wèn)題后，我們就參照接口文檔來(lái)開(kāi)發(fā)登錄功能了，登錄接口描述如下：

基本信息

請(qǐng)求路徑：/login
請(qǐng)求方式：POST
接口描述：該接口用于員工登錄Tlias智能學(xué)習(xí)輔助系統(tǒng)，登錄完畢后，系統(tǒng)下發(fā)JWT令牌。 

請(qǐng)求參數(shù)

參數(shù)格式：application/json

參數(shù)說(shuō)明：

請(qǐng)求數(shù)據(jù)樣例：

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

響應(yīng)數(shù)據(jù)

參數(shù)格式：application/json

參數(shù)說(shuō)明：

響應(yīng)數(shù)據(jù)樣例：

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

備注說(shuō)明

用戶登錄成功后，系統(tǒng)會(huì)自動(dòng)下發(fā)JWT令牌，然后在后續(xù)的每次請(qǐng)求中，都需要在請(qǐng)求頭header中攜帶到服務(wù)端，請(qǐng)求頭的名稱為 token ，值為 登錄時(shí)下發(fā)的JWT令牌。

如果檢測(cè)到用戶未登錄，則會(huì)返回如下固定錯(cuò)誤信息：

{
    "code": 0,
    "msg": "NOT_LOGIN",
    "data": null
}

登錄校驗(yàn)過(guò)濾器：LoginCheckFilter

@Slf4j
@WebFilter(urlPatterns = "/*") //攔截所有請(qǐng)求
public class LoginCheckFilter implements Filter {
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {
        //前置：強(qiáng)制轉(zhuǎn)換為http協(xié)議的請(qǐng)求對(duì)象、響應(yīng)對(duì)象 （轉(zhuǎn)換原因：要使用子類中特有方法）
        HttpServletRequest request = (HttpServletRequest) servletRequest;
        HttpServletResponse response = (HttpServletResponse) servletResponse;
        //1.獲取請(qǐng)求url
        String url = request.getRequestURL().toString();
        log.info("請(qǐng)求路徑：{}", url); //請(qǐng)求路徑：http://localhost:8080/login
        //2.判斷請(qǐng)求url中是否包含login，如果包含，說(shuō)明是登錄操作，放行
        if(url.contains("/login")){
            chain.doFilter(request, response);//放行請(qǐng)求
            return;//結(jié)束當(dāng)前方法的執(zhí)行
        }
        //3.獲取請(qǐng)求頭中的令牌（token）
        String token = request.getHeader("token");
        log.info("從請(qǐng)求頭中獲取的令牌：{}",token);
        //4.判斷令牌是否存在，如果不存在，返回錯(cuò)誤結(jié)果（未登錄）
        if(!StringUtils.hasLength(token)){
            log.info("Token不存在");
            Result responseResult = Result.error("NOT_LOGIN");
            //把Result對(duì)象轉(zhuǎn)換為JSON格式字符串 (fastjson是阿里巴巴提供的用于實(shí)現(xiàn)對(duì)象和json的轉(zhuǎn)換工具類)
            String json = JSONObject.toJSONString(responseResult);
            response.setContentType("application/json;charset=utf-8");
            //響應(yīng)
            response.getWriter().write(json);
            return;
        }
        //5.解析token，如果解析失敗，返回錯(cuò)誤結(jié)果（未登錄）
        try {
            JwtUtils.parseJWT(token);
        }catch (Exception e){
            log.info("令牌解析失敗!");
            Result responseResult = Result.error("NOT_LOGIN");
            //把Result對(duì)象轉(zhuǎn)換為JSON格式字符串 (fastjson是阿里巴巴提供的用于實(shí)現(xiàn)對(duì)象和json的轉(zhuǎn)換工具類)
            String json = JSONObject.toJSONString(responseResult);
            response.setContentType("application/json;charset=utf-8");
            //響應(yīng)
            response.getWriter().write(json);
            return;
        }
        //6.放行
        chain.doFilter(request, response);
    }
}

在上述過(guò)濾器的功能實(shí)現(xiàn)中，我們使用到了一個(gè)第三方j(luò)son處理的工具包fastjson。我們要想使用，需要引入如下依賴：

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

攔截器Interceptor

學(xué)習(xí)完了過(guò)濾器Filter之后，接下來(lái)我們繼續(xù)學(xué)習(xí)攔截器Interseptor。

攔截器我們主要分為三個(gè)方面進(jìn)行講解：

• 介紹下什么是攔截器，并通過(guò)快速入門(mén)程序上手?jǐn)r截器
• 攔截器的使用細(xì)節(jié)
• 通過(guò)攔截器Interceptor完成登錄校驗(yàn)功能

我們先學(xué)習(xí)第一塊內(nèi)容：攔截器快速入門(mén)

快速入門(mén)

• 什么是攔截器？
• 是一種動(dòng)態(tài)攔截方法調(diào)用的機(jī)制，類似于過(guò)濾器。攔截器是Spring框架中提供的，用來(lái)動(dòng)態(tài)攔截控制器方法的執(zhí)行。

攔截器的作用：

• 攔截請(qǐng)求，在指定方法調(diào)用前后，根據(jù)業(yè)務(wù)需要執(zhí)行預(yù)先設(shè)定的代碼。

在攔截器當(dāng)中，我們通常也是做一些通用性的操作，比如：我們可以通過(guò)攔截器來(lái)攔截前端發(fā)起的請(qǐng)求，將登錄校驗(yàn)的邏輯全部編寫(xiě)在攔截器當(dāng)中。在校驗(yàn)的過(guò)程當(dāng)中，如發(fā)現(xiàn)用戶登錄了(攜帶JWT令牌且是合法令牌)，就可以直接放行，去訪問(wèn)spring當(dāng)中的資源。如果校驗(yàn)時(shí)發(fā)現(xiàn)并沒(méi)有登錄或是非法令牌，就可以直接給前端響應(yīng)未登錄的錯(cuò)誤信息。

下面我們通過(guò)快速入門(mén)程序，來(lái)學(xué)習(xí)下攔截器的基本使用。攔截器的使用步驟和過(guò)濾器類似，也分為兩步：

• 定義攔截器
• 注冊(cè)配置攔截器

自定義攔截器:實(shí)現(xiàn)HandlerInterceptor接口，并重寫(xiě)其所有方法

//自定義攔截器
@Component
public class LoginCheckInterceptor implements HandlerInterceptor {
    //目標(biāo)資源方法執(zhí)行前執(zhí)行。 返回true：放行    返回false：不放行
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        System.out.println("preHandle .... ");
        return true; //true表示放行
    }
    //目標(biāo)資源方法執(zhí)行后執(zhí)行
    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        System.out.println("postHandle ... ");
    }
    //視圖渲染完畢后執(zhí)行，最后執(zhí)行
    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        System.out.println("afterCompletion .... ");
    }
}

注意：
? preHandle方法：目標(biāo)資源方法執(zhí)行前執(zhí)行。 返回true：放行 返回false：不放行
? postHandle方法：目標(biāo)資源方法執(zhí)行后執(zhí)行
? afterCompletion方法：視圖渲染完畢后執(zhí)行，最后執(zhí)行

注冊(cè)配置攔截器：實(shí)現(xiàn)WebMvcConfigurer接口，并重寫(xiě)addInterceptors方法

@Configuration  
public class WebConfig implements WebMvcConfigurer {
    //自定義的攔截器對(duì)象
    @Autowired
    private LoginCheckInterceptor loginCheckInterceptor;
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
       //注冊(cè)自定義攔截器對(duì)象
        registry.addInterceptor(loginCheckInterceptor).addPathPatterns("/**");//設(shè)置攔截器攔截的請(qǐng)求路徑（ /** 表示攔截所有請(qǐng)求）
    }
}

Interceptor詳解

攔截器的入門(mén)程序完成之后，接下來(lái)我們來(lái)介紹攔截器的使用細(xì)節(jié)。攔截器的使用細(xì)節(jié)我們主要介紹兩個(gè)部分：

• 攔截器的攔截路徑配置
• 攔截器的執(zhí)行流程

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

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

@Configuration  
public class WebConfig implements WebMvcConfigurer {
    //攔截器對(duì)象
    @Autowired
    private LoginCheckInterceptor loginCheckInterceptor;
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        //注冊(cè)自定義攔截器對(duì)象
        registry.addInterceptor(loginCheckInterceptor)
                .addPathPatterns("/**")//設(shè)置攔截器攔截的請(qǐng)求路徑（ /** 表示攔截所有請(qǐng)求）
                .excludePathPatterns("/login");//設(shè)置不攔截的請(qǐng)求路徑
    }
}

在攔截器中除了可以設(shè)置/**攔截所有資源外，還有一些常見(jiàn)攔截路徑設(shè)置：

下面主要來(lái)演示下/**與/*的區(qū)別：

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

@Configuration 
public class WebConfig implements WebMvcConfigurer {
    //攔截器對(duì)象
    @Autowired
    private LoginCheckInterceptor loginCheckInterceptor;
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
       //注冊(cè)自定義攔截器對(duì)象
        registry.addInterceptor(loginCheckInterceptor)
                .addPathPatterns("/*")
                .excludePathPatterns("/login");//設(shè)置不攔截的請(qǐng)求路徑
    }
}

執(zhí)行流程
介紹完攔截路徑的配置之后，接下來(lái)我們?cè)賮?lái)介紹攔截器的執(zhí)行流程。通過(guò)執(zhí)行流程，大家就能夠清晰的知道過(guò)濾器與攔截器的執(zhí)行時(shí)機(jī)。

• 當(dāng)我們打開(kāi)瀏覽器來(lái)訪問(wèn)部署在web服務(wù)器當(dāng)中的web應(yīng)用時(shí)，此時(shí)我們所定義的過(guò)濾器會(huì)攔截到這次請(qǐng)求。攔截到這次請(qǐng)求之后，它會(huì)先執(zhí)行放行前的邏輯，然后再執(zhí)行放行操作。而由于我們當(dāng)前是基于springboot開(kāi)發(fā)的，所以放行之后是進(jìn)入到了spring的環(huán)境當(dāng)中，也就是要來(lái)訪問(wèn)我們所定義的controller當(dāng)中的接口方法。
• Tomcat并不識(shí)別所編寫(xiě)的Controller程序，但是它識(shí)別Servlet程序，所以在Spring的Web環(huán)境中提供了一個(gè)非常核心的Servlet：DispatcherServlet（前端控制器），所有請(qǐng)求都會(huì)先進(jìn)行到DispatcherServlet，再將請(qǐng)求轉(zhuǎn)給Controller。
• 當(dāng)我們定義了攔截器后，會(huì)在執(zhí)行Controller的方法之前，請(qǐng)求被攔截器攔截住。執(zhí)行preHandle()方法，這個(gè)方法執(zhí)行完成后需要返回一個(gè)布爾類型的值，如果返回true，就表示放行本次操作，才會(huì)繼續(xù)訪問(wèn)controller中的方法；如果返回false，則不會(huì)放行（controller中的方法也不會(huì)執(zhí)行）。
• 在controller當(dāng)中的方法執(zhí)行完畢之后，再回過(guò)來(lái)執(zhí)行postHandle()這個(gè)方法以及afterCompletion() 方法，然后再返回給DispatcherServlet，最終再來(lái)執(zhí)行過(guò)濾器當(dāng)中放行后的這一部分邏輯的邏輯。執(zhí)行完畢之后，最終給瀏覽器響應(yīng)數(shù)據(jù)。

接下來(lái)我們就來(lái)演示下過(guò)濾器和攔截器同時(shí)存在的執(zhí)行流程：

• 開(kāi)啟LoginCheckInterceptor攔截器

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

@Configuration  
public class WebConfig implements WebMvcConfigurer {
    //攔截器對(duì)象
    @Autowired
    private LoginCheckInterceptor loginCheckInterceptor;
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        //注冊(cè)自定義攔截器對(duì)象
        registry.addInterceptor(loginCheckInterceptor)
                .addPathPatterns("/**")//攔截所有請(qǐng)求
                .excludePathPatterns("/login");//不攔截登錄請(qǐng)求
    }
}

開(kāi)啟DemoFilter過(guò)濾器

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

以上就是攔截器的執(zhí)行流程。通過(guò)執(zhí)行流程分析，大家應(yīng)該已經(jīng)清楚了過(guò)濾器和攔截器之間的區(qū)別，其實(shí)它們之間的區(qū)別主要是兩點(diǎn)：

• 接口規(guī)范不同：過(guò)濾器需要實(shí)現(xiàn)Filter接口，而攔截器需要實(shí)現(xiàn)HandlerInterceptor接口。
• 攔截范圍不同：過(guò)濾器Filter會(huì)攔截所有的資源，而Interceptor只會(huì)攔截Spring環(huán)境中的資源。

登錄校驗(yàn)- Interceptor

講解完了攔截器的基本操作之后，接下來(lái)我們需要完成最后一步操作：通過(guò)攔截器來(lái)完成案例當(dāng)中的登錄校驗(yàn)功能。

登錄校驗(yàn)的業(yè)務(wù)邏輯以及操作步驟我們前面已經(jīng)分析過(guò)了，和登錄校驗(yàn)Filter過(guò)濾器當(dāng)中的邏輯是完全一致的?，F(xiàn)在我們只需要把這個(gè)技術(shù)方案由原來(lái)的過(guò)濾器換成攔截器interceptor就可以了。
登錄校驗(yàn)攔截器

//自定義攔截器
@Component //當(dāng)前攔截器對(duì)象由Spring創(chuàng)建和管理
@Slf4j
public class LoginCheckInterceptor implements HandlerInterceptor {
    //前置方式
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        System.out.println("preHandle .... ");
        //1.獲取請(qǐng)求url
        //2.判斷請(qǐng)求url中是否包含login，如果包含，說(shuō)明是登錄操作，放行
        //3.獲取請(qǐng)求頭中的令牌（token）
        String token = request.getHeader("token");
        log.info("從請(qǐng)求頭中獲取的令牌：{}",token);
        //4.判斷令牌是否存在，如果不存在，返回錯(cuò)誤結(jié)果（未登錄）
        if(!StringUtils.hasLength(token)){
            log.info("Token不存在");
            //創(chuàng)建響應(yīng)結(jié)果對(duì)象
            Result responseResult = Result.error("NOT_LOGIN");
            //把Result對(duì)象轉(zhuǎn)換為JSON格式字符串 (fastjson是阿里巴巴提供的用于實(shí)現(xiàn)對(duì)象和json的轉(zhuǎn)換工具類)
            String json = JSONObject.toJSONString(responseResult);
            //設(shè)置響應(yīng)頭（告知瀏覽器：響應(yīng)的數(shù)據(jù)類型為json、響應(yīng)的數(shù)據(jù)編碼表為utf-8）
            response.setContentType("application/json;charset=utf-8");
            //響應(yīng)
            response.getWriter().write(json);
            return false;//不放行
        }
        //5.解析token，如果解析失敗，返回錯(cuò)誤結(jié)果（未登錄）
        try {
            JwtUtils.parseJWT(token);
        }catch (Exception e){
            log.info("令牌解析失敗!");
            //創(chuàng)建響應(yīng)結(jié)果對(duì)象
            Result responseResult = Result.error("NOT_LOGIN");
            //把Result對(duì)象轉(zhuǎn)換為JSON格式字符串 (fastjson是阿里巴巴提供的用于實(shí)現(xiàn)對(duì)象和json的轉(zhuǎn)換工具類)
            String json = JSONObject.toJSONString(responseResult);
            //設(shè)置響應(yīng)頭
            response.setContentType("application/json;charset=utf-8");
            //響應(yīng)
            response.getWriter().write(json);
            return false;
        }
        //6.放行
        return true;
    }

注冊(cè)配置攔截器

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

到此這篇關(guān)于一文掌握J(rèn)avaWeb登錄認(rèn)證的文章就介紹到這了,更多相關(guān)JavaWeb登錄認(rèn)證內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！