Django:完全自定义的身份验证问题。请帮忙
我正在创建一个多租户应用程序,它不会使用任何标准 Django Admin(内部使用除外,它将可以访问所有租户......这很简单)。我正在尝试创建自己的授权系统,并且对使用标准用户模型(或任何内置应用程序的模型)不感兴趣。我的应用程序将有帐户,每个帐户将有管理员(出于名称冲突的目的,必须使用管理员与用户)。这些用户将使用我自己的完全定制的系统进行身份验证。难道这一切都是错的吗?我是否应该/可以在使用我自己的自定义界面的多租户情况下仍然使用 Django 的身份验证系统(就像之前提到的,我不会允许帐户持有者使用默认的管理界面)。使用我自己的系统是否存在安全隐患,或者 Django 的标准安全元素(例如会话劫持预防)是否可以保护我?
在我看来,很多 Django 都是围绕使用 Admin 界面的想法构建的,而不是使用自己的 Admin 构建多租户 SAAS 软件。难道我的想法全错了?
I'm creating a multiple-tenant application that won't use any of the standard Django Admin (except for internal use which will have access to all tenants... that's simple enough). I'm trying to create an authorization system of my own and I'm not interested in using the standard User model (or any built-in application's model). My application will have accounts, and each account will have administrators (had to use Administrator vs User for name-clash purposes). Those users will authenticate using my own completely custom system. Is this all wrong. Should/Can I still use Django's auth system in a multi-tennant situation which uses my own custom interface (like mentioned before I won't be allowing account holders to use the default Admin interface). Is there security implications in using my own system or do Django's standard security elements like session hijacking prevention protect me?
It seems to me that a lot of Django is built around the idea of using the Admin interface and not building multi-tenant SAAS software with your own Admin. Am I thinking of this all wrong?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你绝对应该使用 Django auth 系统,它仍然可以满足你 90% 的需要。
我在一个项目中构建了与您的场景一模一样的内容:公司帐户,每个帐户都有管理员用户和多个普通用户。
以下是我使用的模型结构:
以及使用自定义装饰器在视图级别强制执行授权要求的一些示例:
我们实际上使用帐户的子域,因此不需要显式的
account_id
参数。为帐户管理员使用自定义界面是非常合理的。 Django 管理界面仅适用于 100% 受信任的用户,例如系统管理员和内部支持人员。
You definitely should use Django auth system, it still does 90% of what you need.
I've built what looks exactly like your scenarion in one project: corporate accounts, each with admin user and multiple regular users.
Here's model structure I used:
And some examples of enforcing authorization requirements on view level with custom decorators:
We actually used subdomains for accounts, so there was no need for explicit
account_id
parameter.It is very reasonable to use custom interface for account admins. Django admin interface is only intended for 100%-trusted users like system admininstators and internal support staff.