8

初歩的な質問で申し訳ありません。

RESTful サービスを個別のユーザーと組み合わせて使用​​するための一般的なアプローチについて、私は少し混乱しています。特に、私は主に、私が作成するさまざまなアプリケーション、つまり Web アプリケーションや、場合によってはすべて同じデータにアクセスするいくつかのモバイル アプリを通じて、私だけが使用する API の開発に関心があります。

(1) django-tastypie のようなものによって生成された残りの API は、非公開の使用に適しています (またはベスト プラクティスでさえあります)。

(2) Restful API へのログイン アクセスを作成する際に、Web アプリのすべてのユーザーのログインを作成していますか? それとも、自分自身と Web アプリケーションのログインを作成していますか? 私の webapp へのユーザー アカウントは、Restful API にアクセスするためのアカウントとは区別されるべきですか?

基本的に、Django と django-tastypie を使用して、ユーザーがログイン、オブジェクトの作成と表示、ユーザーのサブスクライブ、オブジェクトの表示を行えるようにするアプリケーションを作成したいと考えています。ビュー内の関連データのシリアル化と更新の作成を容易にするために、Tastypie API を独自の JavaScript の目的で使用したいと考えています。これらのユーザー アカウントは、この図のどこに当てはまりますか? ありがとう！

4

2 に答える 2

4

私の理解が正しければ、ここで 2 つの別々の認証の問題を扱っています: (A) API へのアクセス - Web/モバイル アプリのみ (B) API を介したユーザー データへのアクセス - Web/モバイル アプリを介したユーザー向け

(A) の場合は、秘密鍵で認証できます。したがって、Web またはモバイルのフロント エンドはすべての API リクエストでそのキーを送信します。これにより、承認したクライアントからのみリクエストを受信することが保証されます。

アプリごとに異なるキーを使用する場合は、単純な django モデルを作成してそれらを追跡し、必要に応じて新しいキーを追加したり、それらを取り消すことができます。

すべてに SSL を使用すると、スニッフィング攻撃から安全にキーを検出できます。ここでの最も弱い点は、キーをアプリに保存する必要があるため、誰かがモバイルアプリをリバースエンジニアリングしてキーを見つけることができることだと思います.

(B) については、django auth システムを使用します。Tastypie Basic または ApiKeyオーセンティケーターを使用すると、ユーザーが API を介してログインし、アクセス許可に基づいてデータにアクセスまたは作成できるようになります。それが2番目の質問であなたが求めていたものだと思いますか？

セッションを使用している場合、(A) と (B) の両方に同じ認証モデルを使用することはできないと思います。これは、同時に 2 つのアクティブなセッションを持つことができないためです。

于 2012-07-09T05:40:22.277 に答える