后端认证鉴权身份认证【免费下载链接】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 可选应用allauth.usersessions用户会话管理模块对外暴露的唯一定制化信号 ——allauth.usersessions.signals.session_client_changed。该信号会在已认证用户的会话生命周期内其 IP 地址或 User-Agent 发生变化时被触发是构建异地登录提醒、风控告警、会话迁移通知等功能的天然切入点。读完本文你将掌握该信号的完整参数契约、精确触发条件、底层调用链从中间件到模型层的完整链路、监听注册方式以及如何借助仓库内测试用例验证自己的实现。信号的定义与参数契约session_client_changed信号定义在 allauth/usersessions/signals.pyfrom django.dispatch import Signal # Emitted when the client (e.g. browser) of a session changes. # Arguments: # - request: HttpRequest # - from_session: UserSession # - to_session: UserSession session_client_changed Signal()它是一个标准的django.dispatch.Signal实例携带三个具名参数参数类型语义requestdjango.http.HttpRequest触发本次变化的当前请求对象可从中读取用户、会话 Key、客户端 IP、User-Agent 等上下文信息from_sessionallauth.usersessions.models.UserSession变化前的会话快照旧 IP / 旧 User-Agent / 旧的最后活跃时间等to_sessionallauth.usersessions.models.UserSession更新后的会话记录新 IP / 新 User-Agent / 已刷新的last_seen_at信号由Signal()直接实例化没有像 Django 内置信号那样声明providing_args该参数在 Django 3.0 起已废弃参数契约以源码注释为准。UserSession 模型信号数据的载体from_session与to_session均为UserSession模型实例该模型定义于 allauth/usersessions/models.py其字段直接决定了信号能暴露哪些信息class UserSession(models.Model): user models.ForeignKey(settings.AUTH_USER_MODEL, on_deletemodels.CASCADE) created_at models.DateTimeField(defaulttimezone.now) ip models.GenericIPAddressField() last_seen_at models.DateTimeField(defaulttimezone.now) session_key models.CharField(_(session key), max_length40, uniqueTrue, editableFalse) user_agent models.CharField(max_lengthHTTP_USER_AGENT_MAX_LENGTH) data models.JSONField(defaultdict)ip与user_agent是判断客户端是否变化的两个比对维度session_key唯一标识一条 Django 服务端会话同一会话同一浏览器登录态的多次请求会命中同一条UserSession记录created_at/last_seen_at用于会话列表展示与活动追踪。触发条件两条缺一不可根据官方文档 docs/usersessions/signals.rst 的说明该信号并非每次请求都触发必须同时满足同一用户会话的 IP 或 User-Agent 发生变化USERSESSIONS_TRACK_ACTIVITY配置为True活动追踪开启。在 allauth/usersessions/signals.py 的源码中可以看到最终的判定逻辑if from_session and ( from_session.ip ! session.ip or from_session.user_agent ! session.user_agent ): session_client_changed.send( senderUserSession, requestrequest, from_sessionfrom_session, to_sessionsession, )即只有当更新前的快照from_session存在且新旧ip或user_agent至少有一项不同时才会send该信号。sender固定为UserSession模型类本身。为什么依赖 USERSESSIONS_TRACK_ACTIVITYUSERSESSIONS_TRACK_ACTIVITY定义于 allauth/usersessions/app_settings.py默认值为Falseproperty def TRACK_ACTIVITY(self) - bool: Whether or not sessions are to be actively tracked. When tracking is enabled, the last seen IP address and last seen timestamp will be kept track of. return self._setting(TRACK_ACTIVITY, False)当该设置为False时UserSession记录只在登录时创建一次后续请求不会回写 IP / User-Agent /last_seen_at因此会话中途发生变化这个事件根本不会被观察到信号自然也不会发出。只有开启活动追踪会话才会被持续更新变化检测才有意义。底层实现从请求到信号发出的完整调用链调用链总览session_client_changed的触发路径可归纳为HTTP 请求 └─ allauth.usersessions.middleware.UserSessionsMiddleware └─ UserSession.objects.create_from_request(request) ├─ get_or_create(session_key...) # 命中已有记录 ├─ 生成 from_session 快照旧值 ├─ 更新 ip / user_agent / last_seen_at └─ 新旧值比对不一致 └─ session_client_changed.send(...)中间件入口UserSessionsMiddleware位于 allauth/usersessions/middleware.pyclass UserSessionsMiddleware: def __call__(self, request: HttpRequest): if ( app_settings.TRACK_ACTIVITY and hasattr(request, session) and request.session.session_key and hasattr(request, user) and request.user.is_authenticated ): UserSession.objects.create_from_request(request) response self.get_response(request) return response该中间件的调用前置于视图执行get_response之前且带有多重守卫活动追踪必须开启、请求必须已挂载 session 且带session_key、用户必须已认证。这也是为什么启用USERSESSIONS_TRACK_ACTIVITY True时必须同时把该中间件加入MIDDLEWARE见 docs/usersessions/configuration.rst 的明确要求。模型管理器的核心逻辑真正执行快照 更新 发信号的是UserSessionManager.create_from_request实现于 allauth/usersessions/models.pydef create_from_request(self, request: HttpRequest) - None: if not request.user.is_authenticated: raise ValueError() if not request.session.session_key: request.session.save() ua request.META.get(HTTP_USER_AGENT, )[ 0 : UserSession._meta.get_field(user_agent).max_length ] defaults dict( userrequest.user, ipget_adapter().get_client_ip(request), user_agentua, ) from_session None with transaction.atomic(): from allauth.usersessions.signals import session_client_changed session, created UserSession.objects.get_or_create( session_keyrequest.session.session_key, defaultsdefaults ) if not created: from_session UserSession( session_keysession.session_key, usersession.user, ipsession.ip, user_agentsession.user_agent, datasession.data, created_atsession.created_at, last_seen_atsession.last_seen_at, ) # Update session session.user defaults[user] session.ip defaults[ip] session.user_agent defaults[user_agent] session.last_seen_at timezone.now() session.save() if from_session and ( from_session.ip ! session.ip or from_session.user_agent ! session.user_agent ): session_client_changed.send( senderUserSession, requestrequest, from_sessionfrom_session, to_sessionsession, )几个值得注意的实现细节首次创建不触发get_or_create返回createdTrue时不会构造from_session登录后第一次请求只建立记录、不判定变化快照在事务内生成from_session是更新前的内存副本非数据库对象不落库确保to_session已保存最新值而from_session保留旧值便于接收方做差异对比事务边界记录更新在transaction.atomic()内完成而信号的send在事务提交之后、create_from_request返回之前执行保证接收方读到的是已持久化的最新记录User-Agent 截断UA 字符串按字段max_length源自allauth.core.internal.httpkit.HTTP_USER_AGENT_MAX_LENGTH截断后再比对避免超长 UA 导致字段溢出客户端 IP 获取IP 通过allauth.account.adapter.get_adapter().get_client_ip(request)获得遵循账号适配器对REMOTE_ADDR/ 代理头等来源的既有解析逻辑。登录与改密场景除中间件外create_from_request还在两处被调用注册于 allauth/usersessions/apps.pyuser_logged_in.connect(receiversignals.on_user_logged_in) for sig in [password_set, password_changed]: sig.connect(receiversignals.on_password_changed)用户登录时on_user_logged_in先purge_and_list清理已失效的会话记录再为当前会话创建或复用UserSession密码设置 / 修改后on_password_changed在LOGOUT_ON_PASSWORD_CHANGE未开启的前提下重新登记当前会话保证改密后会话记录与 Django 会话仍一致。这些入口保证了会话在登录时创建是中间件层面能检测到会话中途变化的前提。如何监听并消费该信号信号是标准 Django signal监听方式与普通信号完全一致。推荐在应用的AppConfig.ready()中注册或在独立模块中连接后由应用导入。基础监听示例# myapp/signals.py from django.dispatch import receiver from allauth.usersessions.signals import session_client_changed receiver(session_client_changed) def on_session_client_changed(sender, request, from_session, to_session, **kwargs): if from_session.ip ! to_session.ip: # 异地 IP 登录/切换告警可在此接入通知、风控或审计日志 print(fIP changed: {from_session.ip} - {to_session.ip}) if from_session.user_agent ! to_session.user_agent: print(fUser agent changed: {from_session.user_agent!r} - {to_session.user_agent!r}) # 也可结合 request.user 判断具体用户 user request.user需要注意send时传入的参数即为上述三个具名参数接收函数签名中的sender固定为UserSession模型类**kwargs用于兼容未来可能追加的参数。在 AppConfig 中注册# myapp/apps.py from django.apps import AppConfig class MyAppConfig(AppConfig): name myapp def ready(self) - None: from . import signals # noqa: F401用仓库测试用例验证信号行为仓库为信号行为提供了完整、可直接参考的自动化验证tests/apps/usersessions/test_middleware.py。核心用例test_mw_change_ip_and_useragent第 47-90 行完整模拟了同一会话、IP 与 UA 同时变化的触发过程override_settings(USERSESSIONS_TRACK_ACTIVITYTrue) def test_mw_change_ip_and_useragent(rf, db, user): mw UserSessionsMiddleware(lambda request: None) # First request request1 rf.get(/) request1.user user request1.session Mock() request1.session.session_key sess-123 request1.META[HTTP_USER_AGENT] Old User Agent request1.META[REMOTE_ADDR] 1.1.1.1 mw(request1) # Second request with changed IP and User Agent request2 rf.get(/) ... # Set up signal receiver signal_received [] def signal_handler(sender, request, from_session, to_session, **kwargs): signal_received.append((from_session, to_session)) session_client_changed.connect(signal_handler) mw(request2) # Check if UserSession was updated user_session UserSession.objects.get(session_keysess-123, useruser) assert user_session.ip 2.2.2.2 assert user_session.user_agent New User Agent # Check if signal was triggered assert len(signal_received) 1 from_session, to_session signal_received[0] assert from_session.ip 1.1.1.1 assert from_session.user_agent Old User Agent assert to_session.ip 2.2.2.2 assert to_session.user_agent New User Agent从该用例可以提炼出信号行为的四个可验证断言首次请求无既有记录不触发信号第二次请求携带新 IP 与新 UA 时UserSession记录被更新为最新值2.2.2.2/New User Agent信号恰好触发一次from_session携带旧值1.1.1.1/Old User Agentto_session携带新值USERSESSIONS_TRACK_ACTIVITY False时见test_mw_with_request_user中间件不会创建或更新任何UserSession记录信号自然不触发。这些测试同时印证了中间件、模型管理器与信号三者之间的契约关系可作为你自己实现信号接收器时的行为基准。配套设置与模块上下文活动追踪相关的配置项设置项默认值说明USERSESSIONS_TRACK_ACTIVITYFalse是否持续追踪会话更新 IP、User-Agent、最后活跃时间信号触发的前提USERSESSIONS_ADAPTERallauth.usersessions.adapter.DefaultUserSessionsAdapter会话模块适配器可子类化覆盖默认行为如调整批量结束会话的方式其中DefaultUserSessionsAdapter仅提供一个end_sessions(sessions)方法见 allauth/usersessions/adapter.py用于批量结束会话与信号无关但同属该模块的可扩展点。启用活动追踪的最小配置结合 docs/usersessions/installation.rst 与 docs/usersessions/configuration.rst要实际收到session_client_changed需要在 Django 设置中同时配置INSTALLED_APPS [ ... django.contrib.humanize, # 会话列表模板中展示时间差文案所需 allauth.usersessions, ... ] MIDDLEWARE [ ... # 必需USERSESSIONS_TRACK_ACTIVITY True 时依赖它回写会话 allauth.usersessions.middleware.UserSessionsMiddleware, ... ] USERSESSIONS_TRACK_ACTIVITY TrueUSERSESSIONS_TRACK_ACTIVITY True时如果漏装中间件会话的 IP / UA /last_seen_at将不会随请求刷新变化检测便无从谈起信号也不会发出。典型应用场景基于信号提供的from_session/to_session差异与request上下文可以低成本实现以下能力异地登录风控from_session.ip与to_session.ip的网段 / 地理位置差异可作为告警或二次验证的触发条件设备变更通知User-Agent 变化通常意味着浏览器或设备切换可用于在新设备上继续使用账号的安全提示会话审计日志将每次客户端变化旧值 → 新值、发生时间、用户落库形成可回溯的审计轨迹会话迁移 / 失效联动在检测到客户端变化后主动调用适配器结束其他可疑会话或更新与设备绑定的安全令牌。需要留意的是信号只在同一会话同一session_key内的客户端属性变化时触发新设备从零登录属于新建UserSession走的是createdTrue分支不会触发本信号——若需要监听登录事件本身应使用allauth.account.signals.user_logged_in其与on_user_logged_in的连接关系见 allauth/usersessions/apps.py。小结session_client_changed是 django-allauth 用户会话模块暴露的、针对客户端环境中途变化这一安全敏感事件的信号。它的触发完全受控于两个条件——同一会话内 IP / User-Agent 的差异以及USERSESSIONS_TRACK_ACTIVITY True的活动追踪开关其底层链路清晰可循中间件在每次已认证请求时调用UserSession.objects.create_from_request()在事务内完成旧值快照与新值回写比对不一致后对外send。借助仓库中的模型实现、AppConfig 信号连接与中间件测试用例开发者可以准确预测其行为边界并在此基础上构建自己的会话安全逻辑。赞分享后端认证鉴权身份认证【免费下载链接】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 MFA 信号Signals完全指南5 大信号的触发时机、参数详解与实战监听django allauth MFA 信号Signals完全指南5 大信号的触发时机、参数详解与实战监听 django allauth 的 MFA多因素后端认证鉴权身份认证Textual Hide 事件深入解析触发时机、底层机制与实战监听Textual Hide 事件深入解析触发时机、底层机制与实战监听 Hide 是 Textual 终端 UI 框架中用于通知控件从界面上消失的内置事件。本前端UI组件异步编程django-allauth 社交账号信号SocialAccount Signals开发指南四个核心信号的触发时机与实战用法django allauth 社交账号信号SocialAccount Signals开发指南四个核心信号的触发时机与实战用法 django allauth后端认证鉴权身份认证上一篇changesets 管理应用与非 npm 包版本privatePackages 配置与发布实战指南下一篇BiliOB观测者前端架构详解打造高效直观的数据可视化界面创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考