update doc

129dad08 · sinat_25235033 · 9de7a5c5 · 129dad08 · 129dad08 · 129dad08
12 changed file
--- a/README_CN.md
+++ b/README_CN.md
@@ -19,21 +19,21 @@

 ## Background  
 现在很多网站都进行了前后端分离，后端提供rest api，前端调用接口获取数据渲染。这种架构下如何保护好后端所提供的rest api使得更加重视。  
-api的保护可以认为：认证-请求携带的认证信息是否校验通过，鉴权-认证通过的用户拥有指定api的权限才能访问此api。然而不仅于此，什么样的认证策略, jwt, basic,digest,oauth还是多支持, 权限配置是写死代码还是动态配置，我想动态赋权怎么办，云原生越来越火用的框架是quarkus等新秀不是spring生态咋弄，http实现不是servlet而是jax-rs规范咋整， to be or not to be, this is a question
+认证-请求携带的认证信息是否校验通过，鉴权-认证通过的用户拥有指定api的权限才能访问此api。然而不仅于此，什么样的认证策略, jwt, basic,digest,oauth还是多支持, 权限配置是写死代码还是动态配置，我想动态赋权怎么办，云原生越来越火用的框架是quarkus等新秀不是spring生态咋弄，http实现不是servlet而是jax-rs规范咋整。   

 > 目前`java`主流的权限框架有`shiro，spring security`, 下面对于它们的探讨都是个人之见，接受纠正   
 > `shiro`对于`restful api`原生支持不太友好,需要改写一些代码,2年前一个项目 [booshiro](https://gitee.com/tomsun28/bootshiro) 就是改造`shiro`,使其在过滤链就能匹配不同的`rest`请求进行权限校验,之后给`shiro commit`几次`pr`,`fix`其在过滤链匹配时的危险漏洞,总的来说`shiro`很强大但其起源并非面向`web`,对`restful`不是很友好    
-> `spring security`很强大,与`spring`深度集成,离开`spring`,比如`javalin`和之前用过的`osgi`框架`karaf`就用不了了  
-> 如果不用注解配置，它们都会在链式匹配这块，用请求的url和配置的链一个一个`ant`匹配(匹配过程中会有缓存等提高性能)，但匹配的链过多时还是比较耗性能(根据算法时间复杂度判断，暂未测试验证)    
-> 我们希望能解决这些，提供一个**针对restful api**，**无框架依赖**，可以**动态修改权限**，**多认证策略**，**更快速度**，**易用**的认证鉴权框架    
+> `spring security`很强大,与`spring`深度集成,离开`spring`,和其他框架就不太好集成使用    
+> 如果不用注解配置，它们都会在链式匹配这块，用请求的`url`和配置的链一个一个`ant`匹配(匹配过程中会有缓存等提高性能)，但匹配的链过多时还是比较耗性能(根据算法时间复杂度判断，暂未测试验证)    
+> 我们希望能解决这些，提供一个**针对`restful api`**，**无框架依赖**，可以**动态修改权限**，**多认证策略**，**更快速度**，**易用**的认证鉴权框架    

 ## <font color="green">Introduction</font>

 > `sureness` 是我们在使用 `java` 权限框架 `shiro` 之后,吸取其良好设计加上一些想法实现的全新认证鉴权项目  
 >  面对 `restful api` 的认证鉴权,基于 `rbac` (用户-角色-资源)主要关注于对 `restful api` 的安全保护  
->  无特定框架依赖(本质就是过滤器处拦截判断,已有springboot,quarkus,javalin,ktor等demo)  
->  支持动态修改权限配置(动态修改哪些api需要被认证，可以被谁访问)    
->  支持主流http容器  servlet 和 jax-rs  
+>  无特定框架依赖(本质就是过滤器处拦截判断,已有`springboot,quarkus,javalin,ktor`等demo)  
+>  支持动态修改权限配置(动态修改哪些`api`需要被认证，可以被谁访问)    
+>  支持主流`http`容器  `servlet` 和 `jax-rs`  
 >  支持多种认证策略, `jwt, basic auth, digest auth` ... 可扩展自定义支持的认证方式   
 >  [基于改进的字典匹配树拥有的高性能](#高性能匹配 )  
 >  良好的扩展接口, demo和文档  
@@ -61,7 +61,7 @@ api的保护可以认为：认证-请求携带的认证信息是否校验通过
  `eg: /api/v2/book===get` `get`方式请求`/api/v2/book`接口数据     
 - 角色资源映射: 用户所属角色--角色拥有资源--用户拥有资源(用户就能访问此`api`)   

-资源路径匹配详见 [url路径匹配](docs/cn/path-match.md)  
+资源路径匹配详见 [URI路径匹配](docs/cn/path-match.md)  

 #### 项目中加入sureness  

@@ -78,8 +78,8 @@ compile group: 'com.usthe.sureness', name: 'sureness-core', version: '0.4.2'
 ```

 #### 使用默认配置来配置sureness    
-默认配置使用了文件数据源sureness.yml作为账户权限数据源  
-默认配置支持了jwt, basic auth, digest auth认证  
+默认配置使用了文件数据源`sureness.yml`作为账户权限数据源  
+默认配置支持了`jwt, basic auth, digest auth`认证  
 ```
 @Bean
 public DefaultSurenessConfig surenessConfig() {
@@ -104,7 +104,7 @@ public DefaultSurenessConfig surenessConfig() {

 #### 添加过滤器拦截所有请求    

-`sureness`的本质就拦截所有rest请求对其认证鉴权判断。  
+`sureness`的本质就拦截所有`rest`请求对其认证鉴权判断。  
 入口拦截器器实现一般可以是 `filter or spring interceptor`  
 在拦截器中加入`sureness`的安全过滤器，如下:  

@@ -177,7 +177,7 @@ try {


 ## 参与贡献  
-非常欢迎参与项目贡献，跟sureness一起走得更远更好。对项目代码有疑问或者建议请直接联系 @tomsun28  
+非常欢迎参与项目贡献。对项目代码有疑问或者建议请直接联系 @tomsun28  

 仓库的组成部分:  
 - [sureness的核心代码--sureness-core](core)  

--- a/docs/cn/README.md
+++ b/docs/cn/README.md
@@ -16,33 +16,33 @@

 ## Background  
 现在很多网站都进行了前后端分离，后端提供rest api，前端调用接口获取数据渲染。这种架构下如何保护好后端所提供的rest api使得更加重视。  
-api的保护可以认为：认证-请求携带的认证信息是否校验通过，鉴权-认证通过的用户拥有指定api的权限才能访问此api。然而不仅于此，什么样的认证策略, jwt, basic,digest,oauth还是多支持, 权限配置是写死代码还是动态配置，我想动态赋权怎么办，云原生越来越火用的框架是quarkus等新秀不是spring生态咋弄，http实现不是servlet而是jax-rs规范咋整， to be or not to be, this is a question
+认证-请求携带的认证信息是否校验通过，鉴权-认证通过的用户拥有指定api的权限才能访问此api。然而不仅于此，什么样的认证策略, jwt, basic,digest,oauth还是多支持, 权限配置是写死代码还是动态配置，我想动态赋权怎么办，云原生越来越火用的框架是quarkus等新秀不是spring生态咋弄，http实现不是servlet而是jax-rs规范咋整。   

 > 目前`java`主流的权限框架有`shiro，spring security`, 下面对于它们的探讨都是个人之见，接受纠正   
 > `shiro`对于`restful api`原生支持不太友好,需要改写一些代码,2年前一个项目 [booshiro](https://gitee.com/tomsun28/bootshiro) 就是改造`shiro`,使其在过滤链就能匹配不同的`rest`请求进行权限校验,之后给`shiro commit`几次`pr`,`fix`其在过滤链匹配时的危险漏洞,总的来说`shiro`很强大但其起源并非面向`web`,对`restful`不是很友好    
-> `spring security`很强大,与`spring`深度集成,离开`spring`,比如`javalin`和之前用过的`osgi`框架`karaf`就用不了了  
-> 如果不用注解配置，它们都会在链式匹配这块，用请求的url和配置的链一个一个`ant`匹配(匹配过程中会有缓存等提高性能)，但匹配的链过多时还是比较耗性能(根据算法时间复杂度判断，暂未测试验证)    
-> 我们希望能解决这些，提供一个**针对restful api**，**无框架依赖**，可以**动态修改权限**，**多认证策略**，**更快速度**，**易用**的认证鉴权框架    
+> `spring security`很强大,与`spring`深度集成,离开`spring`,和其他框架就不太好集成使用    
+> 如果不用注解配置，它们都会在链式匹配这块，用请求的`url`和配置的链一个一个`ant`匹配(匹配过程中会有缓存等提高性能)，但匹配的链过多时还是比较耗性能(根据算法时间复杂度判断，暂未测试验证)    
+> 我们希望能解决这些，提供一个**针对`restful api`**，**无框架依赖**，可以**动态修改权限**，**多认证策略**，**更快速度**，**易用**的认证鉴权框架    

 ## <font color="green">Introduction</font>

 > `sureness` 是我们在使用 `java` 权限框架 `shiro` 之后,吸取其良好设计加上一些想法实现的全新认证鉴权项目  
 >  面对 `restful api` 的认证鉴权,基于 `rbac` (用户-角色-资源)主要关注于对 `restful api` 的安全保护  
->  无特定框架依赖(本质就是过滤器处拦截判断,已有springboot,quarkus,javalin,ktor等demo)  
->  支持动态修改权限配置(动态修改哪些api需要被认证，可以被谁访问)    
->  支持主流http容器  servlet 和 jax-rs  
+>  无特定框架依赖(本质就是过滤器处拦截判断,已有`springboot,quarkus,javalin,ktor`等demo)  
+>  支持动态修改权限配置(动态修改哪些`api`需要被认证，可以被谁访问)    
+>  支持主流`http`容器  `servlet` 和 `jax-rs`  
 >  支持多种认证策略, `jwt, basic auth, digest auth` ... 可扩展自定义支持的认证方式   
->  基于改进的字典匹配树拥有的高性能 
+>  [基于改进的字典匹配树拥有的高性能](#高性能匹配 )  
 >  良好的扩展接口, demo和文档  

 >`sureness`的低配置，易扩展，不耦合其他框架，能使开发者对自己的项目多场景快速安全的进行保护   

 ##### Framework Sample Support  

- [x] spring [sample-bootstrap](cn/sample-bootstrap.md)   
- [x] springboot [sample-tom](cn/sample-tom.md)  
- [x] quarkus [sample-quarkus](cn/sample-quarkus.md)  
- [x] javalin [sample-javalin](cn/sample-javalin.md)    
- [x] ktor [sample-ktor](cn/sample-ktor.md)    
- [x] spring webflux [spring-webflux-sureness](cn/sample-spring-webflux.md)    
+- [x] spring [sample-bootstrap](sample-bootstrap)   
+- [x] springboot [sample-tom](sample-tom)  
+- [x] quarkus [sample-quarkus](samples/quarkus-sureness)  
+- [x] javalin [sample-javalin](samples/javalin-sureness)    
+- [x] ktor [sample-ktor](samples/ktor-sureness)   
+- [x] spring webflux [sample-spring-webflux](samples/spring-webflux-sureness)   
 - [x] more samples todo   
--- a/docs/cn/_coverpage.md
+++ b/docs/cn/_coverpage.md
@@ -5,8 +5,8 @@
 > A Simple and Efficient Open-source Jvm Security Framework that Focus on Protection of Restful Api.  

 - 基于 `rbac` (用户-角色-资源)主要关注于对 `restful api` 的安全保护    
- 无特定框架依赖(springboot,quarkus,javalin,ktor等demo)  
- 支持主流http容器 servlet 和 jax-rs 
+- 无特定框架依赖(`springboot,quarkus,javalin,ktor`等demo)  
+- 支持主流`http`容器 `servlet` 和 `jax-rs` 
 - 支持动态权限配置   
 - 支持多种认证策略  


--- a/docs/cn/contributing.md
+++ b/docs/cn/contributing.md
 参与贡献  
 =======================================

-非常欢迎参与项目贡献，帮助sureness走得更远更好。对项目代码有疑问或者建议请直接联系 @tomsun28  
+非常欢迎参与项目贡献。对项目代码有疑问或者建议请直接联系 @tomsun28  

 仓库的组成部分:  
 - [sureness的核心代码--sureness-core](https://github.com/tomsun28/sureness/tree/master/core)  

--- a/docs/cn/custom-datasource.md
+++ b/docs/cn/custom-datasource.md
 ## 自定义数据源    

-自定义前需要了解sureness提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  
+自定义前需要了解`sureness`提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  

 实现 `PathTreeProvider`的接口, 加载到`DefaultPathRoleMatcher`中        
 实现 `SurenessAccountProvider`的接口,加载到需要的`processor`中       

--- a/docs/cn/custom-processor.md
+++ b/docs/cn/custom-processor.md
 ## 自定义processor    

-自定义前需要了解sureness提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  
+自定义前需要了解`sureness`提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  

 一个`subject`当然也可以被不同的`processor`处理,所以可以单独自定义`processor`   
 实现`Processor`接口,设置支持的`subject`,实现处理该`subject`的逻辑  

--- a/docs/cn/custom-subject-creator.md
+++ b/docs/cn/custom-subject-creator.md
 ## 自定义subject creator    

-自定义subject creator是我们使用频率最高的扩展，当请求体对象并不是servlet或者jax-rs标准api时, 我们就需要自定义subject creator, 
-使其通过请求对象获取我们需要的请求信息(请求路径，请求方法，认证信息等), 从而创建出对应的subject  
+自定义`subject creator`是我们使用频率最高的扩展，当请求体对象并不是`servlet`或者`jax-rs`标准`api`时, 我们就需要自定义`subject creator`, 
+使其通过请求对象获取我们需要的请求信息(请求路径，请求方法，认证信息等), 从而创建出对应的`subject`  

-自定义前需要了解sureness提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  
+自定义前需要了解`sureness`提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  

 - `SubjectCreate`: 创建`Subject`接口,根据请求内容创建不同类型的`Subject`对象 


--- a/docs/cn/custom-subject.md
+++ b/docs/cn/custom-subject.md
 ## 自定义subject  

-自定义前需要了解sureness提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  
+自定义前需要了解`sureness`提供的扩展接口,详见 [进阶扩展](cn/extend-point.md)  

 实现`Subject`接口,添加自定义的`subject`内容  
 实现`SubjectCreate`接口方法,创建出自定义的`subject`  

--- a/docs/cn/default-auth.md
+++ b/docs/cn/default-auth.md
@@ -35,12 +35,12 @@ Authorization: Basic dG9tOjMyMTEz
 下面是`digest auth`的认证流程(图片来源于[网络](https://www.cnblogs.com/xiaoxiaotank/p/11078571.html)):  
 ![digestFlow](../_images/digestFlow.png)  

-我们可以在chrome浏览器直接使用它: 访问url，在弹出的对话框中输入账户密码即可,chrome浏览器会自动进行认证流程.    
+我们可以在`chrome`浏览器直接使用它: 访问`url`，在弹出的对话框中输入账户密码即可,`chrome`浏览器会自动进行认证流程.    
 ![digestAuthChromeUse](../_images/digestAuthUse.png)    


 #### 其他认证方式  
-目前sureness默认支持这三种主流的认证方式，满足绝大部分需求，当然你也可以很轻松的自定义认证方式，详见[自定义Subject](cn/custom-subject.md)  
+目前`sureness`默认支持这三种主流的认证方式，满足绝大部分需求，当然你也可以很轻松的自定义认证方式，详见[自定义Subject](cn/custom-subject.md)  

 我们提供了默认认证方式的使用`DEMO`，请参考 [使用sureness10分钟项目集成案例](cn/sample-bootstrap.md)   
 当然我们也提供了自定义认证方式的扩展`DEMO`，请参考 [使用sureness30分钟项目集成案例](cn/sample-tom.md)     

--- a/docs/cn/quickstart.md
+++ b/docs/cn/quickstart.md
@@ -25,8 +25,8 @@ compile group: 'com.usthe.sureness', name: 'sureness-core', version: '0.4.2'
 ```

 #### 使用默认配置来配置sureness    
-默认配置使用了文件数据源sureness.yml作为账户权限数据源  
-默认配置支持了jwt, basic auth, digest auth认证  
+默认配置使用了文件数据源`sureness.yml`作为账户权限数据源  
+默认配置支持了`jwt, basic auth, digest auth`认证  
 ```
 @Bean
 public DefaultSurenessConfig surenessConfig() {

--- a/docs/cn/sample-spring-webflux.md
+++ b/docs/cn/sample-spring-webflux.md
@@ -3,7 +3,7 @@
 [spring-webflux-sureness例子项目仓库地址](https://github.com/tomsun28/sureness/tree/master/samples/spring-webflux-sureness)      

 - 基于`spring-webflux`
- 自定义 subject creator (BasicSubjectReactiveCreator, JwtSubjectReactiveCreator, NoneSubjectReactiveCreator) 适配 ServerHttpRequest 请求体    
+- 自定义 `subject creator (BasicSubjectReactiveCreator, JwtSubjectReactiveCreator, NoneSubjectReactiveCreator)` 适配 `ServerHttpRequest` 请求体    
 - 从默认的配置文件`sureness.yml`加载账户信息,资源角色,过滤资源等信息  
 - 使用默认的`jwt,basic auth`方式认证鉴权
 - 例子中包含`restful api`  

--- a/docs/cn/sample-tom.md
+++ b/docs/cn/sample-tom.md
@@ -9,9 +9,9 @@

 样例中包含2种自定义认证鉴权方式:  

-1. 自定义了一个单独的subjectCreator 见 `CustomPasswdSubjectCreator`     
-演示功能就是自定义的从不同地方获取请求体的账户密码，来创建默认的PasswordSubject，走默认的账户密码认证流程  
+1. 自定义了一个单独的`subjectCreator` 见 `CustomPasswdSubjectCreator`     
+演示功能就是自定义的从不同地方获取请求体的账户密码，来创建默认的`PasswordSubject`，走默认的账户密码认证流程  

-2. 自定义了一整套流程(包含subject subjectCreator processor) 见 `CustomTokenSubject CustomTokenSubjectCreator CustomTokenProcessor`  
-演示功能就是自定义一个简单的token作为subject对象，对其自定义创建获取方式-creator和自定义认证鉴权处理流程-processor.  
-此自定义流程也演示了一个简单的token刷新流程  
\ No newline at end of file
+2. 自定义了一整套流程(包含`subject subjectCreator processor`) 见 `CustomTokenSubject CustomTokenSubjectCreator CustomTokenProcessor`  
+演示功能就是自定义一个简单的`token`作为`subject`对象，对其自定义创建获取方式-`creator`和自定义认证鉴权处理流程-`processor`.  
+此自定义流程也演示了一个简单的`token`刷新流程  
\ No newline at end of file