mirror of
https://gitee.com/dromara/sa-token.git
synced 2025-06-28 13:34:18 +08:00
优化文档
This commit is contained in:
click33
parent
23c00b5d8e
commit
7695fbf05e
@ -2,7 +2,7 @@
|
||||
|
||||
---
|
||||
|
||||
在`sa-token`中, `Session` 分为三种, 分别是：
|
||||
在`Sa-Token`中, `Session` 分为三种, 分别是：
|
||||
- `User-Session`: 指的是框架为每个`loginId`分配的`Session`
|
||||
- `Token-Session`: 指的是框架为每个`token`分配的`Session`
|
||||
- `自定义Session`: 指的是以一个`特定的值`作为SessionId，来分配的`Session`
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# sa-token 源码用到的所有技术栈
|
||||
# Sa-Token 源码用到的所有技术栈
|
||||
|
||||
包括但不限于以下：
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
- **2020-10-26：** Gitee star数量破100
|
||||
- **2021-03-01：** 被[HelloGitHub]第59期收录推荐
|
||||
- **2021-03-26：** GitHub star数量破1k
|
||||
- **2021-03-30：** 受TLog作者邀请，sa-token加入dromara社区
|
||||
- **2021-03-30：** 受TLog作者邀请，Sa-Token加入dromara社区
|
||||
- **2021-03-30：** 被Gitee官方列为推荐项目
|
||||
- **2021-03-31：** Gitee star数量破1K
|
||||
- **2021-04-09：** GitHub star数量破2K
|
||||
|
||||
@ -1,36 +1,36 @@
|
||||
# token有效期详解
|
||||
# Token有效期详解
|
||||
|
||||
<!-- 本篇介绍token有效期的详细用法 -->
|
||||
<!-- 本篇介绍Token有效期的详细用法 -->
|
||||
|
||||
`sa-token` 提供两种token自动过期策略，分别是`timeout`与`activity-timeout`，其详细用法如下：
|
||||
Sa-Token 提供两种Token自动过期策略，分别是`timeout`与`activity-timeout`，其详细用法如下：
|
||||
|
||||
|
||||
### timeout
|
||||
1. `timeout`代表token的长久有效期，单位/秒，例如将其配置为`2592000`(30天)，代表在30天后，token必定过期，无法继续使用
|
||||
1. `timeout`代表Token的长久有效期，单位/秒，例如将其配置为 2592000 (30天)，代表在30天后，Token必定过期，无法继续使用
|
||||
2. `timeout`无法续签，想要继续使用必须重新登录
|
||||
3. `timeout`的值配置为-1后，代表永久有效，不会过期
|
||||
|
||||
|
||||
### activity-timeout
|
||||
1. `activity-timeout`代表临时有效期，单位/秒，例如将其配置为`1800`(30分钟)，代表用户如果30分钟无操作，则此token会立即过期
|
||||
2. 如果在30分钟内用户有操作，则会再次续签30分钟，用户如果一直操作则会一直续签，直到连续30分钟无操作，token才会过期
|
||||
1. `activity-timeout`代表临时有效期，单位/秒，例如将其配置为 1800 (30分钟)，代表用户如果30分钟无操作，则此Token会立即过期
|
||||
2. 如果在30分钟内用户有操作，则会再次续签30分钟，用户如果一直操作则会一直续签，直到连续30分钟无操作，Token才会过期
|
||||
3. `activity-timeout`的值配置为-1后，代表永久有效，不会过期，此时也无需频繁续签
|
||||
|
||||
|
||||
### 关于activity-timeout的续签
|
||||
如果`activity-timeout`配置了大于零的值，`sa-token`会在登录时开始计时，在每次直接或间接调用`getLoginId()`时进行一次过期检查与续签操作。
|
||||
如果`activity-timeout`配置了大于零的值，Sa-Token 会在登录时开始计时，在每次直接或间接调用`getLoginId()`时进行一次过期检查与续签操作。
|
||||
此时会有两种情况：
|
||||
1. 一种是会话无操作时间太长，token已经过期，此时框架会抛出`NotLoginException`异常(场景值=-3)，
|
||||
2. 另一种则是会话在`activity-timeout`有效期内通过检查，此时token可以成功续签
|
||||
1. 一种是会话无操作时间太长，Token已经过期，此时框架会抛出`NotLoginException`异常(场景值=-3)，
|
||||
2. 另一种则是会话在`activity-timeout`有效期内通过检查，此时Token可以成功续签
|
||||
|
||||
|
||||
### 我可以手动续签吗？
|
||||
**可以！**
|
||||
如果框架的自动续签算法无法满足您的业务需求，你可以进行手动续签，`sa-token`提供两个API供你操作：
|
||||
1. `StpUtil.checkActivityTimeout()`: 检查当前token 是否已经[临时过期]，如果已经过期则抛出异常
|
||||
2. `StpUtil.updateLastActivityToNow()`: 续签当前token：(将 [最后操作时间] 更新为当前时间戳)
|
||||
如果框架的自动续签算法无法满足您的业务需求，你可以进行手动续签，Sa-Token 提供两个API供你操作：
|
||||
1. `StpUtil.checkActivityTimeout()`: 检查当前Token 是否已经[临时过期]，如果已经过期则抛出异常
|
||||
2. `StpUtil.updateLastActivityToNow()`: 续签当前Token：(将 [最后操作时间] 更新为当前时间戳)
|
||||
|
||||
注意：在手动续签时，即时token已经 [临时过期] 也可续签成功，如果此场景下需要提示续签失败，可采用先检查再续签的形式保证token有效性
|
||||
注意：在手动续签时，即使Token已经 [临时过期] 也可续签成功，如果此场景下需要提示续签失败，可采用先检查再续签的形式保证Token有效性
|
||||
|
||||
例如以下代码：
|
||||
``` java
|
||||
|
||||
@ -1,112 +0,0 @@
|
||||
# Web开发常见漏洞防护
|
||||
本章介绍web开发时常见漏洞的防护方法
|
||||
|
||||
|
||||
### 点击劫持
|
||||
|
||||
简而言之，点击劫持就是攻击者会自己搭建一个网页，这个网页分为两层：
|
||||
- 上层是被iframe导入的被攻击网站，具有一些敏感性操作，比如转账、点赞等按钮，这一层会完全透明
|
||||
- 下层是攻击者自己精心制作的网页，它会准备一个按钮诱导你进行点击(比如点击领取红包等)，当你点击这个按钮时，响应你的将不会是这个按钮，而是上层的转账页面，在不知情的情况下造成财产损失
|
||||
|
||||
详情介绍参考：[https://blog.csdn.net/qq_32523587/article/details/79613768](https://blog.csdn.net/qq_32523587/article/details/79613768)
|
||||
|
||||
防范点击劫持的最有效做法就是增加响应头：`X-Frame-Options: DENY`, 告诉浏览器我们的网站不可以通过 iframe 进行展示（浏览器收到此响应头的指示之后，会拒绝渲染页面），
|
||||
从根本上杜绝了点击劫持发生的可能，在 [全局过滤器](/use/global-filter) 章节的示例中，我们已经展示了如何在过滤器中增加安全响应头
|
||||
|
||||
响应头`X-Frame-Options`有三个取值：
|
||||
- `DENY`: 任何时候都不可以通过 iframe 展示视图
|
||||
- `SAMEORIGIN`: 在同域下可以通过 iframe 展示视图
|
||||
- `ALLOW-FROM uri`: 指定地址来源的访问下可以通过 iframe 展示视图
|
||||
|
||||
除了后端的响应头，我们还可以在前端使用如下方式进行判断：
|
||||
``` js
|
||||
// 判断当前页面是否在顶层视口打开
|
||||
if(top != window) {
|
||||
// 跳入一个安全页面，比如404页
|
||||
location.href="xxx";
|
||||
}
|
||||
```
|
||||
除了跳转页面，你还可以用其它方法防御点击劫持，比如加载一个全局遮罩来隔离用户的点击操作，或者在非顶层窗口下拒绝提交token，使用户保持未登录状态
|
||||
|
||||
|
||||
### XSS攻击
|
||||
|
||||
XSS（跨站脚本攻击）就是指攻击者在一段正常的内容中嵌入恶意脚本，使得访问网页的用户自动运行一些破坏性的代码
|
||||
|
||||
例如一个论坛具有发帖功能，攻击者在发帖时故意插入一段如下内容：
|
||||
``` java
|
||||
<img src="xxx" onerror="alert('xss攻击！')" />
|
||||
```
|
||||
如果论坛服务端没有对此进行任何防护，那么用户每次访问这个帖子的时候都会被强制弹窗，
|
||||
事实上真正的`XSS攻击`绝不只是弹窗骚扰一下那么简单，它可以完成窃取Cookie，自动转账等破坏性操作
|
||||
|
||||
防范XSS攻击：
|
||||
1. 首先安全响应头给安排上：`X-Frame-Options: 1; mode=block`, 这是浏览器默认提供的XSS防护机制
|
||||
2. 有条件的情况下，尽量使用前后台分离架构，传统服务端渲染视图时几乎每一个变量都可能成为XSS注入点，而前后台分离下一般只有富文本渲染才会有机会XSS注入
|
||||
3. 对所有的用户输入必须XSS过滤，特别是字符串型参数
|
||||
4. 可以使用一些自动扫描工具寻找潜在的 XSS 漏洞
|
||||
|
||||
|
||||
### CSRF攻击
|
||||
CSRF（跨站请求伪造），又称 XSRF，攻击流程如下：
|
||||
|
||||
1. 用户登陆站点`a.com`，身份令牌被写入Cookie中
|
||||
2. 攻击者搭建站点`b.com`，引诱用户访问
|
||||
3. 用户访问`b.com`时，自动执行了攻击者准备的js代码，即：调用`a.com`的转账接口
|
||||
4. 用户在不知情的情况下，造成了财产损失
|
||||
|
||||
仅仅访问一个不安全的站点就让我们造成了财产损失？事实上，真正的CSRF攻击并没有这么简单，挡在攻击者第一道门槛便是`CORS同源策略`
|
||||
|
||||
同源策略限制了js在`b.com`中只能操作`b.com`的数据（`Cookie`、`localStorage`、`DOM`等），而无法直接操作`a.com`的数据。
|
||||
|
||||
这就导致一个结果：虽然在`b.com`可以调用`a.com`的转账接口，但是却无法携带用户储存在`a.com`的授权Cookie，对于`a.com`来讲，即使收到了浏览器发来的请求，
|
||||
也因为请求中没有携带token令牌，而无法识别调用者具体是谁，只能将其视为一次无效调用。
|
||||
|
||||
但是，请注意！这个小小的限制，虽然为用户提供了安全保护，却也为我们开发者造成了不小的困扰，特别是在前后端分离架构下，我们经常会遇到这个错误：
|
||||
|
||||
|
||||
|
||||
这就是导致无数前端后端互相撕逼的 —— 跨域！
|
||||
|
||||
浏览器在检测到你身处`b.com`却想要调用`a.com`的接口时，会率先发送一个`OPTIONS`预检请求，目的是为了询问`a.com`是否同意`b.com`发起的请求，
|
||||
在默认情况下，`a.com`收到一个陌生的第三方网站发来的请求，做出的回应肯定是：`不允许`, 浏览器收到回应就识相的关闭了请求，跨域请求失败
|
||||
|
||||
但是，有些开发者为了省事，直接设置了响应头: `Access-Control-Allow-Origin: *`，允许任何第三方网站的请求，这就给`CSRF攻击`留下了可乘之机
|
||||
|
||||
假设我们设置了只允许指定的网站跨域请求，就万事大吉了吗？并没有，攻击者仍可以通过抓包等手段得到我们的转账url，
|
||||
在`b.com`里，通过`open(url)`直接打开一个新的窗口调用转账接口，由于是属于打开新页面，浏览器连`OPTIONS`预检请求都不会发送，而是直接调用接口成功
|
||||
|
||||
此招无解吗？并不。由于它是属于打开新页面，这就导致调用接口时只能发送`get请求`，我们在设计接口时只需要遵守一个准则：`敏感接口一律post，禁止get调用`即可。
|
||||
|
||||
究其原因，导致`CSRF攻击`频频发生的原因是什么？是我们在跨域请求时，浏览器总是“自作聪明”的自动提交主站`Cookie`，
|
||||
在浏览器的不断更新中，Cookie的跨域规则变得愈发复杂，新手开发者及其容易绕的晕头转向，而同时`w3c`对`Cookie`规范的各种修修补补，又总是解决一个问题的同时暴露出其他的N多问题
|
||||
|
||||
既然Cookie机制如此难以驾驭，我们何不果断的放弃Cookie机制，改用`localStorage`机制存储会话token，这种方式轻松避免了`自动提交`带来的各种安全问题。
|
||||
事实上，`localStorage存储` + `header请求头提交`也是前后台分离趋势下的常见会话处理方案
|
||||
|
||||
篇幅有限，我们总结一下防范`CSRF攻击`要点
|
||||
|
||||
**在Cookie模式下**：
|
||||
1. 仅靠`CORS同源策略`无法彻底防范`CSRF攻击`，我们必须在后台建立`第三方域名白名单`，只有在白名单中的第三方域名才可以跨域调用我们的接口
|
||||
2. 涉及到数据增删改类型的接口，必须是`post`模式(或其它)，严禁`get`模式，查询接口可以`get`
|
||||
3. 敏感操作增加验证码或者二次验证密码，减小被攻击的概率
|
||||
|
||||
**在 localStorage存储 + header请求头提交 模式下**：
|
||||
1. 在配置文件中，配置`is-read-cookie: false`，关闭Cookie模式，防止Sa-Token在登录时注入Cookie
|
||||
2. 同上，敏感操作增加验证码或者二次验证密码，减小被攻击的概率
|
||||
|
||||
有关CSRF攻防讲解的比较通透的一篇文章：[https://juejin.cn/post/6844903689702866952](https://juejin.cn/post/6844903689702866952)
|
||||
|
||||
|
||||
### Token泄露
|
||||
Token泄露一般发生在客户端，比如用户连接了不安全的WiFi导致通讯被监听，虽然此情形下token泄露的责任在于用户，但是我们还是有必要采取一定的措施使其损失降到最低
|
||||
1. 有条件上https的话一律https
|
||||
2. token有效期一定不能设置为永久，而且要尽量的短（but：为了不影响用户体验又不能设置特别的短，so: 7-30天是个比较合适的范围）
|
||||
3. 对敏感操作接口，增加密码二次校验(或手机验证码等)
|
||||
4. 用户更改密码后使其历史会话直接过期
|
||||
5. 有条件的情况下后台管理增加踢人下线功能，对已经泄露token的账号可以及时清理下线
|
||||
|
||||
|
||||
<br><br>
|
||||
更多类型漏洞连载中.... （欢迎提交pr）
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
<html lang="zh">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>sa-token</title>
|
||||
<title>Sa-Token</title>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
|
||||
<meta name="description" content="sa-token是一个java权限认证框架，功能全面，上手简单，登录验证、权限验证、Session会话、踢人下线、账号封禁、集成Redis、前后台分离、分布式会话、微服务网关鉴权、单点登录、临时Token验证、记住我模式、模拟他人账号、临时身份切换、多账号体系、注解式鉴权、路由拦截式鉴权、花式token、自动续签、同端互斥登录、会话治理、密码加密、jwt集成、Spring集成、WebFlux集成...，有了sa-token，你所有的权限认证问题，都不再是问题">
|
||||
<meta name="keywords" content="sa-token,sa-token框架,sa-token文档,java权限认证">
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
|
||||
|
||||
### 登录方法需要我自己实现吗？
|
||||
是的，不同于`shiro`等框架，`sa-token`不会在登录流程中强插一脚，开发者比对完用户的账号和密码之后，只需要调用`StpUtil.login(id)`通知一下框架即可
|
||||
是的，不同于`shiro`等框架，`Sa-Token`不会在登录流程中强插一脚，开发者比对完用户的账号和密码之后，只需要调用`StpUtil.login(id)`通知一下框架即可
|
||||
|
||||
|
||||
### 一个User对象存进Session后，再取出来时报错：无法从User类型转换成User类型？
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
---
|
||||
|
||||
#### 集成sa-token的开源项目:
|
||||
#### 集成Sa-Token的开源项目:
|
||||
|
||||
[[sa-plus] 一个基于springboot架构的快速开发框架，内置代码生成器](https://gitee.com/click33/sa-plus)
|
||||
|
||||
|
||||
@ -4,17 +4,17 @@
|
||||
|
||||
### 推荐须知：
|
||||
Sa-Token作为一个新兴项目，迫切需要一定的途径进行项目推广<br>
|
||||
如果您也是java公众号运营者，欢迎您将sa-token框架推荐给您的粉丝：
|
||||
如果您也是java公众号运营者，欢迎您将Sa-Token框架推荐给您的粉丝：
|
||||
|
||||
1. 您无需为sa-token专门撰写文案，只需要复制项目仓库的 Readme 内容即可，可参考：[链接](https://mp.weixin.qq.com/s/xMCedNj6Nti2BwGzS9A0mg)
|
||||
1. 您无需为Sa-Token专门撰写文案，只需要复制项目仓库的 Readme 内容即可，可参考：[链接](https://mp.weixin.qq.com/s/xMCedNj6Nti2BwGzS9A0mg)
|
||||
2. 在文章底部或内容中留下项目官网或者GitHub仓库链接
|
||||
3. 文章需至少 1000+ 的阅读量
|
||||
|
||||
作为回报，sa-token将：
|
||||
作为回报，Sa-Token将：
|
||||
1. 在框架官方文档 [[推荐公众号]](/more/tj-gzh) 处留下您的公众号二维码（按照推荐日期倒叙排列）
|
||||
2. 在框架官方交流群里@全体成员推广您的公众号一次
|
||||
3. 您的公众号所有新推文章都可以将链接发送到sa-token交流群中，增加阅读量（为避免频繁推送连接，请不要超过一周三次）
|
||||
3. 您的公众号所有新推文章都可以将链接发送到Sa-Token交流群中，增加阅读量（为避免频繁推送连接，请不要超过一周三次）
|
||||
|
||||
<br>
|
||||
如果您还有除公众号以外的其它途径可以与sa-token相互推荐，欢迎加群交流……（群链接在首页）
|
||||
如果您还有除公众号以外的其它途径可以与Sa-Token相互推荐，欢迎加群交流……（群链接在首页）
|
||||
|
||||
|
||||
@ -163,5 +163,5 @@
|
||||
|
||||
<br>
|
||||
|
||||
感谢以上公众号对 sa-token 项目的推荐，如果您也是java公众号运营者，欢迎 [相互推荐](/more/tj-gzh-hz)
|
||||
感谢以上公众号对 Sa-Token 项目的推荐，如果您也是java公众号运营者，欢迎 [相互推荐](/more/tj-gzh-hz)
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
因此Sa-Token提供AOP插件，你只需在`pom.xml`里添加如下依赖，便可以在任意层级使用注解鉴权
|
||||
|
||||
``` xml
|
||||
<!-- sa-token整合SpringAOP实现注解鉴权 -->
|
||||
<!-- Sa-Token整合SpringAOP实现注解鉴权 -->
|
||||
<dependency>
|
||||
<groupId>cn.dev33</groupId>
|
||||
<artifactId>sa-token-spring-aop</artifactId>
|
||||
|
||||
@ -19,8 +19,8 @@ Sa-Token 在集群、分布式下的解决方案
|
||||
该如何选择一个合适的方案？
|
||||
- 方案一：性能消耗太大，不太考虑
|
||||
- 方案二：需要从网关处动手，与框架无关
|
||||
- 方案三：`sa-token`整合`Redis`非常简单，详见章节: [持久层扩展](use/dao-extend)
|
||||
- 方案四：详见官方仓库中`sa-token`整合`jwt`的示例
|
||||
- 方案三：Sa-Token 整合`Redis`非常简单，详见章节: [持久层扩展](use/dao-extend)
|
||||
- 方案四：详见官方仓库中 Sa-Token 整合`jwt`的示例
|
||||
|
||||
由于`jwt`模式不在服务端存储数据，对于比较复杂的业务可能会功能受限，因此更加推荐使用方案三
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@
|
||||
1. 使用`共享Cookie`来解决`token共享`问题
|
||||
2. 使用`Redis`来解决`Session共享`问题
|
||||
|
||||
在前面的章节我们已经了解了`sa-token`整合`Redis`的步骤，现在我们来讲一下如何在多个域名下共享Cookie。
|
||||
在前面的章节我们已经了解了`Sa-Token`整合`Redis`的步骤，现在我们来讲一下如何在多个域名下共享Cookie。
|
||||
|
||||
首先我们需要明确一点：根据`CORS策略`，在A域名下写入的Cookie，在B域名下是无法读取的，浏览器对跨域访问有着非常严格的限制 <br>
|
||||
|
||||
@ -37,7 +37,7 @@ OK，所有理论就绪，下面开始实战
|
||||
|
||||
### 集成步骤
|
||||
|
||||
sa-token整合同域下的单点登录非常简单，相比于正常的登录，你只需要在配置文件中增加配置 `sa-token.cookie-domain=xxx.com` 来指定一下Cookie写入时指定的父级域名即可，详细步骤示例如下：
|
||||
Sa-Token整合同域下的单点登录非常简单，相比于正常的登录，你只需要在配置文件中增加配置 `sa-token.cookie-domain=xxx.com` 来指定一下Cookie写入时指定的父级域名即可，详细步骤示例如下：
|
||||
|
||||
#### 1. 准备工作
|
||||
首先修改hosts文件(`C:\WINDOWS\system32\drivers\etc\hosts`)，添加以下IP映射，方便我们进行测试：
|
||||
|
||||
@ -3,12 +3,12 @@
|
||||
------
|
||||
|
||||
## Maven依赖
|
||||
在项目中直接通过 `pom.xml` 引入 `sa-token` 的依赖即可（四选一）：
|
||||
在项目中直接通过 `pom.xml` 引入 Sa-Token 的依赖即可（四选一）：
|
||||
|
||||
<!------------------------------ tabs:start ------------------------------>
|
||||
|
||||
<!-- tab:SpringMVC环境 （ServletAPI） -->
|
||||
如果你使用的框架基于 ServletAPI 构建（ `SpringMVC`、`SpringBoot`、`Zuul`等 ），请引入此包
|
||||
如果你使用的框架基于 ServletAPI 构建（ SpringMVC、SpringBoot、Zuul等 ），请引入此包
|
||||
``` xml
|
||||
<!-- Sa-Token 权限认证, 在线文档：http://sa-token.dev33.cn/ -->
|
||||
<dependency>
|
||||
@ -19,7 +19,7 @@
|
||||
```
|
||||
|
||||
<!-- tab:WebFlux环境 （Reactor） -->
|
||||
注：如果你使用的框架基于 Reactor 模型构建（`Netty`、`WebFlux`、`Soul`、`SC Gateway`等），请引入此包
|
||||
注：如果你使用的框架基于 Reactor 模型构建（Netty、WebFlux、Soul、SC Gateway等），请引入此包
|
||||
``` xml
|
||||
<!-- Sa-Token 权限认证（Reactor响应式集成）, 在线文档：http://sa-token.dev33.cn/ -->
|
||||
<dependency>
|
||||
@ -30,7 +30,7 @@
|
||||
```
|
||||
|
||||
<!-- tab:Servlet容器环境 -->
|
||||
注：如果你的项目没有使用Spring，但是Web框架是基于`ServletAPI`规范的，可以引入此包
|
||||
注：如果你的项目没有使用Spring，但是Web框架是基于 ServletAPI 规范的，可以引入此包
|
||||
``` xml
|
||||
<!-- Sa-Token 权限认证（ServletAPI规范）, 在线文档：http://sa-token.dev33.cn/ -->
|
||||
<dependency>
|
||||
@ -41,7 +41,7 @@
|
||||
```
|
||||
|
||||
<!-- tab:其它 -->
|
||||
注：如果你的项目既没有使用`SpringMVC`、`WebFlux`，也不是基于`ServletAPI`规范，那么可以引入`core`核心包
|
||||
注：如果你的项目既没有使用 SpringMVC、WebFlux，也不是基于 ServletAPI 规范，那么可以引入core核心包
|
||||
``` xml
|
||||
<!-- Sa-Token 权限认证（core核心包）, 在线文档：http://sa-token.dev33.cn/ -->
|
||||
<dependency>
|
||||
@ -78,8 +78,8 @@ implementation 'cn.dev33:sa-token-core:1.20.0'
|
||||
|
||||
## 获取源码
|
||||
如果你想深入了解Sa-Token，你可以通过`Gitee`或者`GitHub`来获取源码 （**学习测试请拉取master分支**，dev为正在开发的分支，有很多特性并不稳定）
|
||||
- Gitee地址：[https://gitee.com/dromara/sa-token](https://gitee.com/dromara/sa-token)
|
||||
- GitHub地址：[https://github.com/dromara/sa-token](https://github.com/dromara/sa-token)
|
||||
- **Gitee**地址：[https://gitee.com/dromara/sa-token](https://gitee.com/dromara/sa-token)
|
||||
- **GitHub**地址：[https://github.com/dromara/sa-token](https://github.com/dromara/sa-token)
|
||||
- 开源不易，求鼓励，给个`star`吧
|
||||
- 源码目录介绍:
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# SpringBoot 集成 Sa-Token 示例
|
||||
|
||||
本篇将带你从零开始集成sa-token，从而让你快速熟悉sa-token的使用姿势 <br>
|
||||
本篇将带你从零开始集成Sa-Token，从而让你快速熟悉Sa-Token的使用姿势 <br>
|
||||
整合示例在官方仓库的`/sa-token-demo/sa-token-demo-springboot`文件夹下，如遇到难点可结合源码进行测试学习
|
||||
|
||||
---
|
||||
@ -31,7 +31,7 @@ server:
|
||||
port: 8081
|
||||
|
||||
spring:
|
||||
# sa-token配置
|
||||
# Sa-Token配置
|
||||
sa-token:
|
||||
# token名称 (同时也是cookie名称)
|
||||
token-name: satoken
|
||||
@ -61,7 +61,7 @@ spring:
|
||||
public class SaTokenDemoApplication {
|
||||
public static void main(String[] args) throws JsonProcessingException {
|
||||
SpringApplication.run(SaTokenDemoApplication.class, args);
|
||||
System.out.println("启动成功：sa-token配置如下：" + SaManager.getConfig());
|
||||
System.out.println("启动成功：Sa-Token配置如下：" + SaManager.getConfig());
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -106,7 +106,7 @@ public class UserController {
|
||||
|
||||
|
||||
### 详细了解
|
||||
通过这个示例，你已经对sa-token有了初步的了解，那么现在开始详细了解一下它都有哪些 [能力](/use/login-auth) 吧
|
||||
通过这个示例，你已经对Sa-Token有了初步的了解，那么现在开始详细了解一下它都有哪些 [能力](/use/login-auth) 吧
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Spring WebFlux 集成 Sa-Token 示例
|
||||
|
||||
WebFlux基于Reactor响应式模型开发，有着与标准ServletAPI完全不同的底层架构，因此要适配WebFlux, 必须提供与Reactor相关的整合实现，
|
||||
本篇将以WebFlux为例，展示sa-token与Reactor响应式模型web框架相整合的示例, **你可以用同样方式去对接其它Reactor模型Web框架**(Netty、Soul、Gateway等)
|
||||
本篇将以WebFlux为例，展示Sa-Token与Reactor响应式模型web框架相整合的示例, **你可以用同样方式去对接其它Reactor模型Web框架**(Netty、Soul、Gateway等)
|
||||
|
||||
整合示例在官方仓库的`/sa-token-demo/sa-token-demo-webflux`文件夹下，如遇到难点可结合源码进行测试学习
|
||||
|
||||
@ -32,7 +32,7 @@ WebFlux基于Reactor响应式模型开发，有着与标准ServletAPI完全不
|
||||
public class SaTokenDemoApplication {
|
||||
public static void main(String[] args) throws JsonProcessingException {
|
||||
SpringApplication.run(SaTokenDemoApplication.class, args);
|
||||
System.out.println("启动成功：sa-token配置如下：" + SaManager.getConfig());
|
||||
System.out.println("启动成功：Sa-Token配置如下：" + SaManager.getConfig());
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -46,7 +46,7 @@ public class SaTokenDemoApplication {
|
||||
@Configuration
|
||||
public class SaTokenConfigure {
|
||||
/**
|
||||
* 注册 [sa-token全局过滤器]
|
||||
* 注册 [Sa-Token全局过滤器]
|
||||
*/
|
||||
@Bean
|
||||
public SaReactorFilter getSaReactorFilter() {
|
||||
|
||||
@ -6,12 +6,12 @@
|
||||
注解鉴权 —— 优雅的将鉴权与业务代码分离！
|
||||
|
||||
- `@SaCheckLogin`: 登录认证 —— 只有登录之后才能进入该方法
|
||||
- `@SaCheckRole("admin")`: 权限认证 —— 必须具有指定权限才能进入该方法
|
||||
- `@SaCheckPermission("user:add")`: 角色认证 —— 必须具有指定角色标识才能进入该方法
|
||||
- `@SaCheckRole("admin")`: 角色认证 —— 必须具有指定角色标识才能进入该方法
|
||||
- `@SaCheckPermission("user:add")`: 权限认证 —— 必须具有指定权限才能进入该方法
|
||||
- `@SaCheckSafe`: 二级认证校验 —— 必须二级认证之后才能进入该方法
|
||||
|
||||
Sa-Token使用全局拦截器完成注解鉴权功能，为了不为项目带来不必要的性能负担，拦截器默认处于关闭状态<br>
|
||||
因此，为了使用注解鉴权，你必须手动将sa-token的全局拦截器注册到你项目中
|
||||
因此，为了使用注解鉴权，你必须手动将Sa-Token的全局拦截器注册到你项目中
|
||||
|
||||
<!-- Sa-Token内置两种模式完成注解鉴权，分别是`拦截器模式`和`AOP模式`, 为了避免不必要的性能浪费，这两种模式默认都处于关闭状态 <br>
|
||||
因此如若使用注解鉴权，你必须选择其一进行注册 -->
|
||||
@ -23,7 +23,7 @@ Sa-Token使用全局拦截器完成注解鉴权功能，为了不为项目带来
|
||||
``` java
|
||||
@Configuration
|
||||
public class SaTokenConfigure implements WebMvcConfigurer {
|
||||
// 注册sa-token的注解拦截器，打开注解式鉴权功能
|
||||
// 注册Sa-Token的注解拦截器，打开注解式鉴权功能
|
||||
@Override
|
||||
public void addInterceptors(InterceptorRegistry registry) {
|
||||
// 注册注解拦截器，并排除不需要注解鉴权的接口地址 (与登录拦截器无关)
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# 框架配置
|
||||
你可以**零配置启动框架** <br>
|
||||
但同时你也可以通过配置，定制性使用框架，`sa-token`支持多种方式配置框架信息
|
||||
但同时你也可以通过配置，定制性使用框架，`Sa-Token`支持多种方式配置框架信息
|
||||
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
|
||||
``` java
|
||||
spring:
|
||||
# sa-token配置
|
||||
# Sa-Token配置
|
||||
sa-token:
|
||||
# token名称 (同时也是cookie名称)
|
||||
token-name: satoken
|
||||
@ -34,12 +34,12 @@ spring:
|
||||
### 方式2、通过代码配置
|
||||
``` java
|
||||
/**
|
||||
* sa-token代码方式进行配置
|
||||
* Sa-Token代码方式进行配置
|
||||
*/
|
||||
@Configuration
|
||||
public class SaTokenConfigure {
|
||||
|
||||
// 获取配置Bean (以代码的方式配置sa-token, 此配置会覆盖yml中的配置)
|
||||
// 获取配置Bean (以代码的方式配置Sa-Token, 此配置会覆盖yml中的配置)
|
||||
@Primary
|
||||
@Bean(name="SaTokenConfigure")
|
||||
public SaTokenConfig getSaTokenConfig() {
|
||||
|
||||
@ -47,7 +47,7 @@ Sa-token默认将会话数据保存在内存中，此模式读写速度最快，
|
||||
```
|
||||
|
||||
**2. 引入了依赖，我还需要为Redis配置连接信息吗？** <br>
|
||||
需要！只有项目初始化了正确的Redis实例，`sa-token`才可以使用Redis进行数据持久化，参考以下`yml配置`：
|
||||
需要！只有项目初始化了正确的Redis实例，`Sa-Token`才可以使用Redis进行数据持久化，参考以下`yml配置`：
|
||||
``` java
|
||||
# 端口
|
||||
spring:
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
|
||||
### 组件简述
|
||||
|
||||
之前的章节中，我们学习了“根据拦截器实现路由拦截鉴权”，其实在大多数web框架中，使用过滤器可以实现同样的功能，本章我们就利用sa-token全局过滤器来实现路由拦截器鉴权。
|
||||
之前的章节中，我们学习了“根据拦截器实现路由拦截鉴权”，其实在大多数web框架中，使用过滤器可以实现同样的功能，本章我们就利用Sa-Token全局过滤器来实现路由拦截器鉴权。
|
||||
|
||||
首先我们先梳理清楚一个问题，既然拦截器已经可以实现路由鉴权，为什么还要用过滤器再实现一遍呢？简而言之：
|
||||
1. 相比于拦截器，过滤器更加底层，执行时机更靠前，有利于防渗透扫描
|
||||
@ -19,7 +19,7 @@ Sa-Token同时提供过滤器和拦截器机制，不是为了让谁替代谁，
|
||||
|
||||
|
||||
### 注册过滤器
|
||||
同拦截器一样，为了避免不必要的性能浪费，sa-token全局过滤器默认处于关闭状态，若要使用过滤器组件，首先你需要注册它到项目中：
|
||||
同拦截器一样，为了避免不必要的性能浪费，Sa-Token全局过滤器默认处于关闭状态，若要使用过滤器组件，首先你需要注册它到项目中：
|
||||
``` java
|
||||
/**
|
||||
* [Sa-Token 权限认证] 配置类
|
||||
@ -29,7 +29,7 @@ Sa-Token同时提供过滤器和拦截器机制，不是为了让谁替代谁，
|
||||
public class SaTokenConfigure {
|
||||
|
||||
/**
|
||||
* 注册 [sa-token全局过滤器]
|
||||
* 注册 [Sa-Token全局过滤器]
|
||||
*/
|
||||
@Bean
|
||||
public SaServletFilter getSaServletFilter() {
|
||||
@ -40,7 +40,7 @@ public class SaTokenConfigure {
|
||||
|
||||
// 认证函数: 每次请求执行
|
||||
.setAuth(r -> {
|
||||
System.out.println("---------- 进入sa-token全局认证 -----------");
|
||||
System.out.println("---------- 进入Sa-Token全局认证 -----------");
|
||||
|
||||
// 登录验证 -- 拦截所有路由，并排除/user/doLogin 用于开放登录
|
||||
SaRouter.match("/**", "/user/doLogin", () -> StpUtil.checkLogin());
|
||||
@ -50,7 +50,7 @@ public class SaTokenConfigure {
|
||||
|
||||
// 异常处理函数：每次认证函数发生异常时执行此函数
|
||||
.setError(e -> {
|
||||
System.out.println("---------- 进入sa-token异常处理 -----------");
|
||||
System.out.println("---------- 进入Sa-Token异常处理 -----------");
|
||||
return AjaxJson.getError(e.getMessage());
|
||||
})
|
||||
|
||||
@ -92,7 +92,7 @@ public class SaTokenConfigure {
|
||||
public class SaTokenConfigure {
|
||||
|
||||
/**
|
||||
* 注册 [sa-token全局过滤器]
|
||||
* 注册 [Sa-Token全局过滤器]
|
||||
*/
|
||||
@Bean
|
||||
public SaReactorFilter getSaReactorFilter() {
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
|
||||
### 获取当前账号权限码集合
|
||||
因为每个项目的需求不同，其权限设计也千变万化，因此【获取当前账号权限码集合】这一操作不可能内置到框架中，
|
||||
所以`sa-token`将此操作以接口的方式暴露给你，以方便的你根据自己的业务逻辑进行重写
|
||||
所以`Sa-Token`将此操作以接口的方式暴露给你，以方便的你根据自己的业务逻辑进行重写
|
||||
|
||||
你需要做的就是新建一个类，实现`StpInterface`接口，例如以下代码：
|
||||
|
||||
@ -31,7 +31,7 @@ import cn.dev33.satoken.stp.StpInterface;
|
||||
/**
|
||||
* 自定义权限验证接口扩展
|
||||
*/
|
||||
@Component // 保证此类被SpringBoot扫描，完成sa-token的自定义权限验证扩展
|
||||
@Component // 保证此类被SpringBoot扫描，完成Sa-Token的自定义权限验证扩展
|
||||
public class StpInterfaceImpl implements StpInterface {
|
||||
|
||||
/**
|
||||
@ -92,7 +92,7 @@ StpUtil.checkPermissionOr("user-update", "user-delete");
|
||||
|
||||
|
||||
### 角色认证
|
||||
在sa-token中，角色和权限可以独立验证
|
||||
在Sa-Token中，角色和权限可以独立验证
|
||||
|
||||
``` java
|
||||
// 当前账号是否含有指定角色标识, 返回true或false
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
有的时候，我们会在一个项目中设计两套账号体系，比如一个电商系统的 `user表` 和 `admin表`<br>
|
||||
在这种场景下，如果两套账号我们都使用 `StpUtil` 类的API进行登录鉴权，那么势必会发生逻辑冲突
|
||||
|
||||
在sa-token中，这个问题的模型叫做：多账号体系验证 <br>
|
||||
在Sa-Token中，这个问题的模型叫做：多账号体系验证 <br>
|
||||
要解决这个问题，我们必须有一个合理的机制将这两套账号的授权给区分开，让它们互不干扰才行
|
||||
|
||||
|
||||
@ -76,14 +76,21 @@ public String info() {
|
||||
很简单，我们只要更改一下 `StpUserUtil` 的 `TokenName` 即可，参考示例如下：
|
||||
|
||||
``` java
|
||||
// 底层的 StpLogic 对象
|
||||
public static StpLogic stpLogic = new StpLogic("user") {
|
||||
// 重写 StpLogic 类下的 `splicingKeyTokenName` 函数，返回一个与 `StpUtil` 不同的token名称, 防止冲突
|
||||
@Override
|
||||
public String splicingKeyTokenName() {
|
||||
return super.splicingKeyTokenName() + "-user";
|
||||
}
|
||||
};
|
||||
public class StpUserUtil {
|
||||
|
||||
// 使用匿名子类 重写`stpLogic对象`的一些方法
|
||||
public static StpLogic stpLogic = new StpLogic("user") {
|
||||
// 重写 StpLogic 类下的 `splicingKeyTokenName` 函数，返回一个与 `StpUtil` 不同的token名称, 防止冲突
|
||||
@Override
|
||||
public String splicingKeyTokenName() {
|
||||
return super.splicingKeyTokenName() + "-user";
|
||||
}
|
||||
// 同理你可以按需重写一些其它方法 ...
|
||||
};
|
||||
|
||||
// ...
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
再次调用 `StpUserUtil.login(10001)` 进行登录授权时，token的名称将不再是 `satoken`，而是我们重写后的 `satoken-user`
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
以上介绍的api都是操作当前账号，对当前账号进行各种鉴权操作，你可能会问，我能不能对别的账号进行一些操作？<br>
|
||||
比如：查看账号`10001`有无某个权限码、获取id账号为`10002`的用户`User-Session`，等等...
|
||||
|
||||
sa-token在api设计时充分考虑了这一点，暴露出多个api进行此类操作
|
||||
Sa-Token在api设计时充分考虑了这一点，暴露出多个api进行此类操作
|
||||
|
||||
|
||||
## 有关操作其它账号的api
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
|
||||
## 具体API
|
||||
|
||||
在`sa-token`中如何做到同端互斥登录? <br/>
|
||||
在`Sa-Token`中如何做到同端互斥登录? <br/>
|
||||
首先在配置文件中，将 `isConcurrent` 配置为false，然后调用登录等相关接口时声明设备标识即可：
|
||||
|
||||
|
||||
|
||||
@ -76,7 +76,7 @@ uni.request({
|
||||
});
|
||||
```
|
||||
|
||||
4. 只要按照如此方法将`token`值传递到后端，`sa-token`就能像传统PC端一样自动读取到`token`值，进行鉴权
|
||||
4. 只要按照如此方法将`token`值传递到后端，`Sa-Token`就能像传统PC端一样自动读取到`token`值，进行鉴权
|
||||
5. 你可能会有疑问，难道我每个`ajax`都要写这么一坨？岂不是麻烦死了
|
||||
- 你当然不能每个`ajax`都写这么一坨，因为这种重复代码都是要封装在一个函数里统一调用的
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# 密码加密
|
||||
|
||||
严格来讲，密码加密不属于 [权限认证] 的范畴，但是对于大多数系统来讲，密码加密又是安全认证不可或缺的部分，
|
||||
所以，应大家要求，`sa-token`在`v1.14版本`添加密码加密模块，该模块非常简单，仅仅封装了一些常见的加密算法
|
||||
所以，应大家要求，`Sa-Token`在`v1.14版本`添加密码加密模块，该模块非常简单，仅仅封装了一些常见的加密算法
|
||||
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ AES加密
|
||||
``` java
|
||||
// 定义秘钥和明文
|
||||
String key = "123456";
|
||||
String text = "sa-token 一个轻量级java权限认证框架";
|
||||
String text = "Sa-Token 一个轻量级java权限认证框架";
|
||||
|
||||
// 加密
|
||||
String ciphertext = SaSecureUtil.aesEncrypt(key, text);
|
||||
@ -47,7 +47,7 @@ String privateKey = "MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAO+wmt01pwm
|
||||
String publicKey = "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDvsJrdNacJvZRzHauwPIJBIoJNFyjH47/uCIwBYVgkok3j+3bZZ3HhSW5Fsb23O0KN3wjqcJn3LJMFHN1UoMoiZDSQ7PYrz275bfCFNm2fjwQ8WMUgiRa4KLlTqQK/Gq/2+oDbmE4tb7dxZBrUowAhW9NNv+vESlE8nvP7XXFYpQIDAQAB";
|
||||
|
||||
// 文本
|
||||
String text = "sa-token 一个轻量级java权限认证框架";
|
||||
String text = "Sa-Token 一个轻量级java权限认证框架";
|
||||
|
||||
// 使用公钥加密
|
||||
String ciphertext = SaSecureUtil.rsaEncryptByPublic(publicKey, text);
|
||||
@ -68,7 +68,7 @@ System.out.println(SaSecureUtil.rsaGenerateKeyPair());
|
||||
### Base64编码与解码
|
||||
``` java
|
||||
// 文本
|
||||
String text = "sa-token 一个轻量级java权限认证框架";
|
||||
String text = "Sa-Token 一个轻量级java权限认证框架";
|
||||
|
||||
// 使用Base64编码
|
||||
String base64Text = SaBase64Util.encode(text);
|
||||
|
||||
@ -5,19 +5,19 @@
|
||||
|
||||
|
||||
|
||||
那么在sa-token中，如何做到 [ 记住我 ] 功能呢？
|
||||
那么在Sa-Token中，如何做到 [ 记住我 ] 功能呢？
|
||||
|
||||
|
||||
### 在sa-token中实现记住我功能
|
||||
|
||||
sa-token的登录授权，**默认就是`[记住我]`模式**，为了实现`[非记住我]`模式, 你需要在登录时如下设置：
|
||||
Sa-Token的登录授权，**默认就是`[记住我]`模式**，为了实现`[非记住我]`模式, 你需要在登录时如下设置：
|
||||
|
||||
``` java
|
||||
// 设置登录账号id为10001，第二个参数指定是否为[记住我]，当此值为false后，关闭浏览器后再次打开需要重新登录
|
||||
StpUtil.login(10001, false);
|
||||
```
|
||||
|
||||
那么，sa-token实现`[记住我]`的具体原理是？
|
||||
那么，Sa-Token实现`[记住我]`的具体原理是？
|
||||
|
||||
|
||||
### 实现原理
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
> 项目中所有接口均需要登录验证，只有'登录接口'本身对外开放
|
||||
|
||||
我们怎么实现呢？给每个接口加上鉴权注解？手写全局拦截器？似乎都不是非常方便。<br/>
|
||||
在这个需求中我们真正需要的是一种基于路由拦截的鉴权模式, 那么在sa-token怎么实现路由拦截鉴权呢？
|
||||
在这个需求中我们真正需要的是一种基于路由拦截的鉴权模式, 那么在Sa-Token怎么实现路由拦截鉴权呢？
|
||||
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
``` java
|
||||
@Configuration
|
||||
public class SaTokenConfigure implements WebMvcConfigurer {
|
||||
// 注册sa-token的登录拦截器
|
||||
// 注册Sa-Token的登录拦截器
|
||||
@Override
|
||||
public void addInterceptors(InterceptorRegistry registry) {
|
||||
// 注册登录拦截器，并排除登录接口或其他可匿名访问的接口地址 (与注解拦截器无关)
|
||||
@ -54,7 +54,7 @@ public class SaTokenConfigure implements WebMvcConfigurer {
|
||||
``` java
|
||||
@Configuration
|
||||
public class SaTokenConfigure implements WebMvcConfigurer {
|
||||
// 注册sa-token的拦截器
|
||||
// 注册Sa-Token的拦截器
|
||||
@Override
|
||||
public void addInterceptors(InterceptorRegistry registry) {
|
||||
// 注册路由拦截器，自定义验证规则
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# 会话治理
|
||||
|
||||
尽管框架将大部分操作提供了简易的封装，但在一些特殊场景下，我们仍需要绕过框架，直达数据底层进行一些操作 <br>
|
||||
sa-token提供以下API助你直接操作会话列表
|
||||
Sa-Token提供以下API助你直接操作会话列表
|
||||
|
||||
|
||||
---
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
### Session是什么？
|
||||
|
||||
Session是会话中专业的数据缓存组件，通过`Session`我们可以很方便的缓存一些高频读写数据，提高程序性能<br>
|
||||
在`sa-token`中, `Session` 分为三种, 分别是：
|
||||
在`Sa-Token`中, `Session` 分为三种, 分别是：
|
||||
- `User-Session`: 指的是框架为每个`loginId`分配的`Session`
|
||||
- `Token-Session`: 指的是框架为每个`token`分配的`Session`
|
||||
- `自定义Session`: 指的是以一个`特定的值`作为SessionId，来分配的`Session`
|
||||
@ -105,7 +105,7 @@ session.logout();
|
||||
|
||||
### 类型转换API
|
||||
由于Session存取值默认的类型都是Object，因此我们通常会写很多不必要类型转换代码 <br>
|
||||
为了简化操作，sa-token自`v1.15.0`封装了存取值API的类型转换，你可以非常方便的调用以下方法：
|
||||
为了简化操作，Sa-Token自`v1.15.0`封装了存取值API的类型转换，你可以非常方便的调用以下方法：
|
||||
``` java
|
||||
// 写值
|
||||
session.set("name", "zhang");
|
||||
@ -158,5 +158,5 @@ public void reset(HttpSession session) {
|
||||
```
|
||||
**要点：**
|
||||
1. `SaSession` 与 `HttpSession` 没有任何关系，在`HttpSession`上写入的值，在`SaSession`中无法取出
|
||||
2. `HttpSession`并未被框架接管，在使用sa-token时，请在任何情况下均使用`SaSession`，不要使用`HttpSession`
|
||||
2. `HttpSession`并未被框架接管，在使用Sa-Token时，请在任何情况下均使用`SaSession`，不要使用`HttpSession`
|
||||
|
||||
|
||||
@ -15,13 +15,13 @@
|
||||
为此，我们需要在yml中添加如下配置：
|
||||
``` java
|
||||
spring:
|
||||
# sa-token配置
|
||||
# Sa-Token配置
|
||||
sa-token:
|
||||
# token前缀
|
||||
tokenPrefix: Bearer
|
||||
```
|
||||
|
||||
此时 sa-token 便可在读取token时裁剪掉 `Bearer`，成功获取`xxxx-xxxx-xxxx-xxxx`
|
||||
此时 Sa-Token 便可在读取token时裁剪掉 `Bearer`，成功获取`xxxx-xxxx-xxxx-xxxx`
|
||||
|
||||
|
||||
### 注意点
|
||||
|
||||
@ -49,7 +49,7 @@ import org.springframework.stereotype.Component;
|
||||
import cn.dev33.satoken.action.SaTokenActionDefaultImpl;
|
||||
|
||||
/**
|
||||
* 继承sa-token行为Bean默认实现, 重写部分逻辑
|
||||
* 继承Sa-Token行为Bean默认实现, 重写部分逻辑
|
||||
*/
|
||||
@Component
|
||||
public class MySaTokenAction extends SaTokenActionDefaultImpl {
|
||||
@ -90,7 +90,7 @@ import cn.dev33.satoken.action.SaTokenActionDefaultImpl;
|
||||
import cn.hutool.core.util.IdUtil;
|
||||
|
||||
/**
|
||||
* 继承sa-token行为Bean默认实现, 重写部分逻辑
|
||||
* 继承Sa-Token行为Bean默认实现, 重写部分逻辑
|
||||
*/
|
||||
@Component
|
||||
public class MySaTokenAction extends SaTokenActionDefaultImpl {
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
<html lang="zh">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>sa-token</title>
|
||||
<title>Sa-Token</title>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
|
||||
<meta name="description" content="sa-token是一个java权限认证框架，功能全面，上手简单，登录验证、权限验证、Session会话、踢人下线、账号封禁、集成Redis、前后台分离、分布式会话、微服务网关鉴权、单点登录、临时Token验证、记住我模式、模拟他人账号、临时身份切换、多账号体系、注解式鉴权、路由拦截式鉴权、花式token、自动续签、同端互斥登录、会话治理、密码加密、jwt集成、Spring集成、WebFlux集成...，有了sa-token，你所有的权限认证问题，都不再是问题">
|
||||
<meta name="keywords" content="sa-token,sa-token框架,sa-token文档,java权限认证">
|
||||
@ -176,7 +176,7 @@
|
||||
<p>提供SpringMVC、WebFlux、Solon等常见web框架的starter集成包，真正的开箱即用</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="re-text">有了sa-token，你所有的权限认证问题，都不再是问题！</div>
|
||||
<div class="re-text">有了Sa-Token，你所有的权限认证问题，都不再是问题！</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@ -339,7 +339,7 @@
|
||||
</style>
|
||||
<div class="foot-box" id="foot">
|
||||
<div class="s-width" style="text-align: center;">
|
||||
Copyright ©2021 sa-token java权限认证 | sa-token.dev33.cn | <a href="https://beian.miit.gov.cn/" target="_blank">鲁ICP备18046274号-2</a>
|
||||
Copyright ©2021 Sa-Token java权限认证 | sa-token.dev33.cn | <a href="https://beian.miit.gov.cn/" target="_blank">鲁ICP备18046274号-2</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user