Django Tenants租户超级用户跨schema登录权限问题咨询

跨Schema登录、可修改其他租户超管账号是否为框架预期行为 #

这不是框架设计时预期的正常安全表现，本质是默认配置没做租户维度的Admin权限校验导致的，核心原因基本都是配置问题：

• 大部分人刚开始用的时候，会习惯性把django.contrib.auth、django.contrib.admin这些后台、权限相关的依赖放到SHARED_APPS里，这部分配置对应的数据库表只会在public schema下生成，所有租户共用这一套表。这种情况下哪怕你执行./manage.py create_tenant_superuser --username=admin2 --schema=client2指定了schema创建超管，用户记录实际还是写在全局共享的auth_user表里，is_superuser、is_staff这类权限标记全租户生效，当然能登任意schema的管理后台。
• Django原生Admin的登录校验本来就只查账号密码、有没有超管/职员权限，不会自动判断当前访问的schema和用户所属租户是不是匹配，也不会默认给后台展示的数据加租户过滤，所以超管登进去之后，能改全局共享用户表里的所有账号，包括其他租户建的超管密码。

create_tenant_superuser本来的设计目的就是在指定schema下创建仅属于这个租户的超管，出现跨租户能登、能改其他账号的情况，是配置没补全导致的漏洞，不是框架本身要做的效果。

框架是否应当实现每个租户在/admin路径下完全隔离的独立管理页面 #

Django Tenants的核心作用是做数据库层的Schema隔离，它只给你提供隔离的底层能力，不会默认帮你把上层业务、管理后台的隔离逻辑全写完，这部分本来就是开发者要根据自己业务需求实现的内容。
要实现Admin页面的完全租户隔离，直接按下面调整就行：

• 先改应用配置：把django.contrib.auth、django.contrib.admin、django.contrib.contenttypes这些Admin依赖的应用从SHARED_APPS挪到TENANT_APPS里，重新跑迁移之后，每个租户的schema下都会生成独立的用户、权限、后台数据表，从数据库层就把用户、权限数据彻底隔开，从根源上杜绝跨租户碰其他账号的可能。
• 如果你的业务必须要全局共享一套用户表，就自己改Admin的登录校验逻辑：登录校验时额外判断下当前请求对应的schema，和用户绑定的租户是不是对得上，对不上直接不让登；同时重写Admin里所有模型的查询集，强制只返回当前租户下的数据，从逻辑上禁止跨租户改账号、改业务数据。
• 补一层中间件校验：所有走/admin路径的请求，先过一遍租户身份校验，和当前租户不匹配的用户直接拦在登录页外面就行。

内容的提问来源于stack exchange，提问作者Evren Bingøl