2

クライアント側では、iOS SDK for Facebook を使用してログインし、Facebook ID とアクセス トークンを取得します。

ここで、Django 側で、Facebook ID をプライマリ識別子として使用し、アクセス トークン、名、姓などの他のフィールドを使用してユーザーを作成したいと考えています (最後の 2 つはサーバー上の Graph API から取得します)。側）。

カスタム ユーザー モデルを作成する必要があることはわかっています。

ユーザーに関連する情報を保存する場合は、追加情報のフィールドを含むモデルに 1 対 1 の関係を使用できます。この 1 対 1 のモデルは、サイト ユーザーに関する非認証関連の情報を格納する場合があるため、プロファイル モデルと呼ばれることがよくあります。

Facebook ID とアクセス トークンを認証に使用するので、これでは不十分です。

これにより、2 つのオプションが残されます。カスタム ユーザー モデルを次のように置き換えることができます。

AUTH_USER_MODEL = 'myapp.MyUser'

または、AbstractUser をサブクラス化できます。

Django の User モデルに完全に満足していて、追加のプロファイル情報を追加したい場合は、単純に django.contrib.auth.models.AbstractUser をサブクラス化し、カスタム プロファイル フィールドを追加できます。

しかし、それも正しくはありません。また、このデザインのヒントは、私をもう少し混乱させました。

モデル設計に関する考慮事項 カスタム ユーザー モデルで認証に直接関係しない情報を処理する前に、慎重に検討してください。アプリ固有のユーザー情報は、ユーザー モデルと関係のあるモデルに格納することをお勧めします。

私がやろうとしていることを実装する最良の方法は何ですか?

4

2 に答える 2

1

補足: カスタム ユーザーの問題は、多くの場合、他のアプリ (もちろん、それらを使用することになります) が、認証の基本モデルで行っている仮定が原因で、カスタム ユーザーと正しく対話しない場合があることです。

Facebook ID とアクセス トークンを認証に使用するので、これでは不十分です。

カスタムユーザーが本当に必要かどうかはわかりません。たとえば、私は認証にオープン IDを使用していますが、デフォルト ユーザーを使用しても問題はありません。デフォルト ユーザーとの OneToOne 関係を持つ別のモデルがあります。

認証 (および一般的な認証) 用の Facebook ID について主に考慮する必要があるのは、独自の特定の Facebook 認証を備えたカスタム認証バックエンドを用意することです。

内部的には、authenticate()はインストールされているすべてのバックエンド ( settings.AUTHENTICATION_BACKENDS) を介して実行され、それらの 1 つを使用してユーザーを認証しようとします。

Facebook認証用のDjangoパッケージなど、既存の実装の一部を検索できます。

于 2013-08-27T06:51:02.737 に答える
0

ユーザーがユーザー名、メール、パスワードでログイン/登録できるようにする必要がある場合 -> OneToOnedjango のユーザーモデルとの関係を使用して Facebook の資格情報を保存します。

ユーザーモデルが Facebook データに完全に依存していて、ユーザーにユーザー名/パスでログインさせたくない場合 -> ユーザーモデルをAUTH_USER_MODEL = 'myapp.MyUser'.

また、甘い小さなパッケージで多くの問題を解決するdjango-allauthを確認することもできます。

于 2013-08-27T06:50:31.363 に答える