一、架構分析
目前絕大多數系統都已經采用 “前後端分離” 架構來設計了，傳統的Session模式鑒權也不再适合這種架構（或者需要額外寫很多的代碼來專門适配）。
Sa-Token 是一個 java 輕量級權限認證架構，專為前後端分離架構打造，主要解決登入認證、權限認證、單點登入、OAuth2、微服務網關鑒權 等一系列權限相關問題。
本文将介紹在 Springboot 架構下的前後端分離項目，如何使用 Sa-Token 友善的完成登入認證。
首先在項目中引入 Sa-Token 依賴：
<!-- Sa-Token 權限認證 -->
<dependency>
<groupId>cn.dev33</groupId>
<artifactId>sa-token-spring-boot-starter</artifactId>
<version>1.34.0</version>
</dependency> 注：如果你使用的是 SpringBoot 3.x，隻需要将 sa-token-spring-boot-starter 修改為 sa-token-spring-boot3-starter 即可。
二、無 Cookie 模式
無 Cookie 模式：特指不支援 Cookie 功能的終端，通俗來講就是我們常說的 —— 前後端分離模式。
正常 Web 端鑒權方法，一般由 Cookie模式 完成，而 Cookie 有兩個特性：
- 1. 可由後端控制寫入。
- 2. 每次請求自動送出。
這就使得我們在前端代碼中，無需任何特殊操作，就能完成鑒權的全部流程（因為整個流程都是後端控制完成的）
而在app、小程式等前後端分離場景中，一般是沒有 Cookie 這一功能的，此時大多數人都會一臉懵逼，咋進行鑒權啊？
見招拆招，其實答案很簡單：
- • 不能後端控制寫入了，就前端自己寫入。（難點在後端如何将 Token 傳遞到前端）
- • 每次請求不能自動送出了，那就手動送出。（難點在前端如何将 Token 傳遞到後端，同時後端将其讀取出來）
三、後端将 token 傳回到前端
- 1. 首先調用 StpUtil.login(id) 進行登入。
- 2. 調用 StpUtil.getTokenInfo() 傳回目前會話的 token 詳細參數。• 此方法傳回一個對象，其有兩個關鍵屬性：tokenName和tokenValue（token 的名稱和 token 的值）。• 将此對象傳遞到前台，讓前端人員将這兩個值儲存到本地。
代碼示例：
// 登入接口
@RequestMapping("doLogin")
public SaResult doLogin() {
// 第1步，先登入上
StpUtil.login(10001);
// 第2步，擷取 Token 相關參數
SaTokenInfo tokenInfo = StpUtil.getTokenInfo();
// 第3步，傳回給前端
return SaResult.data(tokenInfo);
} 四、前端将 token 送出到後端
- 1. 無論是app還是小程式，其傳遞方式都大同小異。
- 2. 那就是，将 token 塞到請求header裡 ，格式為：{tokenName: tokenValue}。
- 3. 以經典跨端架構 uni-app 為例：
方式1，簡單粗暴
// 1、首先在登入時，将 tokenValue 存儲在本地，例如：
uni.setStorageSync('tokenValue', tokenValue);
// 2、在發起ajax請求的地方，擷取這個值，并塞到header裡
uni.request({
url: 'https://www.example.com/request', // 僅為示例，并非真實接口位址。
header: {
"content-type": "application/x-www-form-urlencoded",
"satoken": uni.getStorageSync('tokenValue') // 關鍵代碼, 注意參數名字是 satoken
},
success: (res) => {
console.log(res.data);
}
}); 方式2，更加靈活
// 1、首先在登入時，将tokenName和tokenValue一起存儲在本地，例如：
uni.setStorageSync('tokenName', tokenName);
uni.setStorageSync('tokenValue', tokenValue);
// 2、在發起ajax的地方，擷取這兩個值, 并組織到head裡
var tokenName = uni.getStorageSync('tokenName'); // 從本地緩存讀取tokenName值
var tokenValue = uni.getStorageSync('tokenValue'); // 從本地緩存讀取tokenValue值
var header = {
"content-type": "application/x-www-form-urlencoded"
};
if (tokenName != undefined && tokenName != '') {
header[tokenName] = tokenValue;
}
// 3、後續在發起請求時将 header 對象塞到請求頭部
uni.request({
url: 'https://www.example.com/request', // 僅為示例，并非真實接口位址。
header: header,
success: (res) => {
console.log(res.data);
}
}); - 1. 隻要按照如此方法将token值傳遞到後端，Sa-Token 就能像傳統PC端一樣自動讀取到 token 值，進行鑒權。
- 2. 你可能會有疑問，難道我每個ajax都要寫這麼一坨？豈不是麻煩死了？• 你當然不能每個 ajax 都寫這麼一坨，因為這種重複性代碼都是要封裝在一個函數裡統一調用的。
其它解決方案：
如果你對 Cookie 非常了解，那你就會明白，所謂 Cookie ，本質上就是一個特殊的header參數而已， 而既然它隻是一個 header 參數，我們就能手動模拟實作它，進而完成鑒權操作。
這其實是對無Cookie模式的另一種解決方案，有興趣的同學可以百度了解一下，在此暫不贅述。
五、代碼對比
為了更加直覺的顯示出 前後端一體架構 和 前後端分離架構 的差異，此處再提供一個示例：
package com.pj.cases.up;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import cn.dev33.satoken.stp.SaTokenInfo;
import cn.dev33.satoken.stp.StpUtil;
import cn.dev33.satoken.util.SaResult;
/**
* Sa-Token 前後端分離模式示例
*
* @author kong
* @since 2022-10-17
*/
@RestController
@RequestMapping("/NotCookie/")
public class NotCookieController {
// 前後端一體模式的登入樣例 ---- http://localhost:8081/NotCookie/doLogin?name=zhang&pwd=123456
@RequestMapping("doLogin")
public SaResult doLogin(String name, String pwd) {
if("zhang".equals(name) && "123456".equals(pwd)) {
// 會話登入
StpUtil.login(10001);
return SaResult.ok();
}
return SaResult.error("登入失敗");
}
// 前後端分離模式的登入樣例 ---- http://localhost:8081/NotCookie/doLogin2?name=zhang&pwd=123456
@RequestMapping("doLogin2")
public SaResult doLogin2(String name, String pwd) {
if("zhang".equals(name) && "123456".equals(pwd)) {
// 會話登入
StpUtil.login(10001);
// 與正常登入不同點之處：這裡需要把 Token 資訊從響應體中傳回到前端
SaTokenInfo tokenInfo = StpUtil.getTokenInfo();
return SaResult.data(tokenInfo);
}
return SaResult.error("登入失敗");
}
} - • 接口一：Token 将在 Cookie 上下文傳回到前端，并由浏覽器每次請求時自動送出，這種模式适合前後端一體的架構。
- • 接口二：Token 将在響應 body 裡傳回到前端，并由前端手動存儲，并手動在每次請求時送出，這種模式适合前後端分離的架構。
六、自定義 Token 送出的字首
在某些系統中，前端送出token時會在前面加個固定的字首，例如：
{
"satoken": "Bearer xxxx-xxxx-xxxx-xxxx"
} 此時後端如果不做任何特殊處理，架構将會把Bearer 視為token的一部分，無法正常讀取token資訊，導緻鑒權失敗。
為此，我們需要在yml中添加如下配置：
sa-token:
# token字首
token-prefix: Bearer 此時 Sa-Token 便可在讀取 Token 時裁剪掉 Bearer，成功擷取xxxx-xxxx-xxxx-xxxx。
注意點：
- 1. Token字首 與 Token值 之間必須有一個空格。
- 2. 一旦配置了 Token字首，則前端送出 Token 時，必須帶有字首，否則會導緻架構無法讀取 Token。
- 3. 由于Cookie中無法存儲空格字元，也就意味配置 Token 字首後，Cookie 鑒權方式将會失效，此時隻能将 Token 送出到header裡進行傳輸。
七、自定義 Token 風格
Sa-Token預設的token生成政策是uuid風格，其模樣類似于：623368f0-ae5e-4475-a53f-93e4225f16ae。
如果你對這種風格不太感冒，還可以将token生成設定為其他風格。
怎麼設定呢？隻需要在yml配置檔案裡設定 sa-token.token-style=風格類型 即可，其有多種取值：
// 1. token-style=uuid —— uuid風格 (預設風格)
"623368f0-ae5e-4475-a53f-93e4225f16ae"
// 2. token-style=simple-uuid —— 同上，uuid風格, 隻不過去掉了中劃線
"6fd4221395024b5f87edd34bc3258ee8"
// 3. token-style=random-32 —— 随機32位字元串
"qEjyPsEA1Bkc9dr8YP6okFr5umCZNR6W"
// 4. token-style=random-64 —— 随機64位字元串
"v4ueNLEpPwMtmOPMBtOOeIQsvP8z9gkMgIVibTUVjkrNrlfra5CGwQkViDjO8jcc"
// 5. token-style=random-128 —— 随機128位字元串
"nojYPmcEtrFEaN0Otpssa8I8jpk8FO53UcMZkCP9qyoHaDbKS6dxoRPky9c6QlftQ0pdzxRGXsKZmUSrPeZBOD6kJFfmfgiRyUmYWcj4WU4SSP2ilakWN1HYnIuX0Olj"
// 6. token-style=tik —— tik風格
"gr_SwoIN0MC1ewxHX_vfCW3BothWDZMMtx__" 八、自定義 Token 生成政策
如果你覺着以上風格都不是你喜歡的類型，那麼你還可以自定義token生成政策，來定制化token生成風格。
怎麼做呢？隻需要重寫 SaStrategy 政策類的 createToken 算法即可：
參考步驟如下：
1、在SaTokenConfigure配置類中添加代碼：
@Configuration
public class SaTokenConfigure {
/**
* 重寫 Sa-Token 架構内部算法政策
*/
@Autowired
public void rewriteSaStrategy() {
// 重寫 Token 生成政策
SaStrategy.me.createToken = (loginId, loginType) -> {
return SaFoxUtil.getRandomString(60); // 随機60位長度字元串
};
}
} 2、再次調用 StpUtil.login(10001)方法進行登入，觀察其生成的token樣式:
gfuPSwZsnUhwgz08GTCH4wOgasWtc3odP4HLwXJ7NDGOximTvT4OlW19zeLH ![Django前後端分離[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)