单域名下django-tenants多schema配置求助：认证与会话问题

场景与问题 #

之前基于django-tenants搭建的Django应用，采用子域名对应独立schema的模式（比如schema1对应subdomain1.domain.com），现在要切换为单域名适配多schema，碰到了两个核心问题：

• 认证失效：原认证逻辑挂载在TENANT_APPS中，切换单域名后认证流程完全无法正常工作
• 会话无法维持：用户成功认证后，会话未创建或跳转后直接失效，导致无法正常导航应用

解决办法 #

核心解决思路是让租户识别逻辑提前到认证流程之前，同时调整认证和会话的存储配置，具体操作如下：

1. 调整租户识别逻辑，提前注入上下文 #

不再依赖子域名解析租户，改为从请求中提取租户标识（比如URL前缀/tenant/<schema名称>/、请求头或后续会话中存储的租户ID），且要在认证启动前完成租户schema的激活：

• 编写自定义中间件，在process_request阶段提取租户标识
• 通过标识获取对应租户实例，调用tenant.set_schema()激活当前租户的数据库schema

2. 修正认证相关配置 #

• 将django.contrib.auth等认证类应用从TENANT_APPS迁移至SHARED_APPS，让认证逻辑在公共数据库层面生效，同时租户数据库保留用户关联的业务数据
• 自定义认证后端，在认证过程中自动关联当前租户的用户数据，确保权限验证在租户上下文内正常执行

3. 修复会话维持问题 #

• 修改SESSION_COOKIE_DOMAIN为单域名（例如把.domain.com调整为domain.com），避免子域名的会话隔离限制
• 确保会话存储使用公共数据库（而非租户数据库），保持SESSION_ENGINE为默认的django.contrib.sessions.backends.db，让sessions表保留在公共schema中
• 在租户识别中间件中增加校验：确认会话内的租户标识与当前请求的租户一致，防止跨租户会话冲突

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