美文网首页
基于RESTful API 设计用户权限控制

基于RESTful API 设计用户权限控制

作者: 逐梦余生 | 来源:发表于2023-03-13 15:40 被阅读0次

    Restful简述

    本文是基于RESTful描述的,需要你对这个有初步的了解。 RESTful是什么? Representational State Transfer,简称REST,是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。 REST比较重要的点是资源和状态转换, 所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。 而 “状态转换”,则是把对应的HTTP协议里面,四个表示操作方式的动词分别对应四种基本操作:
    1.GET,用来浏览(browse)资源
    2.POST,用来新建(create)资源
    3.PUT,用来更新(update)资源
    4.DELETE,用来删除(delete)资源


    资源的分类及操作
    清楚了资源的概念,然后再来对资源进行一下分类,我把资源分为下面三类:
    1.私人资源 (Personal Source)
    2.角色资源 (Roles Source)
    3.公共资源 (Public Source)


    “私人资源”:是属于某一个用户所有的资源,只有用户本人才能操作,其他用户不能操作。例如用户的个人信息、订单、收货地址等等。 “角色资源”:与私人资源不同,角色资源范畴更大,一个角色可以对应多个人,也就是一群人。如果给某角色分配了权限,那么只有身为该角色的用户才能拥有这些权限。例如系统资源只能够管理员操作,一般用户不能操作。 “公共资源”:所有人无论角色都能够访问并操作的资源。
    而对资源的操作,无非就是分为四种:
    1.浏览 (browse)
    2.新增 (create)
    3.更新 (update)
    4.删除 (delete)

    角色、用户、权限之间的关系
    角色和用户的概念,自不用多说,大家都懂,但是权限的概念需要提一提。
    “权限”,就是资源与操作的一套组合,例如"增加用户"是一种权限,"删除用户"是一种权限,所以对于一种资源所对应的权限有且只有四种。



    角色与用户的关系:一个角色对应一群用户,一个用户也可以扮演多个角色,所以它们是多对多的关系。
    角色与权限的关系:一个角色拥有一堆权限,一个权限却只能属于一个角色,所以它们是一(角色)对多(权限)的关系
    权限与用户的关系:由于一个用户可以扮演多个角色,一个角色拥有多个权限,所以用户与权限是间接的多对多关系。


    需要注意两种特别情况:
    私人资源与用户的关系,一种私人资源对应的四种权限只能属于一个用户,所以这种情况下,用户和权限是一(用户)对多(权限)的关系。
    超级管理员的角色,这个角色是神一般的存在,能无视一切阻碍,对所有资源拥有绝对权限,甭管你是私人资源还是角色资源。

    数据库表的设计
    角色、用户、权限的模型应该怎么样设计,才能满足它们之间的关系?



    对上图的一些关键字段进行说明:

    Source
    name: 资源的名称,也就是其他模型的名称,例如:user、role等等。
    identity: 资源的唯一标识,可以像uuid,shortid这些字符串,也可以是model的名称。
    permissions : 一种资源对应有四种权限,分别对这种资源的browse、create、update、delete
    Permission
    source : 该权限对应的资源,也就是Source的某一条记录的唯一标识
    action :对应资源的操作,只能是browse、create、update、delete四个之一
    relation:用来标记该权限是属于私人的,还是角色的,用于OwnerPolicy检测
    roles: 拥有该权限的角色
    Role
    users : 角色所对应的用户群,一个角色可以对应多个用户
    permissions: 权限列表,一个角色拥有多项权利
    User
    createBy : 该记录的拥有者,在user标里,一般等于该记录的唯一标识,这一属性用于OwnerPolicy的检测,其他私有资源的模型设计,也需要加上这一字段来标识资源的拥有者。
    roles : 用户所拥有的角色

    策略/过滤器
    在sails下称为策略(Policy),在java SSH下称为过滤器(Filter),无论名称如何,他们工作原理是大同小异的,主要是在一条HTTP请求访问一个Controller下的action之前进行检测。所以在这一层,我们可以自定义一些策略/过滤器来实现权限控制。
    为行文方便,下面姑且允许我使用策略这一词。

    ** 策略 (Policy) **

    下面排版顺序对应Policy的运行顺序

    SessionAuthPolicy:
    检测用户是否已经登录,用户登录是进行下面检测的前提。
    SourcePolicy:
    检测访问的资源是否存在,主要检测Source表的记录
    PermissionPolicy:
    检测该用户所属的角色,是否有对所访问资源进行对应操作的权限。
    OwnerPolicy:
    如果所访问的资源属于私人资源,则检测当前用户是否该资源的拥有者。
    如果通过所有policy的检测,则把请求转发到目标action。


    相关文章

      网友评论

          本文标题:基于RESTful API 设计用户权限控制

          本文链接:https://www.haomeiwen.com/subject/rfpcrdtx.html