SpringSecurity框架教程-Spring Security+JWT实现项目级前端分离认证授权-挑战黑马&尚硅谷

超哥哥go:
学习技术有个好老师或者好文章真的很重要，第一次在技术视频下留评论。平时我也写一些技术博客，深有体会，UP主能将这们知识讲的这么清晰流畅，不光是技术牛逼，也看的出来为了录课真的是花费了很大的心思（ps：SpringSecurity这个知识我扒过很多博客也看过源码，感觉都云里雾里），这里必须三连加充电去支持[打call][打call][打call]

【回复】感谢支持，这课想讲清楚的确是最费心力的[大哭]
【回复】回复 @酒巷懒猫多 : 这个很适合入门，动力节点那个也可以看 新版的
【回复】回复 @三更草堂 :希望up主后面SpringSecurity源码 以及社交登录补上呗[滑稽]
三更草堂:
课程已经录制完了。课程资料可以加群领取。关注up后会自动回复qq群号

【回复】回复 @蓝天1白云 :看下群公告
【回复】老师，加了好几次群了，请通过下，谢谢
三更草堂:
核心内容都已经录制完了，后面的内容会加紧录制。课程资料可以加群领取。关注up后会自动回复qq群号

【回复】回复 @dongjela :啥青橙小站？
【回复】我去 在青橙小站买的资料不全啊
经历网:
一直在找 springCloud 、网关 与 spring security 、前端整合的教程 那些 CV 的教程实在看不懂，也没教刷新令牌的。

三更草堂:
课程已经录制完了。课程资料可以加群领取。关注up后会自动回复qq群号。

【回复】另外最近在构思录制个SpringSecurity Oauth2.0的付费视频。考虑拿实际企业里的认证中心脱敏后用来讲解。无论是工作中需要开发需要还是用来增加简历面试亮点都会很有帮助。 有需要的可以留意下。
【回复】回复 @三更草堂 :务必拉我
蜀州郭富城:
给后来人的小建议： 可能有些小伙伴只看文档没看视频，有几个地方我猜的坑说一下， 1.关于redis和jwt同时使用问题，redis可用可不用，看你自己，如果你生成的jwt没有设置过期时间，你可以通过redis控制一下。 2.关于认证过程中抛出的某些异常 例如：if (Objects.isNull(authenticate)){ throw new RuntimeException("用户名或密码错误！"); }，这个是无效的，他过滤器里面的异常处理器捕获了，不会抛出，可以在后面的自定义异常处理器中获取出来返给前端，最好不要写死，authException.getMessage() 这样就行； 3.关于写完了权限认证的都是403未认证： 可能很多朋友没看视频，看得文档，注意文档里面的jwttoken过滤器里面new UsernamePasswordAuthenticationToken(loginUser, null, loginUser.getAuthorities());第三个参数是null，一定要把loginUser.getAuthorities()传进去

【回复】还没看[doge]，你字多，先给你点个赞[脱单doge]
【回复】我说异常咋抛不出来，原来是这样，谢谢
【回复】回复 @大手dd :这个up不是说了吗[妙啊]
年轻人你慌啥:
关于存储redis中的数据我有几句想说的 1、严格来说，使用jwt是不用redis的，因为jwt初衷就是为了无状态，你加上redis，就违背了初衷，这也是网上对jwt最为诟病的一个地方。 2、使用redis并不是为了减轻数据库的压力，因为jwt本身是可以在payload中放入一些用户基本信息的，在前端携带token访问时，对token进行解析，可以获取到这些数据并写入SecurityContextHolder当中，这样在后面的处理当中，都可以获取到当前用户的相关信息。 3、由于jwt的无状态，后端是没法感知和控制用户的在线状态的，所以加入了redis这一层，在校验token的同时检查redis相关状态从而实现后端对用户状态的控制。 4、所以对于无状态应用，jwt是再好不过的一个东西，但是对于我们常见的有状态应用，使用一个uuid也是能达到相同的效果的。

【回复】回复 @格林尼治鼠 :看了你楼下的关于权限存放问题的说明,我觉得放在redis挺好的,修改了权限信息就需要重新生成token,而存在了redis里面完美解耦合.而且如果项目部署多台实例还可以实现分布式校验.
【回复】JWT在实际应用中也是用在oahth2上，在会话管理上并不合适，spring security提出的cookie+session+spring session redis一整套方案，综合下来还是最优解，使用jwt维持会话需要自己实现session那种自动续期的流程，得不偿失，失去了使用这种技术本该拥有的便利，按up主这种设计，这里边还涉及到不少filter无效配置的情况，如securityContextHolderFilter/requestcache等，假如在未登录时访问购物车，登录后重定向到上一次请求，这种操作因为只返回token而不得已得让前端完成重定向，不然token得放入cookie中这又会导致csrf攻击，好家伙，走了一圈回到了原地。
【回复】我也觉得这个redis用的完全没什么意义，用户id和用户名还有权限放在jwt里传输就行了，又不是什么机密的东西。
即将拥有人鱼线的熊某:
if(Objects.isNull(authenticate)){ throw new RuntimeException("用户名或密码错误"); } 跟着你一样的代码，这一步debug 然后postman写了那个json之后根本就进不了这一步，而且正常完成代码之后一直都是403 forbidden

