用户模型
认证包括 验证 和 授权
这些操作都是围绕着 用户表 的操作,因此第一步是先确定 用户表
默认的用户表一般满足不了实际的需求,这时我们可以
- 扩展,利用 一对一 关联 User 模型。
- 取代 User 表,User 表是继承自 AbstractUser,我们也可以直接继承来自定义我们的表字段,不过别忘记在设置里定义
- 完全自定义,AbstractUser 继承自 AbstractBaseUser 和 PermissionsMixin,而他们又都继承自 models.Model。 因此我们完全可以直接自定义我们自己的 用户表,不过这样会增加很多工作量。具体可参考 官方的源码。
一般情况下可以使用第2种方式,可以复用框架大量的便利的实现。以下是按照 2 的情况。
认证后端
认证后端处理 用户验证 和 权限验证。
默认设置下 AUTHENTICATION_BACKENDS = ['django.contrib.auth.backends.ModelBackend']
,认证后端可以有多个,
当有多个认证后端时 django 会依次尝试验证直到所有后端都被尝试。
我们也可以自定义认证后端。认证代码类似下面这样
1 |
|
- 处理用户验证
authenticate 方法应该在验证通过后返回一个 user 对象,否则返回 None。 - 处理授权
用户模型会把权限查找函数(get_group_permissions(), get_all_permissions(), has_perm(), and has_module_perms()) 委托给任何实现了这些函数的验证后端。这些函数在django.contrib.auth.backends.ModelBackend
都已实现,我们只需继承就好了
分组和权限
对于 2 这种方式,AbstractUser 继承自 AbstractBaseUser 和 PermissionsMixin,我们的用户模型又继承自 AbstractUser,因此也会 继承 AbstractBaseUser 和 PermissionsMixin。让我们看看在这三个类中发生了什么。 首先 AbstractBaseUser 和 AbstractUser 定义了 一些 必须的字段,password、email 等;引入了 UserManager ;还有一些方法。 而 PermissionsMixin 定义了 两个 多对多 字段,一个是 groups 关联 Group 模型;另一个是 user_permissions 关联 Permission 模型。 继续挖 Permission 模型,发现其 和 ContentType 是 多对一 的关系,结合 文档的一段话:
当 INSTALLED_APPS 设置了 django.contrib.auth 时,它将确保你的每个 Django 模型被创建时有四个默认权限:添加、修改、删除和查看。
运行 manage.py migrate 时将创建这些权限。当你添加 django.contrib.auth 到 INSTALLED_APPS 后第一次运行 迁移 , 将会为所有只去已经安装过的模型以及现在正在安装的模型创建这些默认的权限。之后,每次你运行 manage.py migrate 都会为 新模型创建默认权限 (创建权限的函数连接 post_migrate 信号)。
默认权限就是这么来的。
我们也可以自定义我们的权限,示例如下:
1 |
|
这会在 migrate 时写到 Permission 表中。
详细实现可参考官方文档
主要涉及的代码文件:
django.contrib.auth.backends.py
和django.contrib.auth.models.py
1 |
|
1 |
|