Django + Pymongo 自研用户模块如何生成账户确认与密码重置临时链接

1. 未使用Django内置User模型，也可直接复用其token生成器 #

PasswordResetTokenGenerator从设计上就没有绑定Django的ORM体系，你完全可以在自定义的pymongo用户逻辑里直接使用，和选择什么数据库没有任何关系。
常见认知误区是必须继承AbstractBaseUser才能使用这套逻辑，本质是把Django自带的认证视图和token生成逻辑混为一谈——实际上token生成器的核心运行流程全程没有数据库查询，只需要从传入的用户对象上读取三个属性：

• 用户的唯一标识（对应Django的pk属性）
• 用户存在库中的密码哈希字符串（对应Django的password属性）
• 用户的激活状态标识（对应Django的is_active属性）

落地实现步骤 #

• 不需要修改现有pymongo的CRUD逻辑，只要在拿到Mongo用户文档的查询结果后，用简单的类对结果做包装，把上面三个属性映射为同名字段即可
• 可以自定义子类，针对不同场景的token（永不过期的账户确认链接、有时效的密码重置链接）调整哈希逻辑，示例代码：

from django.contrib.auth.tokens import PasswordResetTokenGenerator

class CustomTokenGenerator(PasswordResetTokenGenerator):
    # 重写哈希生成逻辑，实现永不过期的账户确认token
    def _make_hash_value(self, user, timestamp):
        # 移除时间戳参数参与哈希计算
        return (
            str(user.pk) 
            + user.password 
            + str(user.is_active)
        )

# 实例化生成器
custom_token_gen = CustomTokenGenerator()

# 生成账户确认链接的token（永不过期）
confirm_token = custom_token_gen.make_token(user_obj)
# 生成密码重置链接的token（保留Django默认时效逻辑，默认3天有效）
reset_token = super().make_token(user_obj)

• 校验token时直接调用check_token(user_obj, token)方法即可，安全性和Django原生实现完全一致，因为哈希算法、密钥绑定逻辑和官方没有区别。

2. 自行实现同等安全级别的临时链接方案 #

如果不想依赖Django的auth模块，只要对齐它的三个核心安全设计，就能达到同等安全强度，不要随意拿用户名加盐做哈希：
Django原生token的安全核心逻辑：

• 哈希输入混入仅服务端知道的密码哈希值：就算用户名是半公开信息，攻击者也拿不到用户的密码哈希，无法逆向算出合法token
• 哈希计算使用项目SECRET_KEY作为HMAC密钥：不是无密钥的普通哈希，就算公开算法逻辑，攻击者没有SECRET_KEY也无法伪造token
• 时效类token采用时间窗口切片设计：避免短时间内被暴力枚举，同时解决跨时间边界的校验问题

具体实现参考 #

• 永不过期的账户确认链接：将用户Mongo主键、密码哈希、固定的应用专属盐值，通过带SECRET_KEY的HMAC算法生成哈希值作为token，拼接在链接里。这种实现下，只要用户没有修改密码，token就永久有效；用户改密码、完成账户激活后旧token自动失效，符合安全预期
• 3天有效期的密码重置链接：在哈希输入中混入一个按3天为粒度的时间戳切片（即当前时间戳除以3243600取整数），校验时对比当前时间对应的切片值，与token生成时的切片差值超过1个窗口即判定为过期

常见安全坑 #

• 不要用仅包含用户ID、用户名的无密钥哈希做token，这类实现可以被批量伪造
• 不要把原始token作为唯一校验依据，必须绑定对应的用户ID信息，避免跨用户的token越权

• 纯pymongo手写CRUD的方案本身没有硬伤，如果你对Mongo的查询逻辑有定制化要求，不想被ODM的抽象层限制，这种实现完全可行。但如果后续需要快速接入Django的生态功能（内置认证视图、权限系统、Admin后台），会需要额外做不少适配工作。
• 不需要为了使用Django的token生成器特意切换到mongoengine：token生成逻辑和ORM没有绑定，现有pymongo代码零改动就能接入。
• 关于mongoengine的选型误区：就算切换到mongoengine，也无法直接无缝使用Django的内置User模型——Django的内置User是绑定SQL ORM的，mongoengine是独立的Mongo ODM，和Django ORM是两套体系。目前社区里的Mongo适配Django auth的插件，往往存在版本兼容性差、维护不及时的问题，不建议为了适配auth体系特意切换。
• 如果项目还处于非常早期的阶段，可以结合需求做选型：需要最小成本接Django生态的话，直接用关系型数据库配Django ORM是最省心的；如果确定要长期用Mongo，纯pymongo或者mongoengine都可以，不要对无缝接Django内置auth有过高预期。

内容的提问来源于stack exchange，提问作者saigammar