27

Web アプリケーション用の RESTful (または準 RESTful) API を構築する際に、人々がどのようなアプローチを取っているかを知りたいと思っています。

実際の例:

すべてのフォームで CSRF 保護を使用する従来のブラウザーベースの Web アプリケーションがあるとします。ブラウザーに表示される各フォームには、CSRF 保護トークンを含む非表示の入力が含まれています。フォームの送信時に、この入力がサーバー側のトークンのバージョンと一致しない場合、フォームは無効と見なされます。

ここで、Web アプリケーションを API として公開したいとします (おそらく HTML ではなく JSON を使用します)。従来、API を公開する場合、トランザクションは一方的なものであると考えてきました (つまり、API コンシューマーは、最初にフォームをリクエストしてから、返されたフォームを使用してリクエストを構築するのではなく、公開された API に基づいてリクエストを構築します)。

「一方的な」アプローチは、CSRF 保護などの要素が含まれると破綻します。CSRF 保護トークンは、API コンシューマから送信されるすべての POSTS/PUTS/DELETES に含める必要があります。

これにどう対処するのがベストかを考えてみました。API 呼び出しを行う必要があるたびにフォームを要求するのは非常に面倒に思えますが (特に非同期操作を処理する場合)、私が自分で考えた他のすべての代替手段は、CSRF 保護を無効にしているようです (または、少なくともそれに穴を開けます)。 )、これは容認できません。

これについての洞察を持っている人はいますか？

ありがとう。

(問題は概念的でプラットフォームに依存しないため、あまり重要ではありませんが、私は従来の LAMP スタックを扱っており、アプリケーション フレームワークとして Symfony 1.4 を使用しています。私の目標は、開発者が JSON 形式の Web API を公開できるようにすることです。既存の Web アプリケーションとうまく連携するモバイル/デスクトップ アプリを作成します)。

4

1 に答える 1

2

REST は認証 (つまり、基本認証) と非常に相性が良いため、ユーザー サイトのユーザー名と、そのユーザーにバインドされたアプリケーションに固有のパスワードを使用してみてください (API キーと呼ばれることもある手法)。FriendFeed の API が行っていることについては、ドキュメントを参照してください。

厳しいメモ:

  • ダイジェスト認証または SSL を使用する
  • アプリケーションごとに API キーを使用するとオーバーヘッドが発生する可能性があるため、ほとんどのサイトでは、すべてのサードパーティ アプリケーションに対して単一の API キーを使用しています。
  • OAuthはチェックアウトする価値があるかもしれません
于 2010-02-15T17:32:30.473 に答える