django-social-auth django-registration 和 django-profiles -- 一起

发布于 2024-12-11 18:39:50 字数 568 浏览 0 评论 0原文

有没有人使用过django-social-auth，django-registration 和 django-profiles 在一起。他们合作得好吗？我已经建立了social-auth，但我在某处读到 django-allauth 更好。我应该切换到那个吗？

请告知

更新：

我在我的项目中使用了allauth并且它工作正常。您不需要将 django-registration 与 allauth 一起使用，因为它已集成在其中。不过，我使用的是自定义用户配置文件，这是比 django-profiles 更好的选择。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

往昔成烟 2024-12-18 18:39:50

它们一起工作得很好 - 我前几天刚刚设置了它（除了我不需要使用 django-profiles，因为创建你自己的配置文件很容易）。

用户可以使用 django-registration 设置一个普通帐户（contrib.auth），该帐户会发送一封电子邮件进行确认 - 在数据库中创建用户名/电子邮件/密码。
或者，他们可以立即使用 twitter/facebook/google 等登录，并使用虚拟密码（可能没有电子邮件）自动为他们创建一个 contrib.auth 用户。

一些要点和限制：

当您使用社交媒体配置文件登录时，会自动创建 contrib.auth.user。如果该用户名已经存在，则会附加一个 UUID - 这很丑陋，而且 django-social-auth 似乎还没有处理这个问题 - 一个简单的解决方案是允许用户在注册后更改他们的用户名。理想情况下，当您使用 twitter 登录时，您有机会在将详细信息保存到数据库之前（而不是之后）完善您的详细信息。
类似地，设置了一个虚拟密码 - 这使得用户很难使用以下命令重置密码内置的 django 密码更改表单，因为他们将无法输入现有密码（因为它被设置为不可散列的字符串），
您需要考虑注册 Twitter 的用户何时想要关联他们的 Facebook 帐户 - django-social-auth 可以解决此问题，并且很容易将多个第三方登录与一个帐户关联
Twitter 不会公开用户的电子邮件地址，因此您可能需要提示他们向您提供该地址，并且将其保存到数据库 - 这样做的问题是您需要验证它，这否定了使用社交身份验证的全部目的！

django-social-auth 是一个很棒的项目，正在与 ~~convore 小组积极开发~~ Google 网上论坛始终是最新的，所以我当然会推荐它。它的设置也非常容易 - 只需确保您已经解决了登录流程，并且您知道使用此功能的潜在限制

编辑：

这篇文章有点过时的

django-social-auth已成为python-social-auth< /a>
django-allauth：OP提到了django-allauth，它已经得到最近很流行。我还没有使用过它，但它似乎是身份验证、注册和配置文件的一个很好的替代品。
可配置的用户模型：Django 1.5引入了可配置的用户模型< /a> 位于 auth 模块中，以便您现在可以编辑要为用户使用的字段（仅电子邮件，无用户名等）。如果您想向用户添加类似个人资料的信息而无需加入另一个表（就像您使用 django-profiles 或 OneToOne 关系那样），这也很有用自定义配置文件模型）

They work fine together - I just set this up the other day (except I didn't need to use django-profiles as it's as easy to create your own).

A user can set up a normal account (contrib.auth) using django-registration which sends out an email to be confirmed - creating a username/email/password in the DB.
Alternatively they can sign in straight away with twitter/facebook/google etc. and a contrib.auth user is created for them automatically with a dummy password (and potentially no email).

Some points and limitations:

When you sign in with a social media profile, a contrib.auth.user is automatically created. If that username already exists, a UUID is appended - this is ugly and django-social-auth doesn't seem to deal with this problem yet - an easy solution is to allow the user to change their username after they sign up. Ideally, when you sign in with twitter you are given the chance to refine your details before they are saved to the DB (instead of after)
Similarly, a dummy password is set - this makes it difficult to allow the user to reset the password using the built in django password change-form as they will not be able to enter their existing password (as it's set as an unhashble string)
You need to consider when a user that signs up with twitter wants to later associate their facebook account - django-social-auth accounts for this and it's easy to assoicate multiple 3rd party sign ins with one account
Twitter doesn't disclose a users email address so you might want to prompt them to provide it to you and save it to the database - the problem with this is that you will then need to verify it which negates the whole purpose of using social-auth!

django-social-auth is a great project and is being actively developed with a ~~group on convore~~ Google Group that is always up to date so I would certainly suggest it. It's also very easy to set up - just be sure you have ironed out your login flow, and you know of the potential limitations of using this

EDIT:

This post is a little outdated

django-social-auth has become python-social-auth
django-allauth: OP mentioned django-allauth which has gotten popular recently. I haven't used it but it seems to be a great drop-in replacement for authentication, registration and profiles.
Configurable User Models: Django 1.5 introduced a configuratble User models in the auth module so you can now edit what fields you want to make use of for your user (email only, no username etc.). This is also useful if you want to add profile-like information to your user without having to join with another table (like you would with django-profiles or a OneToOne relationship with a custom profile model)