5

私は現在、Django REST Framework を利用する大規模な Django プロジェクトを持っています。

データベースを直接共有するのではなく、API 経由で必要なデータを取得するメインのプロジェクトから構築したい別の小さな Django プロジェクトがあります。

小さなプロジェクトの AUTHENTICATION_BACKEND をオーバーライドし、大きなプロジェクトの API 認証エンドポイントをオーセンティケーターとして使用したいと考えています。

基本的に、プロセスは次のようになります。

  1. ユーザーは、大規模な Django-DRF プロジェクトのユーザーの資格情報を使用して、小規模な Django プロジェクトにログインしようとします。
  2. 小さな Django プロジェクトが API ログイン要求を大きな Django-DRF プロジェクトに送信します。
  3. 大規模な Django-DRF プロジェクトは、API トークンとシリアル化されたユーザー情報を返します。
  4. 小さな Django プロジェクトは、大規模な Django-DRF プロジェクトの応答からの情報を使用して、データベースにユーザーを自動追加/更新します。
  5. 小さな Django プロジェクトはユーザー クライアントにトークンで応答するため、小さな Django プロジェクトのページからの AJAX 要求を大きな Django-DRF プロジェクトのエンドポイントに直接行うことができます。

このユースケースで活用する価値のある既存のプラグインはありますか、それとも独自の AUTHENTICATION_BACKEND を作成する必要がありますか?

4

1 に答える 1

3

django-rest-framework-jwtを調べたいと思うかもしれません。これにより、JWT を認証メカニズムとして使用できるようになり、ケースを簡単に処理できます。プロジェクトは、実際には、必要なもの専用のエンドポイントを提供しますverify_jwt_token。ドキュメントによると：

一部のマイクロサービス アーキテクチャでは、認証は単一のサービスによって処理されます。他のサービスは、ユーザーがこの認証サービスにログインしていることを確認する責任を委任します。これは通常、サービスがユーザーから受け取った JWT を認証サービスに渡し、JWT が有効であるという確認を待ってから、保護されたリソースをユーザーに返すことを意味します。

したがって、ワークフローは次のようになります。

  1. ユーザーはより大きな API に対して認証します
  2. ユーザーは認証リクエストから返された JWT を受け取ります
  3. ユーザーは、各リクエストとともに JWT を小さな API に送信します。
  4. 小さな API は、JWT を受信すると、それをverify_jwt_token大きな API のエンドポイントに転送します。
于 2016-04-14T18:42:50.570 に答える