1

ユーザーモデルが拡張/サブクラス化され、この結果のユーザーモデルが複数のアプリ間で共有および使用される場合、一般的なプロジェクト/アプリケーション構造はどのようなものになるのでしょうか。

複数のアプリで同じユーザーモデルを参照したいのですが。ログインインターフェイスはまだ作成していないので、どのように組み合わせるかわかりません。

次のことが思い浮かびます。

project.loginapp.app1
project.loginapp.app2

この状況に共通のパターンはありますか？ログインは「ログインアプリ」で処理するのが最適ですか？

この質問に似ていますが、より具体的です。 djangoアプリケーションの構成

アップデート

上記の私のユースケースを明確にしました。既存の認証ユーザーモデルにフィールド（拡張またはサブクラス？）を追加したいのですが。次に、そのモデルを複数のアプリで参照します。

4

3 に答える 3

7

なぜユーザーを拡張するのですか？どうか明らかにしてください。

ユーザーに関する情報をさらに追加する場合は、独自のユーザーと認証システムをロールする必要はありません。Djangoのバージョンは非常に堅実です。ユーザー管理はdjango.contrib.authにあります。

ユーザーとともに保存される情報をカスタマイズする必要がある場合は、最初に次のようなモデルを定義します。

class Profile(models.Model):
    ...
    user = models.ForeignKey("django.contrib.auth.models.User", unique=True)

次に設定します

AUTH_PROFILE_MODULE = "appname.profile"

あなたのsettings.pyで

これを設定する利点により、ビューで次のようなコードを使用できます。

def my_view(request):
    profile = request.user.get_profile()
    etc...

ユーザーが認証するためのより多くの方法を提供しようとしている場合は、認証バックエンドを追加できます。django.contrib.auth.backends.ModelBackendを拡張または再実装し、settings.pyでAUTHENTICATION_BACKENDSとして設定します。

djangoが提供するものとは異なる権限またはグループの概念を利用したい場合、あなたを止めるものは何もありません。Djangoはこれらの2つの概念をdjango.contrib.admin（私が知っていること）でのみ使用します。これらのトピックには、適切と思われる他の概念を自由に使用できます。

于 2009-02-23T02:27:09.303 に答える
3

contrib.authモジュールがニーズを満たしているかどうかを最初に確認する必要があるため、車輪の再発明を行う必要はありません。

http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth

編集：

新しいユーザーの作成後にUserProfileを作成するこのスニペットを確認してください。

def create_user_profile_handler(sender, instance, created, **kwargs):
    if not created: return

    user_profile = UserProfile.objects.create(user=instance)
    user_profile.save()

post_save.connect(create_user_profile_handler, sender=User)
于 2009-02-23T02:22:59.673 に答える
2

「プロジェクト/アプリ」の名前は正しく選択されていないと思います。それは「サイト/モジュール」のようなものです。たとえば、アプリはビューがなくても非常に便利です。

YouTubeでの2008年のDjangoConの講演、特に再利用可能なアプリに関する講演を確認してください。プロジェクトの構成方法についてまったく異なる考えが生まれます。

于 2009-02-23T02:25:52.473 に答える