基于djangoRBAC权限

m0_58310590

于 2024-06-24 23:15:34 发布

阅读量1k

点赞数 24

文章标签：数据库网络服务器 django

本文链接：https://blog.csdn.net/m0_58310590/article/details/139941133

版权

RBAC——基于角色权限的模型

【重要】关键构成

RBAC 模型的关键组成部分包括以下几个要素：

角色（Roles）：定义了一组相关权限的集合，例如管理员、用户、审计员等。每个角色代表了特定的工作职责或访问需求。

权限（Permissions）：表示可以执行的操作或访问的资源。权限可以是系统级别的，也可以是特定功能或数据的访问权限。

用户（Users）：系统中的个体用户，被分配到一个或多个角色中。

授权（Authorization）：将角色与权限进行关联，并将角色分配给用户。授权过程确定了用户在系统中的访问权限。

通过使用 RBAC，组织可以实现细粒度的访问控制，确保用户只能访问他们所需的资源，并提高系统的安全性和可管理性。

【 0 】前言

RBAC解决了什么问题

基于角色的访问控制（RBAC）模型解决了许多与权限管理相关的问题，主要包括以下几个方面：

简化权限管理：RBAC模型通过将权限授予角色而不是直接授予用户，简化了权限管理的复杂性。管理员可以根据用户的职责和职位将其分配到适当的角色，而不必为每个用户单独配置权限。这样可以减少管理工作量，提高效率。
降低错误和风险：RBAC模型减少了手动配置权限的错误风险。由于权限是基于角色进行管理，管理员只需要为角色定义适当的权限，而不必考虑每个用户的具体权限。这样可以减少配置错误和意外授权的可能性，提高系统的安全性。
支持权限的继承和维护：RBAC模型支持权限的继承。当一个用户被分配到一个角色时，他将自动继承该角色所具有的权限。如果需要更改权限，只需调整角色的权限定义即可，而无需逐个修改每个用户的权限。这样简化了权限的维护和更新过程。
增强了系统的可扩展性和灵活性：RBAC模型使系统能够更好地适应变化和扩展。当新增用户或角色时，只需将其分配到相应的角色，而无需修改系统的访问规则。这样可以轻松地扩展系统并适应组织结构的变化。
促进了合规性和审计：RBAC模型使合规性和审计更加可行。通过角色的权限分配和管理，可以更容易地跟踪和审计系统中的权限使用情况。这有助于确保符合法规要求，并提供了追踪和解决潜在安全问题的能力。

综上所述，RBAC模型通过简化权限管理、降低错误和风险、支持权限继承和维护、增强系统的可扩展性和灵活性，以及促进合规性和审计，解决了许多与权限管理相关的问题，提高了系统的安全性和管理效率。

RBAC的适用场景

基于角色的访问控制（RBAC）模型适用于许多不同的场景，尤其是那些需要对用户和资源之间的访问进行细粒度控制和管理的场景。以下是一些常见的RBAC使用场景：
企业组织架构：在企业中，RBAC可用于根据员工的职位、角色和职责来管理访问权限。不同部门的员工可以被分配到不同的角色，以便根据其工作职能限制他们对系统和资源的访问。
应用程序和系统访问控制：RBAC可用于管理应用程序和系统中的用户访问权限。管理员可以根据用户的角色将其分配到适当的角色，并定义角色的权限集合。这样，系统可以确保用户只能访问其所需的功能和数据，从而提高安全性。
多租户系统：在多租户环境中，RBAC模型可以用于对不同租户之间的访问进行隔离和管理。每个租户可以有自己的角色和权限定义，以确保其数据和资源只能被其授权的用户访问。
医疗保健：在医疗保健领域，RBAC可用于管理医生、护士和管理员等不同角色的访问权限。例如，医生可以被分配到具有病人记录和处方访问权限的角色，而护士只能访问病人记录。
金融和银行：在金融和银行领域，RBAC可用于管理不同用户角色的访问权限，例如客户、经理和审计人员。通过RBAC，可以确保客户只能访问其自己的账户信息，而经理和审计人员可以拥有更广泛的访问权限。
云计算和网络服务提供商：RBAC可用于管理云计算平台和网络服务提供商中的用户访问权限。不同用户可以被分配到不同的角色，以限制其对云资源、虚拟机或网络设备的操作。

