使用“其他身份验证源”时，我可以避免创建 Django auth.model.User 表吗？
正如 Django 文档所述 其他身份验证来源，为了针对其他来源进行身份验证，您必须实现自己的身份验证后端。此外，他们解释说：
Django 管理系统与本文档开头描述的 Django User 对象紧密耦合。目前，处理此问题的最佳方法是为后端存在的每个用户创建一个 Django User 对象（例如，在 LDAP 目录、外部 SQL 数据库等中）
因为我不打算使用管理系统（我假设他们引用管理应用程序）我可以避免该表复制吗？
我正在考虑实现authenticate和get_user > 方法 正如文档所说，但这意味着实例化User 类，所以下一个问题是：可以在没有实际 Django User 表的情况下实例化 auth.models.User 类吗？
As the Django documentation says about Other authentication sources, in order to authenticate against another source, you must implement your own authentication backend. Also, They explain that:
The Django admin system is tightly coupled to the Django User object described at the beginning of this document. For now, the best way to deal with this is to create a Django User object for each user that exists for your backend (e.g., in your LDAP directory, your external SQL database, etc.)
As i'm not going to use the admin system (i'm assuming they are referencing the admin application) can i avoid that table replication?
I was thinking of implementing the authenticate and get_user methods as the doc says but that implies the instantiation of the User class, so the next question would be: can the auth.models.User class be instantiated without having the actual Django User table?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
对你的问题的简短回答是——是的，可以。只需设置 托管在 User 模型上将属性设置为 False。
The short answer to your question is - yes, it can. Simply set the managed property to False on the User model.
您应该将用户从外部身份验证映射到
auth.User对象。You should map the user from the external authentication into the
auth.Userobject.从
INSTALLED_APPS设置中删除django.contrib.auth。Remove
django.contrib.authfrom theINSTALLED_APPSsetting.您不希望创建表有什么特殊原因吗？如果您编写（或使用预先存在的）LDAP 身份验证后端，用户对象将存储在表中，但它们不会存储任何密码信息，并且您可以在身份验证过程中轻松更新电子邮件地址和姓名等字段，因此不会创建断开连接之间存储在 LDAP 中并在 Django 表中管理的信息（即，您可以继续从 LDAP 更新身份验证信息，而不必担心还要在 Django DB 中更新它）。
Is there a particular reason you don't want the table to be created? If you write (or use a pre-existing) LDAP authentication backend, the User objects will be stored in the table, but they won't have any password information stored, and you can easily update fields like email address and name during the authentication process, so you won't create a disconnect between information stored in LDAP and managed in the Django table (i.e., you can continue updating auth information from LDAP, and don't have to worry about also updating it in the Django DB).
没有办法避开该表并仍然进行任何排序身份验证。 “替代”身份验证方法仍然使用
auth_user表，它们只是通过其他方式进行身份验证。There's no way to avoid the table and still have any sort authentication. The "alternative" authentication methods still make use of the
auth_usertable, they just authenticate via another means.