【问题标题】:How to separate users (models) by admins and customers on Django如何在 Django 上按管理员和客户分隔用户(模型)
【发布时间】:2016-01-12 12:17:23
【问题描述】:

我想将我的 Django 应用程序的用户分为两个类:
- Admin(使用 Django admin 的用户)- 继承自 AbstractUser
- 用户(客户用户)- 继承自 AbstractBaseUser

我想将这两种用户分开,因为AbstractUseris_staffis_superusergroupspermissions)的所有字段对我的客户用户和权限和组都没用,我只是想要实现一些不同的东西。这就是为什么,我想使用AbstractBaseUser

但是对于 django 管理员用户,AbstractUser 类,它只是完美的,特别是具有权限功能。

class Admin(AbstractUser):
    pass

class Customer(AbstractBaseUser):
    pass

但是现在,有没有办法精确使用 Admin 的用户模型仅用于 django 管理员? 并将Customer 模型用于我的其余应用程序。

我必须从头开始实现吗:

class MyUser(AbstractBaseUser):
    username = models.CharField(max_length=30, unique=True)
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    email = models.EmailField()
    is_active = models.BooleanField(default=False)

class Admin(MyUser, PermissionsMixin):
    is_staff = models.BooleanField(default=True)


class Customer(MyUser):
    # specific fields
    pass

通过这个实现,如果我将AUTH_USER_MODEL 设置为User,权限将不起作用,因为User 没有permissionsis_superuseris_staff 字段。

如果将其设置为Admin,我将无法使用django.contrib.auth 验证Customers

那么各位大侠有解决这个问题的办法吗?

【问题讨论】:

  • 拥有两个独立的模型肯定会破坏contrib.authcontrib.admin,无论您的request.user 是否包含UserAdmin。是否有任何客观原因反对让一个基本 User 模型具有两个“配置文件”OneToOne 字段?如果某些字段对您的某些用户组无用,请不要使用它们,毕竟您没有义务这样做。或者您担心性能问题?
  • TY 回复人。正如我所说:“我想将这两种用户分开,因为AbstractUseris_staffis_superusergroupspermissions)的所有字段对我的客户用户以及权限和组都没有用,我只是想实现一些不同的东西。所以,我想使用AbstractBaseUser。”如果客户有两种权限和组,那将是一团糟。我对 Django 很陌生,也许我错了,这是不可能的。我只想要一些高效和干净的东西。
  • 嗯,关键是您的用户不必拥有两组权限。唯一的权限“容器”在User 模型中。如果您的用户是管理员,则他设置了 is_staff 并分配了适当的权限。如果他是客户,那么is_staffFalse 并且他的权限只是不同(您可以并且可能会想要为不同类型的客户设置一些权限),或者可能为空。例如,这使您能够使客户成为管理员,反之亦然。抱歉,cmets 有长度限制,也许我应该整理一个答案:)。
  • 如果您找到了解决方案,可以在这里分享一下吗?

标签: python django django-models django-admin


【解决方案1】:

Django 为您提供的方式似乎更加灵活和适应未来。

  1. 您有一个内置的User 模型,您可以覆盖它。无论如何,该模型具有权限、组等。
  2. 如果您需要为不同类型的用户设置不同的字段集,您可以创建一个OneToOne 配置文件模型。
  3. 您的管理员(实际上是员工用户)和普通客户之间的分隔点是 User.is_staff 属性。

这样你可以获得一堆很酷的东西(与两个完全不同的用户模型相比):

  • 一切开箱即用contrib.authcontrib.admin 模块。
  • 易于自定义的分隔点:只需覆盖 admin_site.has_permission() 即可。
  • 您有能力(但没有义务)创建客户和管理员的用户。
  • 您可以将组和权限(不同于您的管理员)分配给您的客户。即使你现在也不需要它,谁知道呢。

至于缺点。到目前为止,您唯一指出的是:您的客户将拥有(暂时未使用)权限。好吧,由于它们(以及组)只是单独的表,因此您的客户数据不会有存储开销。

也就是说,与收益相比,开销可以忽略不计。我强烈建议使用 Django 的默认 User 模型并在必要时对其进行扩展。

【讨论】:

  • 您没有仔细阅读我的问题,我的客户将拥有权限和组,但与django.contrib.auth 提供的不同。目前我想做的事情是不可能的,那么我将创建一个从PermissionsMixinAbstractBaseUser 继承的User 类,并使用不同的名称来存储组和权限。
  • 对不起,我绝对应该更仔细地阅读这个问题。乍一看(以及一些连续的),我以为您只是不想让那些字段存在。我想的唯一方法是将您的自定义组和权限实现为链接到User 类的单独Customer“配置文件”模型的字段。因此,对于您的客户视图,您将检查 request.user.customer.groups 之类的内容。
  • profile或者继承方式,还没决定,我会考虑一下
  • @LouisBarranqueiro 3 年后你回来在这里回复评论;)?你决定了吗?我也想知道,因为我现在正在研究它
猜你喜欢
  • 2022-06-14
  • 2019-07-05
  • 2011-01-15
  • 1970-01-01
  • 1970-01-01
  • 2012-08-07
  • 2013-06-26
  • 2021-03-05
  • 2018-01-21
相关资源
最近更新 更多