RBAC模型可以应用于各种不同的领域和系统，以提供更安全、灵活和可管理的访问控制机制。根据特定的需求和环境，可以根据RBAC模型进行定制和扩展。

【一】RBAC是什么？

Role-Based Access Control，中文意思是：基于角色（Role）的访问控制。这是一种广泛应用于计算机系统和网络安全领域的访问控制模型。

简单来说，就是通过将权限分配给➡角色，再将角色分配给➡用户，来实现对系统资源的访问控制。一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。具体而言，RBAC模型定义了以下几个核心概念：

角色（Role）：角色是指在系统中具有一组相关权限的抽象概念，代表了用户在特定上下文中的身份或职能，例如管理员、普通用户等。
权限（Permission）：权限是指对系统资源进行操作的许可，如读取、写入、修改等。权限可以被分配给角色。
用户（User）：用户是指系统的实际使用者，每个用户可以被分配一个或多个角色。
分配（Assignment）：分配是指将角色与用户关联起来，以赋予用户相应的权限。

RBAC 认为授权实际上是Who 、What 、How 三元组之间的关系，也就是Who 对What 进行How 的操作，也就是“主体”对“客体”的操作。

Who：是权限的拥有者或主体（如：User，Role）。
What：是操作或对象（operation，object）。
How：具体的权限（Privilege,正向授权与负向授权）。

通过RBAC模型，可以实现灵活且易于管理的访问控制策略。管理员可以通过分配和调整角色，来管理用户的权限。这种角色层次结构可以帮助简化权限管理，并确保用户只有所需的权限。

RBAC模型广泛应用于系统安全、数据库管理、网络管理等领域，它提供了一种可扩展、可管理的访问控制机制，有助于保护系统资源免受未经授权的访问和潜在的安全威胁。

【二】为什么要使用RBAC模型？

因为当用户的数量非常大时，要给系统每个用户逐一授权，是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。

在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。

举个例子：登录功能的用户-角色-权限关系

图片来源：RBAC角色权限设计-阿里云开发者社区

【三】RBAC的适用场景

（1）企业组织架构：在企业中，RBAC可用于根据员工的职位、角色和职责来管理访问权限。不同部门的员工可以被分配到不同的角色，以便根据其工作职能限制他们对系统和资源的访问。

（2）应用程序和系统访问控制：RBAC可用于管理应用程序和系统中的用户访问权限。管理员可以根据用户的角色将其分配到适当的角色，并定义角色的权限集合。这样，系统可以确保用户只能访问其所需的功能和数据，从而提高安全性。

（3）多租户系统：在多租户环境中，RBAC模型可以用于对不同租户之间的访问进行隔离和管理。每个租户可以有自己的角色和权限定义，以确保其数据和资源只能被其授权的用户访问。

（4）医疗保健：在医疗保健领域，RBAC可用于管理医生、护士和管理员等不同角色的访问权限。例如，医生可以被分配到具有病人记录和处方访问权限的角色，而护士只能访问病人记录。

（5）金融和银行：在金融和银行领域，RBAC可用于管理不同用户角色的访问权限，例如客户、经理和审计人员。通过RBAC，可以确保客户只能访问其自己的账户信息，而经理和审计人员可以拥有更广泛的访问权限。

（6）云计算和网络服务提供商：RBAC可用于管理云计算平台和网络服务提供商中的用户访问权限。不同用户可以被分配到不同的角色，以限制其对云资源、虚拟机或网络设备的操作。

RBAC模型可以应用于各种不同的领域和系统，以提供更安全、灵活和可管理的访问控制机制。根据特定的需求和环境，可以根据RBAC模型进行定制和扩展。

【四】RBAC流程图

【五】RBAC各模块功能

