django-allauth 2015 年版本演进全解：从 Django 1.6 兼容到 OAuth 定制化配置

后端认证鉴权身份认证【免费下载链接】django-allauthIntegrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication. Mirror of https://codeberg.org/allauth/django-allauth/项目地址https://gitcode.com/gh_mirrors/dj/django-allauth点击查看免费下载本文以 django-allauth 仓库的 docs/release-notes/2015.rst 为脉络系统梳理 2015 年 0.19.0 至 0.24.1 六个版本的技术演进涵盖密码修改/重置行为策略ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE、ACCOUNT_LOGIN_ON_PASSWORD_RESET、OAuth/OAuth2 每 Provider 认证参数定制、Facebook Graph API 版本与字段配置、Email 确认流程适配器扩展点以及 SocialApp/SocialAccount 字段长度与迁移的兼容性处理。读完本文你将掌握这些历史配置项与扩展点的来龙去脉并能在当前版本的源码中找到它们的对应实现从容应对升级与定制需求。为什么 2015 年的发行说明仍然值得读2015 年是 django-allauth 从 Django 1.6 走向 Django 1.9、从 Python 2.6 走向 Python 3 的关键过渡期。这一年的每个版本都引入了影响至今的架构决策行为策略配置化密码修改后是否登出、密码重置后是否自动登录都从硬编码行为变成可由settings控制的策略适配器Adapter扩展点规范化Email 确认 URL 的生成与确认邮件的发送被抽取为可覆写的方法字段长度与数据库兼容性为适配 MySQL utf8mb4 而调整uid长度并引入SOCIALACCOUNT_UID_MAX_LENGTH可配置项模板机制演进废弃模板上下文处理器context processors转为模板标签{% get_providers %}迁移管理转折将原有迁移迁入south_migrations与 Django 内置迁移体系接轨。以下按时间倒序逐版本展开。0.24.x修复依赖问题与密码修改登出策略0.24.12015-11-09非测试代码误依赖测试包0.24.1 是紧随 0.24.0 后的修复版。发行说明明确指出Non-test code accidentally had test packages as a dependency即非测试代码意外地将测试包列为依赖。这提醒我们在发布前应检查setup.py/pyproject.toml中的依赖声明避免把仅测试用的包带入生产安装环境。0.24.02015-11-08Django 1.9b1 兼容与 uid 长度调整0.24.0 完成 Django 1.9b1 兼容并引入两项社区贡献芬兰语翻译、Basecamp Provider同时带来一项重要的向后不兼容变更。SocialAccount.uid 长度收窄至 191 字符为了兼容 MySQL 在 utf8mb4 字符集下的索引限制SocialAccount.uid的最大长度被收窄到 191 字符此前更长而SocialApp的 key/secret/token 字段则增加到 191 字符。由于uid需要存储 OpenID URL理论上可能超过 191 字符因此引入了可配置项# settings.py SOCIALACCOUNT_UID_MAX_LENGTH 191 # 默认值按需调整从当前源码看这一设置在迁移与校验两个层面都有落点allauth/socialaccount/migrations/0001_initial.py 与 0002_token_max_lengths.py 通过getattr(settings, SOCIALACCOUNT_UID_MAX_LENGTH, 191)读取该配置生成字段allauth/socialaccount/providers/base/provider.py 在 Provider 层校验uid长度若设置值过小会抛出SOCIALACCOUNT_UID_MAX_LENGTH too small ({len(uid)})的异常。因此升级时如果自定义过该配置需同步检查迁移状态0.24.0 已自带迁移文件。0.23.02015-08-02密码重置后自动登录0.23.0 新增 Edmodo Provider并引入ACCOUNT_LOGIN_ON_PASSWORD_RESET设置密码重置完成后是否自动登录用户。当前实现位于 allauth/account/app_settings.py默认值为Falsedef LOGIN_ON_PASSWORD_RESET(self) - bool: return self._setting(LOGIN_ON_PASSWORD_RESET, False)该设置同样被 headless API 文档引用见 allauth/headless/spec/doc/openapi.yaml说明它不仅影响传统模板流程也影响 headless 接口的密码重置行为。0.22.02015-07-23适配器扩展点与 Facebook 配置化0.22.0 是 2015 年架构影响最深远的一个版本涉及 Email 确认流程、模板机制和 Facebook Graph API。Email 确认 URL 与确认邮件的适配器扩展点发行说明宣布Email 确认 URL 的反转reversal可以在适配器中覆写get_email_confirmation_url完整确认邮件处理流程也可通过send_confirmation_mail覆写。这两点在当前 allauth/account/adapter.py 中仍然是标准扩展点def get_email_confirmation_url(self, request, emailconfirmation) - str: Constructs the email confirmation (activation) url. from allauth.account.internal import flows return flows.email_verification.get_email_verification_url(request, emailconfirmation) def should_send_confirmation_mail(self, request, email_address, signup) - bool: return True def send_confirmation_mail(self, request, emailconfirmation, signup) - None: # 根据 EMAIL_VERIFICATION_BY_CODE_ENABLED 决定邮件内容 # - 验证码模式注入 code # - 链接模式注入 key 与 activate_url ...调用链可以在 allauth/account/internal/flows/email_verification.py 与 allauth/account/models.py 中找到模型层的EmailAddress与内部流程都会通过get_adapter().send_confirmation_mail(...)发送邮件。自定义实现时覆写get_email_confirmation_url即可改变激活链接的生成规则如需完全接管邮件内容则覆写send_confirmation_mail。模板上下文处理器退出历史舞台0.22.0 起模板上下文处理器context processors不再被使用allauth.account的上下文处理器原本就是空的而allauth.socialaccount的上下文处理器被转换为{% get_providers %}模板标签。当前实现位于 allauth/socialaccount/templatetags/socialaccount.py模板中按如下方式使用{% load socialaccount %} {% get_providers as socialaccount_providers %}这意味着依赖旧上下文处理器注入变量的自定义模板需要迁移到模板标签语法。Facebook Graph API 版本与字段可配置0.22.0 引入 Facebook Graph API 字段可配置Provider 的FIELDS设置0.19.0 则引入 Graph API 版本可配置SOCIALACCOUNT_PROVIDERS中的VERSION。当前实现allauth/socialaccount/providers/facebook/constants.py 从SOCIALACCOUNT_PROVIDERS[facebook][VERSION]读取版本默认v19.02015 年时默认为 v2.4allauth/socialaccount/providers/facebook/provider.py 通过settings.get(FIELDS, default_fields)返回/me请求的字段列表allauth/socialaccount/providers/facebook/views.py 使用该版本拼接 OAuth dialog 与 Graph API URL。配置示例SOCIALACCOUNT_PROVIDERS { facebook: { VERSION: v19.0, APP: {...}, FIELDS: [ id, first_name, last_name, middle_name, name, name_format, picture, short_name, ], } }平台支持收缩Python 2.6 与 Django 1.6 告别0.22.0 正式放弃 Python 2.6 与 Django 1.6 以下的兼容支持。这与同年 Django 1.82015-04-01 发布引入的EmailField254 字符上限变化相呼应——后者在 0.20.0 中已跟进。0.21.02015-07-02OAuth 每 Provider 认证参数与迁移修正OAuth Provider 认证参数可定制0.21.0 允许像 OAuth2 那样按 Provider 定制 OAuth 认证参数。这意味着对于使用 OAuth 1.0 协议的 Provider开发者也可以在其 Provider 定义中调整认证阶段发送的参数而不必覆写整个流程。新增设置ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE0.21.0 新增ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE设置由社区贡献用于控制修改密码后是否登出用户。该设置在 0.24.1 中被进一步明确使用社交账号登录后设置初始密码或修改密码默认不再登出用户Django 1.7。当前实现位于 allauth/account/app_settings.pydef LOGOUT_ON_PASSWORD_CHANGE(self) - bool: return self._setting(LOGOUT_ON_PASSWORD_CHANGE, False)实际消费该设置的核心流程是 allauth/account/internal/flows/password_change.pyif not app_settings.LOGOUT_ON_PASSWORD_CHANGE: # 修改密码后保持登录态 else: # 修改密码后清除会话并重新认证此外 allauth/usersessions/signals.py 也引用该设置当ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE False时密码修改不会导致其他设备上的用户会话被注销。官方文档 docs/account/configuration.rst 明确其默认值为False示例项目 examples/react-spa/backend/backend/settings.py 中也显式声明了该值。迁移修正0002_email_max_length 的 unique 副作用0.20.0 引入的account迁移0002_email_max_length在调整 email 字段长度时意外将uniqueTrue硬编码了进去而 email 是否唯一实际上取决于ACCOUNT_UNIQUE_EMAIL设置。由于在 email 不唯一的安装上运行0002可能失败维护者无法简单地追加一个0003修正迁移只能修改既有迁移通常不推荐。当前ACCOUNT_UNIQUE_EMAIL的实现见 allauth/account/app_settings.py默认值为Truedef UNIQUE_EMAIL(self) - bool: return self._setting(UNIQUE_EMAIL, True)升级指引针对已运行过旧0002的安装若ACCOUNT_UNIQUE_EMAIL True无需额外操作若ACCOUNT_UNIQUE_EMAIL False且迁移0002已执行先将迁移回退到0001--fake再重新执行修正后的0002python manage.py migrate account 0001 --fake python manage.py migrate account 00020.20.02015-05-25Email 字段长度随 Django 1.8 上调至 254Django 1.8 将EmailField的max_length上调至 254django-allauth 跟进调整并随版本提供account迁移。这也是 0.21.0 迁移修正问题的来源。该版本还新增了 Evernote、SpotifyOAuth2、DropboxOAuth2、Douban 等 Provider。当前迁移链可以在 allauth/account/migrations/ 目录下看到完整演进0001_initial→0002_email_max_length→0003_alter_emailaddress_create_unique_verified_email→0004_alter_emailaddress_drop_unique_email→0005_emailaddress_idx_upper_email→0006_emailaddress_lower→0007_emailaddress_idx_email→0008_emailaddress_unique_primary_email_fixup→0009_emailaddress_unique_primary_email。其中0002正是 0.20.0 引入的 email 长度迁移后续0003/0004则围绕 email 唯一性约束的演进对应ACCOUNT_UNIQUE_EMAIL与已验证 email 唯一策略。0.19.12015-02-05South 与 Django 1.6 的迁移修复0.19.1 修复了使用 South 与 Django 1.6 时的迁移问题。这是 Django 1.7 引入内置迁移框架后第三方应用处理新老迁移体系并存的典型时期。0.19.02015-01-04安全、灵活性与迁移体系重构新增 Provider 与翻译0.19.0 新增 Odnoklassniki、Firefox Accountsfxa、Coinbase 等 Provider并补充斯洛伐克语、台湾繁体中文翻译。这些 Provider 在当前的 allauth/socialaccount/providers/ 目录中均有对应实现odnoklassniki/、fxa/、coinbase/。Facebook JS SDK 不可用时的回退当浏览器插件如 Disconnect.me屏蔽 Facebook JS SDK 时登录流程会自动回退到非 JS 的标准握手流程保证功能可用性。is_safe_url 可覆写is_safe_url被开放为适配器方法便于开发者按需覆写安全 URL 校验逻辑。当前实现位于 allauth/account/adapter.py。自定义密码规则clean_password0.19.0 引入通过clean_password支持自定义密码规则的能力。当前实现位于 allauth/account/adapter.py并被多个入口复用allauth/account/fields.py密码字段的clean阶段调用适配器校验allauth/account/forms.py 与 allauth/headless/account/inputs.py表单层与 headless 输入层均委托get_account_adapter().clean_password(password)。配合ACCOUNT_PASSWORD_MIN_LENGTH见 allauth/account/app_settings.py默认 6与自定义clean_password可以实现长度之外的密码复杂度策略如必须包含数字/大小写。迁移迁入 south_migrations所有既有迁移被移入south_migrations包避免与 Django 内置迁移冲突South 1.0 会自动识别新位置。仍依赖这些迁移的安装需要升级 South。行为统一非活跃用户的登录响应此前社交登录在User.is_active False时跳转/accounts/inactive/而本地登录却报表单校验错误。0.19.0 消除了这一不一致本地登录同样跳转/accounts/inactive/。当前对应实现是适配器的respond_user_inactive见 allauth/account/adapter.py默认返回account_inactive重定向。不兼容变更SocialLogin 对象属性访问面向 Django 1.8 的调整不能再把未保存unsaved的User实例挂接到SocialAccount。因此检查sociallogin对象时应使用sociallogin.user而非sociallogin.account.user。这是从当前 allauth/socialaccount/internal/flows/ 流程中先保存用户再关联社交账号的标准做法的历史源头。不兼容变更ResetPasswordForm.save 签名覆写ResetPasswordForm时save方法现在以request作为第一个参数自定义表单需同步更新签名。升级与迁移速查表版本关键设置/扩展点默认值/说明当前源码位置0.24.0SOCIALACCOUNT_UID_MAX_LENGTH191受 MySQL utf8mb4 索引限制0001_initial.py、provider.py0.23.0ACCOUNT_LOGIN_ON_PASSWORD_RESETFalseapp_settings.py0.22.0get_email_confirmation_url/send_confirmation_mail适配器覆写点adapter.py0.22.0FacebookVERSION/FIELDS版本默认v19.0当时 v2.4facebook/constants.py、facebook/provider.py0.21.0ACCOUNT_LOGOUT_ON_PASSWORD_CHANGEFalseapp_settings.py、password_change.py0.21.0ACCOUNT_UNIQUE_EMAILTrue迁移 0002 修正app_settings.py0.20.0Email 字段长度 254Django 1.8迁移0002_email_max_lengthallauth/account/migrations/0.19.0clean_password/is_safe_url适配器方法adapter.py、adapter.py从 2015 到当前版本这些特性如何延续将 2015 年的发行说明与当前源码对照可以清晰看到设计延续性适配器Adapter成为唯一扩展面Email 确认、密码校验、安全 URL 校验、非活跃用户响应等全部收敛为 allauth/account/adapter.py 上的可覆写方法业务代码不再直接修改视图/表单内部逻辑行为策略全面配置化ACCOUNT_LOGIN_ON_PASSWORD_RESET、ACCOUNT_LOGOUT_ON_PASSWORD_CHANGE、ACCOUNT_UNIQUE_EMAIL等 2015 年引入的设置如今在 allauth/account/app_settings.py 中统一通过_setting机制读取并同步影响 headless API 与传统模板流程Provider 生态持续扩张2015 年新增的 Baidu、Basecamp、Edmodo、Evernote、Spotify、Odnoklassniki、Firefox Accounts、Coinbase、Douban 等 Provider 至今仍保留在 allauth/socialaccount/providers/ 目录中OAuth 与 OAuth2 的参数定制能力已成为 Provider 开发的基础能力迁移体系彻底现代化south_migrations只是过渡当前所有迁移均为 Django 原生迁移格式见 allauth/account/migrations/ 与 allauth/socialaccount/migrations/历史遗留问题如 0002 的 unique 副作用已通过后续迁移与数据库约束演化解决。对于正在维护老版本安装的开发者建议按以下顺序升级先处理 0.21.0 的迁移修正如需再依次验证 0.22.0 的模板标签迁移与适配器覆写点、0.24.0 的 uid 长度与数据库索引最后对照 docs/release-notes/ 中后续年份的发行说明逐步推进到当前版本。赞分享后端认证鉴权身份认证【免费下载链接】django-allauthIntegrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication. Mirror of https://codeberg.org/allauth/django-allauth/项目地址https://gitcode.com/gh_mirrors/dj/django-allauth点击查看免费下载相关推荐告别物理束缚Parsec VDD虚拟显示驱动实战指南告别物理束缚Parsec VDD虚拟显示驱动实战指南 你是否曾为远程服务器没有显示器而烦恼是否想在笔记本上扩展更多屏幕却受限于物理接口Parsec VDD后端认证鉴权身份认证在 React Native 中使用 Lucide 图标库lucide-react-native 包安装、API 与源码原理全解析在 React Native 中使用 Lucide 图标库lucide react native 包安装、API 与源码原理全解析 导读 lucide rea后端认证鉴权身份认证notebooklm-py 的 Session/Kernel 拆分ADR-0010 三分契约设计与能力组合架构的演进notebooklm py 的 Session/Kernel 拆分ADR 0010 三分契约设计与能力组合架构的演进 本篇文章基于开源仓库 notebookl后端认证鉴权身份认证上一篇Area51云存档API错误码含义与解决方法下一篇从零到一Mone云原生研发平台完整指南 - 如何构建企业级敏捷研发体系创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考