关于 restful api 的认证鉴权中的 rbac

[tomsun28]

将 restful api 视作一个资源，即 /api/book/foor===get, get 请求 /api/book/foor 整体视为一个资源
/api/book/foor===post, post 请求 /api/book/foor 整体视为另一个资源
资源和角色相映射，用户再和角色对应。即角色拥有资源，用户所属对应角色，用户才能访问此 api.

上面这种方式咋样? 自荐一个开箱即用的高效认证鉴权包，专注于 Restful Api 的动态保护 su.usthe.com

github: https://github.com/tomsun28/sureness

<dependency>
    <groupId>com.usthe.sureness</groupId>
    <artifactId>sureness-core</artifactId>
    <version>0.0.2.7</version>
</dependency>

[ksice]

这不是按钮级别的权限么，不知道 rbac 到底是个什么程度的权限控制

[tomsun28]

@ksice 这个没有针对按钮，针对的是一个 restful api 接口的权限保护，如果需要按钮权限可以考虑按钮绑定 api 。rbac 我理解是基于角色的权限控制，比如说： 用户 A 属于角色 B，角色 B 拥有资源 C 的访问权限，那么用户 A 就能访问资源 C 。在上面，我们把 restful api 接口视为资源 C 。

[ksice]

那这个不就是最简单的五表权限，或者七表权限和九表权限

[tomsun28]

@ksice 嗯嗯是的，这个项目如果用数据库作为数据源，数据库存储结构会是 5 表权限

[ksice]

@tomsun28 不用数据库的话还可以用什么做数据源呢，缓存么

[tomsun28]

@ksice 目前也实现了基于配置文件做数据源

[ksice]

@tomsun28 基于配置文件是不是没有数据库那么方便灵活和持久化

[tomsun28]

@ksice 是的 支持文本配置是为了方便用户更快搭建试用效果，或者有简单认证需求的可以使用文本数据源，推荐还是数据库作为源

[ksice]

@tomsun28 嗯，只是为了测试的话就不用考虑这方面的问题

[tomsun28]

@ksice 嗯嗯