用户跟角色可以是多对多关系

【六】访问控制流程

【七】数据库设计及相关表2结构

主外键关联的

非主外键（虚拟）

【八】RBAC模型四级分级

RBAC0（Core RB2AC）：最简单的RBAC形式，员工使用角色来获取权限（使用最多）。

基本模型有三个元素：用户、角色和权限。模型设计基于“多对多”原则，即多个用户可以具有相同的角色，一个用户可以具有多个角色。同样，您可以将同一权限分配给多个角色，也可以将同一角色分配给多个权限。

RBAC1（Hierarchical RBAC）：分层，建立在FlatRBAC规则之上，增加角色分层。

添加了第四个组件-层次结构，它定义了不同角色之间的资历关系。通过允许高级角色自动获取下级角色的权限，可以消除冗余，例如在角色重叠时必须指定某些权限。

RBAC2（Static separation of duty (SSD) relations）：受约束的，建立在分层RBAC0之上，并增加职责分离。

为了在存在利益冲突策略的情况下提供帮助，将根据用户分配添加角色之间的关系。例如，作为一个角色的成员的用户将无法被指派为具有利益冲突的角色的成员。

RBAC3（Dynamic separation of duty (DSD) relations）：RBAC3=RBAC1+RBAC2

与SSD一样，DSD限制了可用的用户权限，但基于不同的上下文。例如，根据会话期间执行的任务，用户可能需要不同级别的访问，DSD限制会话期间激活的权限。

【九】总结（优缺1点）

RBAC模型的优点：

简化权限管理：RBAC模型通过将权限分配给角色，再将角色分配给用户，使得权限管理更加灵活和易于管理。管理员可以通过调整角色和用户之间的关系，来分配和撤销权限，而无需直接管理每个用户的权限。
灵活的角色与权限关系：RBAC模型支持多对多的角色与权限关系，即一个角色可以拥有多个权限，一个权限也可以被多个角色所共享。这种灵活性使得RBAC适用于各种复杂的权限管理需求。
提高安全性：RBAC模型可以确保用户只有所需的权限，并提供了良好的隔离性。通过严格控制权限的分配，可以减少系统中的安全漏洞和潜在的攻击风险。
易于扩展和维护：由于RBAC模型使用了基于角色的抽象概念，当系统需要进行扩展或调整时，只需修改角色的权限分配，而无需改变具体的用户权限。

RBAC模型的缺点：

复杂性：尽管RBAC模型提供了灵活的权限管理机制，但其本身也较为复杂。设计和实施RBAC系统需要仔细考虑角色的定义、权限的分配以及用户与角色之间的关系，需要进行详细的规划和配置。
难以处理特殊情况：RBAC模型对于不同角色的用户可能存在某些特殊需求或特权，如临时提升权限、临时改变角色等，这些特殊情况可能难以通过RBAC模型来满足。
高度依赖角色设计：RBAC模型的有效性和安全性高度依赖于正确定义和管理角色。如果角色设计不合理或者角色权限分配不当，可能导致系统中出现权限过度或权限不足的问题。
难以适应复杂场景：在某些复杂的业务场景下，RBAC模型可能无法满足需求。例如，需要考虑时间约束、地域约束、审批流程等其他因素时，RBAC模型的简单角色与权限关系可能显得不够灵活和细粒度。

总结起来，RBAC模型具有简化权限管理、灵活的角色与权限关系、提高安全性和易于扩展等优点。但同时也存在复杂性、处理特殊情况困难、高度依赖角色设计和难以适应复杂场景等缺点。在实施RBAC模型时，需要根据具体情况进行合理规划和权衡。

【十】安全原则

RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。

最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。

责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。

数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。

基于RBAC模型的权限管理设计

简介： RBAC模型（Role-Based Access Control：基于角色的访问控制）是比较早期提出的权限实现模型，在多用户计算机时期该思想即被提出，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公认。RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为Who、What、How的问题，Who、What、How构成了访问权限三元组，具体的理论可以参考RBAC96。

目的

