1

私は現在 Django を使用しており、ユーザーが登録してログに記録できるようにする必要があります。私は多くのドキュメントを読みましたが、それぞれが User モデルの拡張を推奨しています。User モデルの拡張に制限はありますか? 独自のアプリを作成したり、 User モデルを拡張したりする必要がありますか?

4

5 に答える 5

1

現時点では、Django 1.5 の機能を開発バージョンで使用することをお勧めします。1.5 は 11 月末にリリースされるはずです (私の間違いでなければ)。

これにより、デフォルトのユーザー モデルとその周辺のすべてのものを変更する新しい特定の方法が得られるため、モデルをカスタマイズする際に多くのデフォルトの利点を維持できます (それが必要な場合)。

https://docs.djangoproject.com/en/dev/topics/auth/#customizing-the-user-model

于 2012-10-22T16:47:47.853 に答える
1

django-registrationの良い点は、ユーザーを登録するのに十分な情報を収集すること (システムにログインできるようにすること) と、そのユーザーに関するプロファイルを構成する追加情報を収集することを区別することです。性別、生年月日など。この 2 番目のビットは、さまざまな方法で実行できます。django-registration の作成者である James Bennet は、別のアプリであるdjango-profilesも作成し、必要なフィールドを柔軟に構築できます。ユーザープロファイルを作成します。

独自のプロファイル ソリューションを作成する場合は、(オブジェクト継承の意味で) Django User モデルを実際に拡張することはお勧めしませんが、すべてのプロファイル フィールドを保持する追加のモデルで外部キー関係を指定するだけです。次に、任意の User インスタンスからこのプロファイル モデルへの逆の関係に従います。

例えば：

class Profile(models.Model):
    user = models.ForeignKey(User)
    nickname = models.CharField(max_length=255)

>>> user = User.objects.create_user(username='a_user', email='me@home.com', password='password')
>>> profile = Profile.objects.create(user=user, nickname='example')
>>> user.profile_set.all()[0].nickname #follow the reverse relationship from the fk in Profile
example
于 2012-09-26T15:47:04.103 に答える
1

User モデルに保存されている情報がさらに必要な場合は、この回答を確認してください。

ユーザー登録にはdjango-registrationというアプリがあります。

于 2012-09-26T15:02:14.963 に答える
0

django 1.5 はカスタム User モデルをもたらします:) https://docs.djangoproject.com/en/dev/releases/1.5-alpha-1/#configurable-user-model

于 2012-11-24T16:23:40.823 に答える
0

この答えはかなりの物語になったので、ここに短い部分があります：

これは私にとってはかなりうまくいきましたが、 RequestContext インスタンスで auth.User の代わりに User サブクラスが必要な場合は、追加の作業を行う必要があります。

TLDR :

ユーザー名から電子メールベースのログインに切り替えることを目標に、過去にこれを行いました。これにより、新しい認証バックエンドも必要になるため、オーバーヘッドが少し増えました。プラス面としては、認証バックエンドを置き換えると、RequestContext.user と HTTPRequest.user がカスタム User サブクラスのインスタンスになります。

私の経験では、contrib.admin を使用すると、User を拡張する際の厄介な部分が生じます。

秘訣は、認証されていない/権限のないユーザーが管理 URL の 1 つにアクセスしようとしたときに、contrib.admin が独自のログイン ビューを使用することです。これは、別のログイン ページにアクセスしたときにすぐにわかりましたが、いずれにせよそれらをオーバーライドしていなければ、それほど明白ではないかもしれません。ただし、これは標準の認証バックエンドも使用するため、RequestContexts はサブクラスではなく auth.User インスタンスになりました。

その解決策は、AdminSite をオーバーライドして、新しいログイン メソッドを定義することでした。でフロントエンドのログインページにリダイレクトしました?next。

これらすべてのフープをジャンプするのではなく、より簡単な解決策は、コンテキストに auth.User を残して、ユーザー サブクラスに classmethod を定義することです。

@classmethod
def for_auth_user(cls, auth_user):
    return cls.objects.get(user_ptr_id=auth_user.id)

これは、ページの読み込みごとに追加の db ヒットにすぎません。その後、各リクエストの開始時にこのスワップを行うミドルウェアを作成することもできます。

于 2012-09-26T15:59:30.840 に答える