【回复】你这个的上一句话Authentication authenticate = authenticationManager. authenticate(usernamePasswordAuthenticationToken); 里面进行了密码错误异常的捕捉 所以如果密码错了的话 直接在里面就结束了 所以就不会进下面
一阵黄粱罢也:
我也一个疑问就是权限放到JWT中，如果管理员把某个用户得权限修改了，但是由于该用户得token没过期，放在前端本地，用户的权限没有变还是修改之前的；这时只能让用户重新登录吗？还是去查数据库或者缓存，但是每次去查数据库对数据库压力太大了吧，我现在就是想有没有在管理员修改用户权限后，让用户token失效，然后通过一个刷新token让用户重新获取新的权限（管理员修改过的），这样用户也不用重新登录了，无感知，用户体验也好很好，不知道这种方案可行吗？或者各位有更好的见解能说说看嘛

【回复】假设你的jwt就存了用户id，那么每次生成的token不变的情况下，可以在项目启动的时候把用户和用户角色和菜单权限加入redis缓存（是具体的数据库记录），在过滤器中通过token去拿redis中的用户id，再通过用户id拿redis中的菜单权限，再封装一次。这里的关键就在于，启动的时候能够把和权限有关的表记录刷入redis，再分配权限的时候刷新redis，这样就做到了jwt token和实际权限的分离
【回复】管理员修改用户权限应该会更新redis里面的用户权限吧，然后用户发起新的访问 还是会通过jwt获取用户数据，这时候的数据应该是已经修改后的吧。
【回复】回复 @你我之间啊 :对头,修改之后,会从新存储数据,更新用户信息和权限,在重新返还给前端,前端接收后移除之前的token,再把得到的重新放入localStorage中,此时登录状态是依然存在的
叫我小徐就行啦:
老哥讲的很好，看了很多喷你的大多是小号，感觉要么是竞争对手，要么就是些半瓶水，老哥有则改之无则加勉，别被打击。我是今年应届，现在在上海工作，看了你的视频真的学到很多，十分感谢！继续加油！

【回复】回复 @叫我小徐就行啦 :感谢支持，我心态很好的，有自信也非常愿意听取客观的意见。我就是想着有则改之，无则加勉的。无脑喷的我也不会放在心上。
【回复】回复 @三更草堂 :看了一些，老哥是模仿若依的呀哈哈哈
【回复】回复 @叫我小徐就行啦 :其实认证授权写法很多，我不可能全讲一遍。应该是通过一种方案的讲解来理解Security。然后若依这种方案也是我再公司里用的比较多的，而且是最容易理解的，所以就讲了这种。其它的方案我在最后的视频里其实也有提到。正常如果是理解了Security的流程，其它方案也都能想通如何去实现。重点是理解Security的流程。
宇宙机信徒:
到目前为止讲得最好的SpringSecurity入门教程

【回复】回复 @芽衣芽衣俺牙疼 : 不良人讲的也很棒，特别是源码部分。但是小白容易被劝退[喜极而泣]，个人觉得学习技术就是应该先会用了，再了解原理。上来源码debug调试大概率直接懵逼，源码这些东西别人带着过3遍不如自己过1遍
【回复】我觉得 编程不良人 讲的好点。。这个up的我都看了
【回复】老哥，你有笔记吗？能私发一份吗？
润物之音:
之前看了几个视频没理解的，终于在个课程中明白了[鼓掌]

【回复】回复 @a1225987248 : 老哥，能在发一下资源吗
【回复】回复 @a1225987248 : 老哥，有这个文件的资料吗？
野外生活3:
课代表来了哦✨✨✨ SpringSecurity框架教程-Spring Security+JWT实现项目级前端分离认证授权-B站最通俗易懂的Spring ...

不爱穿裤子的小红娘:
以本视频为题,我来说一下403问题 1.检查数据库存储的密码是否通过PasswordEncoder对象加密存储的,如果不是请调用 passwordEncoder.encode("123"); 2.检查SecurityConfig配置类是否放行了登录链接 http.authorizeRequests().antMatchers("/login/user").anonymous(); 3.请以post的请求方式并且请求头加上Content-Type=application/json的方式发送JSON格式{"userName": "xjr", "password": "123" } 4.希望点赞