管理系统用户的功能菜单权限，物理资源（文件、数据）权限。

RBAC模型

简介

RBAC模型（Role-Based Access Control：基于角色的访问控制）是比较早期提出的权限实现模型，在多用户计算机时期该思想即被提出，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公认。

RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为Who、What、How的问题，Who、What、How构成了访问权限三元组，具体的理论可以参考RBAC96。

核心对象

用户、角色、权限

组成

RBAC0

RBAC0是基础，很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。譬如我们做一款企业管理产品，可以抽象出几个角色，譬如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理、市场经理，这样他就拥有这两个角色的所有权限。

RBAC1

RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，即增加角色组的概念。简单理解就是，给角色分成几个等级，用户关联角色组、角色组关联角色，角色关联权限。从而实现更细粒度的权限管理。

RBAC2

RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。静态职责分离，如果一个任务有3个步骤，那么要求必要有至少3个不同用户处理完毕，任务才完结。又如，一个任务有2个步骤，要求必须由两个不同角色的用户来处理，且不能是同一个用户，即一个用户不可同时拥有该两个角色，这种可称之为静态互斥角色。动态职责分离，动态分配系统资源和功能的权限，如某些资源在特定时间才允许对某些用户开放。

RBAC3

RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。

拓展RBAC模型

针对物理资源的权限管理

系统资源可分为逻辑资源和物理资源。逻辑资源如软件系统的菜单、页面、按钮等等；物理资源如视频文件、音频文件、pdf文件等等。其中逻辑资源可以通过权限来控制，物理资源可通过在角色下设置资源列表，通过角色关联资源列表实现，也可直接将用户和资源列表关联实现。

增加用户组管理

基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，用户组凌驾用户之上，是用户的一个集合。可通过增加UserGroup实现，也可以通过引入组织架构实现（即用户的管理变成了组织-部门-用户的管理）。

权限管理设计

功能权限管理

以RBAC0模型为基础建立核心业务实体：单位（公司/部委/组织机构）、部门（科室）、用户、角色、权限
- 使用关联实体为核心业务实体建立映射关系：用户角色、角色权限等
- 为方便数据查询和业务拓展，增加单位权限、单位角色映射关系。此两项非必须。
- 可按照RBAC1模型的设计思路，增加角色组，用户关联角色组、角色组关联角色，角色关联权限。从而实现更细粒度的权限管理。
- 可按照RBAC1模型的思想，将部门和用户的映射关系修改为m:n，将能够实现一个用户归属多个组织的权限管理。如分公司的董事长同时兼任集团公司部门领导的情况。其中隐含了单位和部门关系为多对多，部门和用户关系为多对多。当用户登录的时候，让用户自己选择需要在哪个组织下工作。鉴于这种情况的项目相对而言为少数，大部分项目没有那么复杂的组织架构，可以对外提供两套解决方案。

资源权限管理

业务弱关联性设计

资源本身作为一个业务实体，为资源划分类型
资源和单位建立映射关系，用户隶属于单位
资源和部门建立映射关系，用户隶属于部门
资源和角色建立映射关系，用户关联角色
资源和行政区划建立映射关系，用户关联行政区划或部门关联行政区划或单位关联行政区划
拓展：资源和XXX业务实体建立映射关系，用户关联XXX业务实体

优点：资源和业务实体为弱关联性，可封装成微服务组件对外赋能
缺点：关系模式更加复杂，开发、运维成本高

业务强关联性设计

基于组织架构、职权（角色）、业务归属、区域、坐标等的业务实体建立映射关系

数据权限的管理最简单的维度就是基于功能权限的管理
根据业务数据归属分别建立用户和数据的映射关系
根据业务数据所属业务闸口、区域（行政区域，地缘，自定义划区）和业务实体建立映射关系，业务实体最终落到用户上
根据业务数据治理出来的坐标体系建立映射管理
其他维度的数据权限管理

优点：方便和业务集成、迁移顺滑
缺点：和业务强绑定

缓存设计

