API的主要功能是提供应用程序与开发人员以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。提供API所定义的功能的软件称作此API的实现。API是一种接口,故而是一种抽象。
Representational State Transfer,简称REST,是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。REST比较重要的点是资源和状态转换,
所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。
而"状态转换",则是把对应的HTTP协议里面,四个表示 *** 作方式的动词分别对应四种基本 *** 作:
GET,用来浏览(browse)资源
POST,用来新建(create)资源
PUT,用来更新(update)资源
DELETE,用来删除(delete)资源。
角色和用户的概念,自不用多说,大家都懂,但是权限的概念需要提一提。
"权限",就是资源与 *** 作的一套组合,例如"增加用户"是一种权限,"删除用户"是一种权限,所以对于一种资源所对应的权限有且只有四种。
角色与用户的关系:一个角色对应一群用户,一个用户也可以扮演多个角色,所以它们是多对多的关系。
角色与权限的关系:一个角色拥有一堆权限,一个权限却只能属于一个角色,所以它们是一(角色)对多(权限)的关系
权限与用户的关系:由于一个用户可以扮演多个角色,一个角色拥有多个权限,所以用户与权限是间接的多对多关系。
策略/过滤器
在sails下称为策略(Policy),在java SSH下称为过滤器(Filter),无论名称如何,他们工作原理是大同小异的,主要是在一条HTTP请求访问一个Controller下的action之前进行检测。所以在这一层,我们可以自定义一些策略/过滤器来实现权限控制。
为行文方便,下面姑且允许我使用策略这一词。
策略 (Policy)
下面排版顺序对应Policy的运行顺序
SessionAuthPolicy:
检测用户是否已经登录,用户登录是进行下面检测的前提。
SourcePolicy:
检测访问的资源是否存在,主要检测Source表的记录
PermissionPolicy:
检测该用户所属的角色,是否有对所访问资源进行对应 *** 作的权限。
OwnerPolicy:
如果所访问的资源属于私人资源,则检测当前用户是否该资源的拥有者。
如果通过所有policy的检测,则把请求转发到目标action。
Sails下的权限控制实现
在Sails下,有一个很方便的套件sails-permissions,集成了一套权限管理的方案,本文也是基于该套件的源码所引出来的权限管理解决方案。
有两种供参考1、用户、组、菜单设计 用户与组多对多的关系 组和菜单多对多的关系 此处的组相当于角色、菜单可以表达为页面url等
2、用户、角色、权限设计 用户角色权限两两多对多关系
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)