Django自定义用户模型下多场馆多权限认证授权方案合理性确认

嘿，你的这个思路不仅没问题，反而非常贴合多场馆权限隔离的实际需求——我之前在类似的场馆管理系统里也用过几乎一样的设计，给你拆解下为什么可行，以及几个可以优化的小细节：

核心逻辑的合理性 #

你设计的「用户关联多场馆+场馆级权限」模式，正好命中了多租户（这里的租户就是场馆）场景下的权限隔离需求：

• 不同场馆的权限相互独立，避免用户在A场馆的权限影响到B场馆，这是这类系统的核心要求；
• venue_id设为null的设计也非常必要，完美覆盖了全局权限用户的场景（比如超级管理员、平台运营），他们不需要绑定特定场馆就能拥有全平台的操作权限。

从Django的模型设计原则来看，这种关联方式完全符合ORM的设计逻辑，ForeignKey设置null=True, blank=True是标准的可选关联实现方式。

模型结构的参考示例 #

给你一个更具体的模型实现参考，帮你把思路落地：

from django.db import models
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager

# 先定义场馆模型
class Venue(models.Model):
    name = models.CharField(max_length=100, verbose_name="场馆名称")
    address = models.TextField(verbose_name="场馆地址")
    # 可以根据需求添加更多字段，比如联系方式、营业时间等

# 自定义用户管理器（必须的，因为用了AbstractBaseUser）
class CustomUserManager(BaseUserManager):
    def create_user(self, email, username, password=None, **extra_fields):
        if not email:
            raise ValueError("必须提供邮箱")
        email = self.normalize_email(email)
        user = self.model(email=email, username=username, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_superuser(self, email, username, password=None, **extra_fields):
        extra_fields.setdefault('is_staff', True)
        extra_fields.setdefault('is_superuser', True)
        return self.create_user(email, username, password, **extra_fields)

# 自定义用户模型
class CustomUser(AbstractBaseUser):
    email = models.EmailField(unique=True, verbose_name="邮箱")
    username = models.CharField(max_length=50, unique=True, verbose_name="用户名")
    is_active = models.BooleanField(default=True, verbose_name="是否激活")
    is_staff = models.BooleanField(default=False, verbose_name="是否为员工")
    
    # 通过中间表关联场馆和权限
    venues = models.ManyToManyField(Venue, through='UserVenuePermission', related_name='related_users')

    objects = CustomUserManager()

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['username']

# 核心的用户-场馆权限关联表（就是你说的权限表）
class UserVenuePermission(models.Model):
    user = models.ForeignKey(CustomUser, on_delete=models.CASCADE, verbose_name="关联用户")
    venue = models.ForeignKey(Venue, on_delete=models.CASCADE, null=True, blank=True, verbose_name="关联场馆")
    
    # 权限级别用choices定义，清晰直观
    PERMISSION_LEVELS = [
        ('view', '查看权限'),
        ('edit', '编辑权限'),
        ('manage', '管理权限'),
        ('global_admin', '全局管理员'),
    ]
    permission_level = models.CharField(max_length=20, choices=PERMISSION_LEVELS, verbose_name="权限级别")

    class Meta:
        # 关键约束：同一个用户在同一个场馆下只能有一条权限记录，全局权限（venue=null）也只能有一条
        unique_together = ('user', 'venue')
        verbose_name = "用户-场馆权限"
        verbose_name_plural = "用户-场馆权限"

权限检查的实现建议 #

为了方便在视图、模板里快速判断权限，可以写一个工具函数：

def check_venue_permission(user, venue_id=None, required_level='view'):
    # 先判断是否有全局管理员权限
    if UserVenuePermission.objects.filter(
        user=user, 
        venue__isnull=True, 
        permission_level='global_admin'
    ).exists():
        return True
    
    # 如果指定了场馆，检查对应场馆的权限
    if venue_id:
        permission = UserVenuePermission.objects.filter(
            user=user, 
            venue_id=venue_id
        ).first()
        if not permission:
            return False
        
        # 定义权限优先级，方便比较
        permission_rank = {
            'view': 1,
            'edit': 2,
            'manage': 3,
            'global_admin': 4
        }
        return permission_rank[permission.permission_level] >= permission_rank[required_level]
    
    # 没有指定场馆且不是全局管理员，返回False
    return False

在视图里使用的例子：

from django.http import HttpResponseForbidden
from django.shortcuts import render

def venue_management(request, venue_id):
    if not check_venue_permission(request.user, venue_id, 'manage'):
        return HttpResponseForbidden("你没有该场馆的管理权限")
    # 后续的场馆管理逻辑...
    return render(request, 'venue/management.html', {'venue_id': venue_id})

几个需要注意的细节 #

1. 权限约束的完整性：一定要加上unique_together = ('user', 'venue')，避免同一个用户在同一个场馆下出现多条权限记录，导致权限判断混乱；
2. 权限级别的扩展性：如果后续需要更细分的权限（比如单独的「设备管理权限」「订单管理权限」），可以把权限拆成单独的Permission模型，用多对多关联到UserVenuePermission，这样更灵活；
3. 和Django内置权限的兼容：如果需要使用Django admin的内置权限，可以让CustomUser继承PermissionsMixin，然后全局权限用内置的is_superuser，场馆级权限用自定义的表，这样既兼容admin，又满足业务需求。

总的来说，你的思路完全正确，这种设计既满足了多场馆的权限隔离，又支持全局权限的场景，是非常实用的方案！

内容的提问来源于stack exchange，提问作者amazing carrot soup