可能出现的问题：
1：用户权限信息庞大，往redis中存储大数据块
2：用户权限信息庞大，Mysql数据库查询效率低

RBAC后台管理

settings.py配置文件

#  设置权限
PERMISSIONS = {
    "admin": {
        # 根据路由的名称进行权限的赋予
        "depart-list": ['GET', "POST"],
        # depart-detail对应于 DepartView 中的 retrieve, update, partial_update 和 destroy 方法
        "depart-detail": ['GET', 'PUT', 'PATCH', 'DELETE'],

        "user-detail": ['GET', 'PUT', 'PATCH', 'DELETE'],

    },
    "jingyi": {
        "user-list": ["GET", "POST"],  # 假设管理员可以查看用户列表和创建用户
        "user-detail": ["GET", "PUT", "PATCH", "DELETE"],
        # 添加其他需要的权限
    },
    "user": {
        "depart-detail": ['GET'],
        "user-list": ['GET'],
    },
    "manager": {
        "depart-list": ['GET', "POST"],
    },
}

REST_FRAMEWORK = {
    "UNAUTHENTICATED_USER": None,
    "UNAUTHENTICATED_TOKEN": None
}

# 扩写auth的user表 在AbstractUser必须这样
AUTH_USER_MODEL = 'user.User'

自定义权限源码

class BasePermissionMetaclass(OperationHolderMixin, type):
    pass


class BasePermission(metaclass=BasePermissionMetaclass):
    """
    A base class from which all permission classes should inherit.
    """

    def has_permission(self, request, view):
        """
        Return `True` if permission is granted, `False` otherwise.
        """
        return True

    def has_object_permission(self, request, view, obj):
        """
        Return `True` if permission is granted, `False` otherwise.
        """
        return True

获取对当前的配置的URL

url_name = request.resolver_match.url_name

请求方法
- ```
method = request.method
```

MinPermission.py

from rest_framework.permissions import BasePermission


class MinPermission(BasePermission):
    # 设置权限
    def has_permission(self, request, view):
        # # 判断用户
        # print('判断权限',request.user)
        # # 判断角色
        print('判断权限', request.user.role)

        # 1.当前用户所以的权限
        from django.conf import settings
        permission_dict = settings.PERMISSIONS[request.user.role]

        # 2.当前用户正在访问的URL和方式
        # 判断权限 user
        # depart-list OPTIONS
        # print(request.resolver_match.url_name, request.method)
        url_name = request.resolver_match.url_name
        method = request.method

        # 3.权限判断
        method_list = permission_dict.get(url_name)
        if not method_list:
            return False
        if method in method_list:
            return True
        return False

    def has_object_permission(self, request, view, obj):
        return True

自定义认证类源码

class BaseAuthentication:
    """
    All authentication classes should extend BaseAuthentication.
    """

    def authenticate(self, request):
        """
        Authenticate the request and return a two-tuple of (user, token).
        """
        raise NotImplementedError(".authenticate() must be overridden.")

    def authenticate_header(self, request):
        """
        Return a string to be used as the value of the `WWW-Authenticate`
        header in a `401 Unauthenticated` response, or `None` if the
        authentication scheme should return `403 Permission Denied` responses.
        """

Authen.py

from rest_framework.authentication import BaseAuthentication
from rest_framework import exceptions


class User(object):
    def __init__(self, name=None, role=None):
        self.name = name
        self.role = role


class MinAuthentication(BaseAuthentication):
    # 自定义的认证类
    def authenticate(self, request):
        # 读取用户请求token，校验是否合法！！！
        token = request.query_params.get('token')
        role = request.query_params.get('role')
        if not token:
            raise exceptions.AuthenticationFailed('认证失败！！！')

        # request.user.name
        # request.user.role
        # request.auth
        # 返回的是两个字request.user跟request.all
        # return (None, None)
        return (User('BOSS', role), None)

    def authenticate_header(self, request):
        return 'API'

序列化类

from rest_framework import serializers
from .models import Depart, Role, User


