学springsecurity的时候有几个问题想不通，
1:既然userdetails和principle包含的信息都差不多 get得到的东西也一样，为什么还在authentacation对象里分出来这两个结构？
2:securitycontextholder是在哪个过滤器执行后才保存有当前登录用户的认证授权信息？
3:jwt用双token机制的话是怎么设置区分这两个token的key，setHeader还是setHeaderParam？
4:这两个token在redis里用什么结构存储，是存到哈希表还是就简单设两个带有效期的string减值对？还有这两个token在userDetailsService里的方法里还是在loginSuccessHander里创建并存储比较好？
5:很多帖子都讲要防xss攻击的话要配置htmlescape过滤器，直接在所有的vo上配置valited注解不也一样吗？并且注解方式还更灵活

还有tm的若依这些框架为什么喜欢把用户角色权限的五张表结构改成用户角色访问路径请求方式请求ip用户岗位之类的十几张表的结构啊，有几个公司能大到使用那么复杂的表，还有访问日志记录到数据库里不更增加数据库负担和风险，日志放到redis或者Mongo不好吗？就算要分后台管理和用户两类人群直接分两个项目开发不就好了，莫名其妙的还在iputil里加个innerIP，并不是所有人都喜欢服务器上云，就算上云也是有风险的。

1 userdetails是principal的一个实现，不一定非得是userdetails
2. 这个没有固定答案，如果你还没登陆，并且用springsecurity自带的登录那UsernamePasswordAuth**Filter会认证并设置授权信息，但如果你已经登陆，那就是SecurityContextHolderFilter会从session里取你的授权信息
34据我了解refreshToken不用jwt，随便随机生成然后存string键值对redis就行，accessToken才是jwt不需要存redis。
5我不知道
框架肯定用会给最通用成熟且规范的方案，spring就提供了LDAP和传统SQL数据库两种最通用的方案。而NoSQL虽然用得不少但行业内根本没有靠谱的规范，还不配跟跟那俩相比。

不懂就问chatgpt，程序员基本能力了

不会，问gpt

userdetail是spring的不假，principal可不是spring的吧

若依这个表权限管理只能说正常，能满足一般的实际业务需求，该有的有，日志那一块看实际业务吧

UserDetails和Principal包含的信息确实有些重复，但它们的作用不同。UserDetails是Spring Security用于表示用户的接口，包含了用户的基本信息和权限信息。Principal是Java Security中的概念，表示当前执行操作的主体，可以是用户、服务等。Authentication对象将这两个结构分开是为了更好地区分用户的身份和权限信息。
SecurityContextHolder是在SecurityContextPersistenceFilter过滤器执行后保存当前登录用户的认证授权信息。该过滤器负责从持久化存储中加载SecurityContext，并将其存储在SecurityContextHolder中，以便在整个请求处理过程中访问。
JWT使用双token机制时，一般使用两个不同的key来区分这两个token。通常，用于验证身份的token（access token）会放在请求的Header中，使用setHeader方法设置；用于刷新token的token（refresh token）可以放在请求的Header或者Header参数中，使用setHeaderParam方法设置。
在Redis中存储这两个token可以选择不同的数据结构。一种常见的做法是使用哈希表，将access token和refresh token分别存储在不同的字段中。另一种简单的做法是将这两个token作为带有有效期的字符串存储，可以分别存储在不同的key中。至于在哪里创建和存储这两个token，可以根据具体的业务需求来决定。一般来说，可以在登录成功后的处理器（LoginSuccessHandler）中创建并存储这两个token。
配置HtmlEscape过滤器是一种防止XSS攻击的常见做法，它可以自动对请求参数进行HTML转义，防止恶意脚本注入。在所有的VO上配置@Validated注解确实也可以实现类似的效果，但是这种方式需要在每个VO上都进行配置，比较繁琐。而配置HtmlEscape过滤器可以统一处理所有的请求参数，更加方便。另外，注解方式更适合对请求参数进行校验和验证，而不是防止XSS攻击。因此，建议同时使用HtmlEscape过滤器和注解方式来提高安全性。

我补充一下访问权限的几个问题：
1、RBAC 5 张表的结构只是基础模型，真正有权限需求的必然比它复杂，但也是依据这个模型的变种。（也就是说你能看到的系统基本都只是demo级别的项目）
2、架构设计中很重要的原则是遵循“剃刀原理”，多参与设计就知道了，多增加一个外部实体会让程序复杂度递增

之前学springsecurity学的津津有味，现在全忘记了，真不知道搞一个认证这么麻烦干嘛，授权还不错

别折腾了，不是公司要求的话，自己写过滤器拦截器apo反射注解一套下来，啥玩意搞不下来
硬上框架，后面就会出现存储jwt这种蠢事

springsecurity没啥用，自己写的比他灵活多了

没听说过有人把日志放redis的，您是一点实际经验都没有吗

satoken怎么样

之前学的spring security几乎快忘光了，这个框架太重了而且不灵活