5

私は、RESTful APIを介してサービス（SOA）を公開するErlang/OTPアプリケーションを設計中です。

バックエンドを構成するサービスは、データベースサービス、価格計算サービスなどとなります。

クライアントには、Webクライアント、モバイルクライアント、Asteriskサーバークライアント（データベースサービスでユーザーレコードを検索する必要がある）、さらには私が持っている予定がなく、まだ知らないクライアントなど、さまざまな種類があります。クライアントはRESTfulAPIを異なる方法で使用します。一部はすべてのサービスを消費し、一部は一部のサービスのみを消費します（SOA方式）。

私が抱えている主な懸念は、認証/承認です。

RESTfulWebアプリケーション

Ruby on Railsの組み込みの認証/承認を使用することはできません。これは、WebクライアントがRESTfulAPIを介してアプリケーションを使用する可能性のある多くのクライアントの1つのクライアントにすぎないためです。

だから、私の質問は：

  • 多くの異なるクライアントで使用されることが予想される典型的なRESTfulWebアプリケーションの認証/承認の一般的な概念は何ですか？
  • RESTful Webアプリケーションでの承認/認証のための最も実用的なソフトウェアデザインパターンは何ですか？
  • そのようなアプリケーションの認証/承認を実装するために、どのErlang / OTPオープンソースソフトウェアライブラリを推奨できますか？
4

1 に答える 1

5

他の人がこれをどのように行っているかを確認してください。たとえば、この記事：Facebookでの認証。

一般に、システムに対して自身を認証するためにクライアントが呼び出す別個のAPI呼び出しがあるという考え方です。システムは、任意のクライアントを受け入れるか、登録済みクライアントのリストからのみ受け入れることができます。システムがクライアントを検証すると、クライアントがすべてのAPI呼び出しで使用している特別なトークンを発行します。Facebookのドキュメントでは、アクセストークンと呼ばれています。クライアントが有効なトークンなしでAPIを呼び出そうとすると、システムはこれをエラーとして報告し、特定の条件ではクライアントをブロックする可能性があります。

RESTでは、トークンはURLの別のパラメーターとして、POSTで、またはJSONで直接追加フィールドとして送信できます。POSTまたはJSONとして送信すると、URLがクリーンに保たれるため（URLに基​​づく可能性のあるキャッシュと衝突しないため）、おそらく最適です。

これはアイデアのメリットですが、通常どおり、考慮すべきことがたくさんあります。たとえば、クライアントがシステムで認証せずに有効なトークンを再作成できないように、トークンを推測するのは難しいはずです。また、指定された期間内にAPIが呼び出されない場合、システムはトークンを期限切れにする必要がある場合があります。

あなたの質問の最後の部分に答えるために、いくつかの図書館が指摘します：

  • erlang：phash2または暗号ライブラリを使用して、推測しにくい一意のトークンを生成できます
  • 優れたフレームワークとしてのWebmachine、またはErlangでRESTインターフェースを作成するためのRESTツールキット
  • API呼び出しの背後にあるロジックは、Erlangで実装して、inetsやyawsなどのWebサーバーから直接提供することも、NitrogenやChicagoBossなどのWebフレームワークを使用して実装することもできます。このErlangWebフレームワークのリストを確認してください。
于 2012-08-15T12:09:17.403 に答える