class DepartSerializer(serializers.ModelSerializer):
    class Meta:
        model = Depart
        fields = '__all__'


class RoleSerializer(serializers.ModelSerializer):
    class Meta:
        model = Role
        fields = ['name', 'status']


# 创建用户
class UserSerializer(serializers.ModelSerializer):
    roles = RoleSerializer(many=True, read_only=True)

    class Meta:
        model = User
        fields = ('username', 'email','password', 'roles')

    def create(self, validated_data):
        user = User.objects.create(
            username=validated_data['username'],
            email=validated_data['email']
        )
        user.set_password(validated_data['password'])
        user.save()

        # 从请求中获取角色数据
        roles_data = self.context['request'].data.get('roles', [])
        if roles_data:
            roles = Role.objects.filter(id__in=roles_data)
            # 添加用户角色
            user.roles.add(*roles)

        return user

视图类

from rest_framework.viewsets import ModelViewSet
from .models import Depart
from .serializer import DepartSerializer
# 自定义权限
from utils.MinPermission import MinPermission
# 自定义认证
from utils.Authen import MinAuthentication


class DepartView(ModelViewSet):
    queryset = Depart.objects.all()
    serializer_class = DepartSerializer

    authentication_classes = [MinAuthentication, ]
    permission_classes = [MinPermission,]

    
    
# 创建角色
class RoleCreateView(viewsets.ModelViewSet):
    queryset = Role.objects.all()
    serializer_class = RoleSerializer


class UserView(viewsets.ModelViewSet):
    queryset = User.objects.all()
    serializer_class = UserSerializer

    authentication_classes = [MinAuthentication, ]
    permission_classes = [MinPermission, ]


from .views import DepartView
# 自动生成路由
from rest_framework.routers import SimpleRouter

# 实例化对象
router = SimpleRouter()


router.register('depart', DepartView, 'depart'),

urlpatterns = [

]

# 4 把自动生成的路由，放到 urlpatterns中
urlpatterns += router.url

# http://127.0.0.1:8000/user/api/v1/depart/?token=1&role=admin

# http://127.0.0.1:8000/user/api/v1/depart/

# http://127.0.0.1:8000/user/api/v1/depart/1/?token=1&role=manager

注意：

这些虽然可以实现权限的的限制！！！，但是局限性太大。

    def has_permission(self, permission_name, view):
        # 用户是否有特定权限的检查
        # 遍历当前用户的所有角色
        for role in self.roles.all():
            if permission_name in [perm.name for perm in role.permissions.all()]:
                return True
        return False

=admin


[外链图片转存中...(img-T4eUGA2t-1719242095535)]

```python
# http://127.0.0.1:8000/user/api/v1/depart/

[外链图片转存中…(img-ekToN80B-1719242095535)]

# http://127.0.0.1:8000/user/api/v1/depart/1/?token=1&role=manager

[外链图片转存中…(img-ikIEDK1C-1719242095535)]

[外链图片转存中…(img-VPBfrWRh-1719242095536)]

注意：

这些虽然可以实现权限的的限制！！！，但是局限性太大。

    def has_permission(self, permission_name, view):
        # 用户是否有特定权限的检查
        # 遍历当前用户的所有角色
        for role in self.roles.all():
            if permission_name in [perm.name for perm in role.permissions.all()]:
                return True
        return False

m0_58310590

关注

24
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
基于djangoRBAC权限

基于角色的访问控制（RBAC）模型解决了许多与权限管理相关的问题，主要包括以下几个方面：简化权限管理：RBAC模型通过将权限授予角色而不是直接授予用户，简化了权限管理的复杂性。管理员可以根据用户的职责和职位将其分配到适当的角色，而不必为每个用户单独配置权限。这样可以减少管理工作量，提高效率。降低错误和风险：RBAC模型减少了手动配置权限的错误风险。由于权限是基于角色进行管理，管理员只需要为角色定义适当的权限，而不必考虑每个用户的具体权限。这样可以减少配置错误和意外授权的可能性，提高系统的安全性。
复制链接

扫一扫