【回复】这三个都没问题还是403这是为啥呢
【回复】回复 @三石珏 : 兄弟，解决没有
【回复】回复 @三石珏 : 咋解决呀兄弟
挺萌的翔:
如果有小伙伴同样使用的是java9，在jwt创建token的时候可能会遇到javax.xml.bind.DatatypeConverter的错误。 这是由于JAXB API是java EE 的API，因此在java SE 9.0 中不再包含这个 Jar 包。 java 9 中引入了模块的概念，默认情况下，Java SE中将不再包含java EE 的Jar包而在 java 6/7 / 8 时关于这个API 都是捆绑在一起的。 解决方法： 导入依赖 <dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.0</version> </dependency> --方法转自CSDN

【回复】回复 @咕咕咕_zzz : 但是在项目运行时才会报错, 在单元测试中不会报错
【回复】我用jdk8也遇到了这个问题 很奇怪
烟草味的桔子:
老师讲解的很好，但是在redis中的LoginUser对象的key值最好不要用userId，这会照成用户退出后，旧的token还可以继续使用的问题，有一定安全隐患。 这里我推荐使用uuid作为key值（uuid每次登录生成都会不相同），用户访问登录接口成功时生成uuid加密为token响应回去，并且将uuid作为LoginUser在redis中的key存入缓存，此后每次访问获取token使用jwt解码为redis中的key，根据key查找LoginUser的信息。 同时为了防止用户不正常退出，导致每次访问时产生新的缓存（旧的用户信息缓存堆积），需要设置缓存的过期时间，并且每次访问时都去更新缓存过期时间

【回复】其实key可以继续用userid，在存储的用户信息后面多存个token，在过滤器里校验的时候把存redis里的token提出来然后跟请求的token做比较，如果不同说明该用户在别的地方登录过，或者redis过期了的话也直接无法登录了。然后登录的时候记得根据userid删除对应key的条目再重新新建，这样可以保证里面存的token是最新的，还有在过滤器增加更新redis条目过期时间的语句
【回复】那我退出的时候删除redis里面的用户信息时怎么获取uuid作为删除redis里的用户信息key
巴黎雨季rainy:
之前尚硅谷看的比较多，偶然发现这个教程，看完了，客观评价一句，确实是很好的入门教程，原理也够细致，挑战成功，希望后续能出更多更好的教程，感谢up!

笑太苦:
刚开始看这个Security看不懂，很复杂，但是反复进行一个学习每次看都会有不同的收获，并且三更老师讲的是我见的最细，废话最少的老师，每次都讲到这个怎么进行运行，不行就dbug让你看看怎么进行一个运行流程，怎么进行一个运行，里面有什么返回值等等，我发现其他老师要不然就教你这么用，会用就行，你连为什么这样，为什么这样写都不知道所以三更老师对我来说他更负责，并且看到认证权限那个地方，他把认证的几种方式都讲到了，处处讲到精髓！！！

318197375:
你好, 我觉得你对 JWT 的理解是有偏差的, JWT 设计之初, 就是为了解决后端服务器频繁查库的问题, 因此, JWT是无状态的, 即: 当用户从拿到JWT到JWT过期为止, JWT本身携带的信息使得多数请求可以无需查询数据库(比如鉴权, JWT 自带用户的基础信息和权限信息, 此时不需要去查缓存或是数据库). 如果使用UP设计的方案的话, 其实和传统的方案一致, 只要是登录时向前端返回一个可以查到Redis中存储的用户信息的令牌即可, 这时使用JWT并没有意义. JWT是与后端服务器无耦合的, 所以其在分布式架构下也可以使用, 而传统架构, 用户登录数据的同步也是个问题. 当然JWT也是有缺陷的, 需要斟酌使用, 比如JWT的无状态导致了后端无法强制JWT失效, 用户权限的更新不及时等等问题

【回复】回复 @daylylmn :你好，将注销但未过期jwt存redis的确是用户注销功能的实现，可问题是都要同步数据，为什么不选择另外的鉴权Token，而是用jwt呢？
【回复】回复 @daylylmn : 双token方案，举个例子，一个有效期为5分钟的access_token和一个有效期为15天的refresh_token，持有acess_token的时候无需去DB/redis中校验。当access_token过期的时候，需要持有记录在DB/redis中的refresh_token才可以生成新access_token。（DB/reids中不存储整个jwt，而是哈希值）然后当refresh_token不足x天的时候，在后端中生成新的refresh_token并且更新对应的记录即可。 这样既可以享受jwt的优势（避免频繁查库），也可以有效管理jwt状态（比如更改密码时可以强制所有设备下线）
【回复】回复 @318197375 :你好，不是jwt直接存redis，是jwt解析出来的类似uuid的东西存redis，value就是登陆对象，可以包含用户的一些基本信息加上权限等。要不然权限这些都包在jwt中，这也太大了。