2025-09-19
RBAC，Role-Based Access Control，直译似乎是基于角色的权限控制。
如果直接分配给用户user，那么50个销售就要分配50次，这也太蠢了。所以如果我们定义一个销售角色role，然后只要给这个角色分配一次权限，来多少销售都直接赋予他们这个角色就可以，突然想到类和实例……
**用户 User：**系统的使用者。
**角色 Role：**一个权限的集合，往往代表一类职责或者岗位。
**权限 Permission：**对系统资源的具体操作许可，是权限控制的最小单元。
RBAC1-角色继承 Role Hierarchy
角色之间可以存在继承关系，子角色可以继承父角色的所有权限（和类高度相似……）
避免了重复分配权限，设计更优雅。
RBAC2-责任分离规则 Constraints
引入了一些约束条件来保证安全。
角色互斥：同一个用户不能被赋予两个互斥的角色。（这个和实例不一样了）
基数约束：一个角色被分配用户数量有限。
先决条件角色：要分配角色A，用户必须已经拥有角色B。
RBAC3-RBAC1+RBAC2
简单设计四个角色：超级管理员、数据分析员、销售主管、销售。
超级管理员 Super Admin：
系统拥有者或者核心IT负责人。
管理系统的一切，包括用户账户、角色权限、系统全局设置等等。
数据分析员 Data Analyst：
后台人员，不参与销售过程，但是需要获取数据进行销售分析。
查看、导出、分析公司的销售数据，生成报告，只能看，不能修改。
销售主管 Sales Manager：
销售团队管理者。
管理团队成员，查看团队绩效、分配资源、协助下属跟进客户等。
销售人员 Sales Representative：
一个伟大而可怜的一线销售。
跟进客户，推动成交。
Django实际上自带相应的权限管理，之前只是尝试使用了一下，但是并没有深入。这儿简单整理一下。
Django权限系统核心机制是由User、Group和Permission组成，其实就是把角色换成了组的概念。
当我们创建模型，比如我之前创建的客户模型，Django会自动给每个模型创建4个默认权限，增删改查。
add_<modelname>(e.g., add_customer)
change_<modelname>(e.g., change_customer)
delete_<modelname>(e.g., delete_customer)
view_<modelname>(e.g., view_customer)
这些权限存储在auth_permission表中，并通过content_type_id关联到django_content_type表。
不过Django里面可以把权限直接给用户，这是特殊以及非常细粒度的控制。常规情况下还是通过组来分配权限。
视图装饰器：我们之前在视图里写过一个登录权限啥的，那个装饰器@login_required就是一个权限控制方式。或者@permission_required('crm.change_customer', raise_exception=True)，只有具备crm.change_customer权限的用户才能执行这个视图。
基于类的视图混入：
from django.contrib.auth.mixins import PermissionRequiredMixin, LoginRequiredMixin
from django.views.generic import UpdateView
class CustomerUpdateView(LoginRequiredMixin, PermissionRequiredMixin, UpdateView):
model = Customer
form_class = CustomerForm
permission_required = 'crm.change_customer' # 可以是一个权限字符串或列表
# raise_exception = True # 默认是 False (重定向到登录页)，True 则抛出 PermissionDenied (403)
在模板中检查：
{% if perms.crm.change_customer %}
<a href="{% url 'edit_customer' customer.id %}">Edit</a>
{% endif %}