后端认证鉴权身份认证【免费下载链接】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 在社交账号social account的登录、绑定、更新与解绑全流程中会发出若干 Django 信号Signal开发者可以通过接收器receiver在这些关键节点挂接自己的业务逻辑。本文以仓库中 docs/socialaccount/signals.rst 为骨架结合 allauth/socialaccount/signals.py 的源码定义与触发位置逐一讲解pre_social_login、social_account_added、social_account_updated、social_account_removed四个信号的发送时机、携带参数、典型使用场景并给出可直接复制的订阅示例帮助你精准地在社交认证流程中插入自定义处理。一、信号总览四个信号分别对应哪个业务节点社交账号认证流程大体分为两类场景登录/注册用户通过第三方提供商认证后进入本地账号体系与连接/解绑在已登录状态下为本地账号挂接或移除第三方账号。四个信号分别覆盖了这些流程中的四个关键节点信号触发时机携带参数发送者senderpre_social_login用户成功通过社交提供商认证后、登录被完全处理之前request,socialloginSocialLoginsocial_account_added用户将社交账号连接到本地账号之后request,socialloginSocialLoginsocial_account_updated社交账号数据被更新之后request,socialloginSocialLoginsocial_account_removed用户将社交账号从本地账号解绑之后request,socialaccountSocialAccount所有信号都定义在 allauth/socialaccount/signals.py 中均为django.dispatch.Signal实例。注意四个信号的 sender 并不一致前三个以SocialLogin作为 sender而social_account_removed以SocialAccount作为 sender订阅时需分别对应。关于参数中的sociallogin它并非SocialAccount模型实例而是SocialLogin类实例。从 allauth/socialaccount/models.py 的类文档可以看到它代表一个正在登录过程中的社交用户封装了accountSocialAccount实例、token可选的SocialToken访问令牌、email_addresses从提供商获取的邮箱列表以及state等中间状态。因此你在pre_social_login中能够同时拿到访问令牌与用户画像信息。二、pre_social_login登录前的最后干预点2.1 信号语义allauth.socialaccount.signals.pre_social_login(request, sociallogin)官方文档的描述是该信号在用户成功通过社交提供商认证之后、登录流程被完全处理之前发送。它作为社交登录login、注册signup流程的一部分发出同样也会在为已有账号连接额外社交账号时发出。如果提供商支持访问令牌access token和资料信息profile information都会随sociallogin一并提供。2.2 源码中的发送位置与调用链该信号的发送位于 allauth/socialaccount/internal/flows/login.py 的pre_social_login()函数中def pre_social_login(request: HttpRequest, sociallogin: SocialLogin) - None: clear_pending_signup(request) assert not sociallogin.is_existing # nosec sociallogin.lookup() get_adapter().pre_social_login(request, sociallogin) signals.pre_social_login.send( senderSocialLogin, requestrequest, socialloginsociallogin )注意几个细节发送信号前会先调用sociallogin.lookup()即尝试按(provider, uid)查找是否已有对应的本地SocialAccount见_lookup_by_socialaccount找不到再按邮箱匹配_lookup_by_email。所以你在信号处理器中读取sociallogin.is_existing时能判断这是老用户再次登录还是全新用户。该函数被complete_login()调用同文件 login.py随后根据sociallogin.state中的process值分派到REDIRECT纯跳转、CONNECT连接已有账号或默认的_authenticate登录/注册流程。这意味着信号在流程分派之前发出无论最终走向登录还是连接pre_social_login都会先被触发。2.3 典型用途从 allauth/socialaccount/adapter.py 中同名 adapter 钩子的注释可以看到官方建议的两类典型用法拦截登录例如对特定提供商、特定邮箱域名的用户禁止登录通过抛出ImmediateHttpResponse来中止流程并返回自定义响应在登录落地前做业务预处理例如记录第三方会话、校验黑白名单、注入自定义用户数据等。# receivers.py from django.dispatch import receiver from allauth.socialaccount.signals import pre_social_login receiver(pre_social_login) def on_pre_social_login(sender, request, sociallogin, **kwargs): # 例如阻止来自特定提供商的登录 if sociallogin.account.provider blocked_provider: from django.core.exceptions import PermissionDenied raise PermissionDenied(This provider is not allowed.)信号处理器与 adapter 钩子同时存在的原因官方在 adapter 注释中给出明确说明从信号处理器内部干预流程是不好的做法——因为可能挂载了多个处理器且它们的执行顺序不确定。因此如果你需要在登录前中止流程应当覆写 adapter 的pre_social_login()钩子它先于信号执行如果你只是需要观察/记录而不干预或者需要多个模块各自响应则应使用信号。三、social_account_added账号绑定成功之后allauth.socialaccount.signals.social_account_added(request, sociallogin)该信号在用户将社交账号连接到本地账号之后发出。官方文档特别强调这是一个显式动作即用户主动执行连接操作不会因为社交账号的创建而自动调用——换言之首次通过社交登录自动注册生成SocialAccount时不会触发此信号。3.1 源码中的发送位置发送逻辑位于 allauth/socialaccount/models.py 的SocialLogin.connect()方法中def connect(self, request: HttpRequest, user: AbstractBaseUser) - None: self.user user self.save(request, connectTrue) signals.social_account_added.send( senderSocialLogin, requestrequest, socialloginself ) get_adapter().send_notification_mail( socialaccount/email/account_connected, self.user, context{ account: self.account, provider: self.account.get_provider(), }, )connect()的调用入口是 allauth/socialaccount/internal/flows/connect.py 的do_connect()当用户已登录且社交账号尚未绑定到任何本地用户时会走sociallogin.connect(request, request.user)分支。注意信号发送后还会发送一封账号已连接的通知邮件模板socialaccount/email/account_connected。3.2 典型用途绑定成功后往往需要做数据迁移或初始化例如from django.dispatch import receiver from allauth.socialaccount.signals import social_account_added receiver(social_account_added) def on_social_account_added(sender, request, sociallogin, **kwargs): # 从提供商资料中抽取头像并保存到本地用户 extra_data sociallogin.account.extra_data avatar_url extra_data.get(avatar_url) if avatar_url and sociallogin.user: sociallogin.user.profile.avatar_url avatar_url sociallogin.user.profile.save()四、social_account_updated数据刷新的通知allauth.socialaccount.signals.social_account_updated(request, sociallogin)该信号在社交账号数据被更新之后发出。官方文档指出两种情况会触发用户使用一个已经连接过的社交账号登录用户对已连接的社交账号再次执行 connect 流程。对处理extra_data很有价值——官方文档原文建议如果你需要为社交账号在更新时解包unpack额外的数据这个信号很有用。4.1 源码中的发送位置发送逻辑位于 allauth/socialaccount/models.py 的SocialLogin._lookup_by_socialaccount()中def _lookup_by_socialaccount(self) - bool: assert not self.is_existing # nosec try: a SocialAccount.objects.get( providerself.account.provider, uidself.account.uid ) # Update account a.extra_data self.account.extra_data self.account a self.user self.account.user a.save() signals.social_account_updated.send( senderSocialLogin, requestcontext.request, socialloginself ) self._store_token() return True except SocialAccount.DoesNotExist: return False当用户在登录时系统发现(provider, uid)已对应一个本地SocialAccount会把提供商返回的最新extra_data写回数据库并保存随后发出该信号并继续更新SocialToken_store_token。也就是说该信号是提供商侧资料已同步到本地的回执。4.2 典型用途from django.dispatch import receiver from allauth.socialaccount.signals import social_account_updated receiver(social_account_updated) def on_social_account_updated(sender, request, sociallogin, **kwargs): # 每次用户通过社交账号登录后同步最新资料到本地 email sociallogin.account.extra_data.get(email) if email and sociallogin.user: sociallogin.user.email email sociallogin.user.save()五、social_account_removed解绑完成之后allauth.socialaccount.signals.social_account_removed(request, socialaccount)该信号在用户将社交账号从本地账号断开之后发出。注意这里的第二个参数是socialaccountSocialAccount实例而不是socialloginsender 也是SocialAccount。5.1 源码中的发送位置发送逻辑位于 allauth/socialaccount/internal/flows/connect.py 的disconnect()函数中def disconnect(request: HttpRequest, account) - None: if account_settings.REAUTHENTICATION_REQUIRED: flows.reauthentication.raise_if_reauthentication_required(request) get_account_adapter().add_message( request, messages.INFO, socialaccount/messages/account_disconnected.txt, ) provider account.get_provider() account.delete() signals.social_account_removed.send( senderSocialAccount, requestrequest, socialaccountaccount ) get_adapter().send_notification_mail( socialaccount/email/account_disconnected, request.user, context{ account: account, provider: provider, }, )顺序值得注意先删除SocialAccount记录account.delete()再发送信号最后发送账号已断开通知邮件。因此在信号处理器中该SocialAccount已经不在数据库中了你拿到的是删除前的内存快照。若需要完整资料请在删除前自行缓存。此外disconnect()之前还有validate_disconnect()做安全校验同文件 connect.py如果这是用户最后一个第三方账号且SOCIALACCOUNT_ONLY开启、用户没有可用密码或没有已验证邮箱解绑会被拒绝并抛出校验错误——这些校验失败时social_account_removed自然不会发出。5.2 典型用途from django.dispatch import receiver from allauth.socialaccount.signals import social_account_removed receiver(social_account_removed) def on_social_account_removed(sender, request, socialaccount, **kwargs): # 清理与第三方账号绑定的本地缓存数据 provider socialaccount.provider uid socialaccount.uid # 例如注销远程回调、清理用户本地画像中的第三方关联字段 request.user.profile.connected_providers.remove(provider) request.user.profile.save()六、订阅信号的三种推荐姿势Django 信号的订阅本质是调用signal.connect(receiver_func)。推荐以下两种方式之一注册方式一使用receiver装饰器 AppConfig.ready()# myapp/signals.py from django.dispatch import receiver from allauth.socialaccount import signals receiver(signals.pre_social_login) def my_handler(sender, request, sociallogin, **kwargs): ...# myapp/apps.py from django.apps import AppConfig class MyAppConfig(AppConfig): default_auto_field django.db.models.BigAutoField name myapp def ready(self): import myapp.signals # noqa: F401方式二显式 connect适合在既有模块中快速挂接from allauth.socialaccount import signals def on_removed(sender, request, socialaccount, **kwargs): ... signals.social_account_removed.connect(on_removed)方式三通过dispatch_uid防止重复注册在 Django 的 autoreload / 测试环境中ready()可能被多次调用重复注册会导致处理器被多次执行。为稳妥起见可指定dispatch_uidreceiver(signals.pre_social_login, dispatch_uidmyapp.on_pre_social_login) def my_handler(sender, request, sociallogin, **kwargs): ...七、测试验证信号确实按预期触发仓库测试 tests/apps/socialaccount/test_login.py 提供了一个很好的信号验证模式用unittest.mock.patch替换信号对象的.send方法再断言是否被调用with patch(allauth.socialaccount.signals.social_account_updated.send) as updated_signal: with patch(allauth.socialaccount.signals.social_account_added.send) as added_signal: resp complete_social_login(request, sociallogin) assert added_signal.called auto_connect assert not updated_signal.called该测试验证了邮件认证场景下的行为当SOCIALACCOUNT_EMAIL_AUTHENTICATION关闭时added_signal与updated_signal均不被调用开启且自动连接auto_connect时只有social_account_added被调用social_account_updated不被调用。这个思路可以直接复用到你自己的测试中用于确认你的业务代码挂在正确的信号上、且触发次数符合预期。八、小结信号选择速查你的需求应订阅的信号注意事项登录/注册/连接发生前做统一预处理或拦截pre_social_login需干预流程时优先用 adapter 钩子参数为sociallogin用户主动绑定第三方账号成功后做初始化social_account_added首次社交注册自动建号不触发参数为sociallogin每次通过已绑定账号登录后同步最新资料social_account_updated此时extra_data已写回数据库参数为sociallogin用户解绑第三方账号后做清理social_account_removed记录已被删除只有内存快照参数为socialaccount四个信号共同覆盖了社交账号从认证、绑定、数据更新到解绑的完整生命周期。正确理解它们的触发时机与参数差异就能在不改动 allauth 源码的前提下通过标准的 Django 信号机制将你的业务逻辑精准地挂接到认证流程的每一个关键节点上。若需要进一步了解模型与流程细节可继续阅读 allauth/socialaccount/models.py、allauth/socialaccount/internal/flows/login.py 与 allauth/socialaccount/internal/flows/connect.py。赞分享后端认证鉴权身份认证【免费下载链接】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点击查看免费下载相关推荐Tolaria 将 Claude CLI 作为子进程驱动 AI AgentNDJSON 流式事件与 MCP 工具集成的工程实践Tolaria 将 Claude CLI 作为子进程驱动 AI AgentNDJSON 流式事件与 MCP 工具集成的工程实践 本文基于 Tolaria 仓库后端认证鉴权身份认证终极指南3种方法在iOS设备间启用JIT调试终极指南3种方法在iOS设备间启用JIT调试 你是否曾遇到过iOS设备上的JIT即时编译限制问题传统的iOS开发调试往往需要Xcode和USB连接但在后端认证鉴权身份认证Sanic 信号机制Signals完整指南事件、分发与内置生命周期信号Sanic 信号机制Signals完整指南事件、分发与内置生命周期信号 信号Signals是 Sanic 应用内实现一处发生、多处感知的解耦通信机后端Web框架上一篇ComfyUI终极扩展指南5分钟掌握210节点的WAS Node Suite完整教程下一篇抖音无水印下载终极指南3分钟学会免费保存高清视频的完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考