LightSecurity是一个基于 jwt 的权限控制框架，支持与 SprigBoot 配合使用。
特点优点上手快速开箱即用轻量级，代码精简，不到500行代码；功能实用，市面上安全框架常用能力与套路均已具备：支持 RESTful 权限控制支持灵活的权限配置(代码配置方式优先级更高)支持基于配置文件的权限配置支持基于代码的权限控制支持基于注解的权限控制设计简单，没有复杂概念；基于权限配置的方式：核心是1个拦截器基于注解的权限控制：核心是1个切面缺点功能比SprigSecurity、ApacheShiro弱；只考虑权限相关问题不考虑身份认证(登录)，意味着登录逻辑得自己玩；不考虑安全，意味着网络攻击得自己防；目前与SprigMVC强绑定，暂不支持WebFlux或其他框架。依赖SprigMVC：用到SprigMVC的拦截器；SprigAOP：如果不用基于注解的权限控制，则无需该部分依赖；jwt：你懂的快速上手TIPS
快速上手可详见项目 light-security-example 目录，内附详细测试步骤。
基于配置文件的权限配置加依赖：
<depedecy><groupId>com.itmuch.security</groupId><artifactId>light-security-sprig-boot-starter</artifactId><versio>1.0.1-RELEASE</versio></depedecy><depedecy><groupId>org.sprigframework.boot</groupId><artifactId>sprig-boot-starter-aop</artifactId></depedecy>写配置
light-security:#权限规则配置：表示用{http-method}方法请求的{path}路径必须具备什么{expressio}spec-list:-http-method:ANYpath:/logiexpressio:"ao()"-http-method:ANYpath:/userexpressio:"hasAyRoles('user','admi')"-http-method:GETpath:/errorexpressio:"ao()"-http-method:ANYpath:/**expressio:"hasLogi()"jwt:#jwtsig算法algorithm:hs512#jwtsecretsecret:http-security-secret-modify-mehttp-security-secret-modify#jwt有效时间expiratio-i-secod:1209600写代码：
@RequestMappig@RestCotroller@RequiredArgsCostructor(oCostructor=@__(@Autowired))publicclassTestCotroller{privatefialUserOperatoruserOperator;privatefialJwtOperatoroperator;/***演示如何获取当前登录用户信息*-该路径需要具备user或admi权限才可访问，详见applicatio.yml**@retur用户信息*/@GetMappig("/user")publicUseruser(){returuserOperator.getUser();}/***演示基于注解的权限控制**@retur如果有权限返回亲，你同时有user、admi角色..*/@GetMappig("/aotatio-test")@PreAuthorize("hasAllRoles('user','admi')")publicStrigaotatioTest(){retur"亲，你同时有user、admi角色..";}/***模拟登录，颁发toke**@returtoke字符串*/@GetMappig("/logi")publicStriglogiReturToke(){Useruser=User.builder().id(1).userame("张三").roles(Arrays.asList("user","admi")).build();returoperator.geerateToke(user);}}基于代码的权限配置@CofiguratiopublicclassLightSecurityCofigurtio{@BeapublicSpecRegistryspecRegistry(){returewSpecRegistry().add(HttpMethod.GET,"/user","hasAyRoles('user')").add(HttpMethod.ANY,"/**","hasLogi()");}}此时，applicatio.yml 中的如下配置可删除，因为代码配置方式优先级更高，配置文件方式将会失效。
light-security:#权限规则配置：表示用{http-method}方法请求的{path}路径必须具备什么{expressio}spec-list:-http-method:ANYpath:/logiexpressio:"ao()"-http-method:ANYpath:/userexpressio:"hasAyRoles('user','admi')"-http-method:GETpath:/errorexpressio:"ao()"-http-method:ANYpath:/**expressio:"hasLogi()"扩展点类作用com.itmuch.lightsecurity.jwt.UserOperator提供用户相关操作，例如解析toke获得用户信息等。com.itmuch.lightsecurity.el.PreAuthorizeExpressioRoot提供了表达式，例如hasAyRoles('user') 等，如需新能力，只要写新方法即可com.itmuch.lightsecurity.aotatio.support.PreAuthorizeAspect为注解 @PreAuthorize("hasAllRoles('user','admi')")提供支持常见问题为什么要再造个轮子？老是有人问我诸如"微服务安全怎么管理？"、"SprigSecurityxxxx问题你遇到过吗？"、"能写个SprigCloudSecurity的系列教程吗？"、"Shiroxxxx问题你遇到过吗？"
烦不胜烦，初期积极回复；后来消极回复；再后来懒得回复。
分析一下，发现主要原因还是SprigSecurity、Shiro学习曲线较高，特别是SprigSecurity。所以就想写个轻量的框架，能够快速解决主要矛盾——足够简单、能实现权限控制。
为什么实现一个通用的权限解决方案？有考虑实现一个通用权限框架，但那样会增加挺多代码，而且要添加挺多适配逻辑(例如适配SprigMVC、WebFlux等)。
个人认为这在现阶段去实现还不合适，个人不太喜欢画饼。既然"通用性"不是目前最主要的矛盾，高效解决问题相对更加重要。那何必花精力去实现通用性？设计上支持往"通用性"迁移即可。
未来如果有需求，我会做一个通用版本，并且低版本也可无痛、平滑地迁移。
为什么不考虑身份认证(登录)？目前市面上大多权限框架都考虑了"身份认证(登录)"+"权限管理"。然而登录操作在现在这个时代，是一个"五花八门"的操作。例如：
手机号+验证码登录扫二维码登录账号密码登录证书登录往往还需还同时支持多种登录方式。这挺难去抽象出通用模式，并为典型的登录方式提供支持。
索性不考虑了——把登录问题留给使用者自己。用户可根据业务需求实现登录逻辑，并颁发Toke，后面的事情就交给 LightSecurity ，让它给你搞定。这样相对更加灵活，更重要的是——你也不再需要去学习用框架应该怎么登录。
评论