2

アプリケーションで RESTfull 認証 API を使用したいと考えています。次の構造を想像してください。

新しいセッション トークン (ログイン) を作成します。

POST /session/?username=&password <-- return session token

トークンを使用して、保護されたリソースを更新および取得します。

PUT /ressource/example?token={token}
GET /ressource/example?token={token}

トークンを削除します (ログアウト):

DELETE /session/{token}

質問:この API は RESTfull ですか? いいえの場合、どうすればよいですか？

4

2 に答える 2

2

認証とセッションは、リクエストごとに完全な認証資格情報を渡さない限り、ステートフルであるため、真に RESTful となることはめったにありません。

これが私がしていることで、あなたのものと似ていますが、大きな違いが 1 つあります。

POST /session/  --> creates a session, passing credentials in HTTP Auth Header

上記は、成功した場合、実際のリソースと同様に、セッション ID とともに 201 を返します。また、Cookie (および特殊なX-タイプの HTTP ヘッダー) にセッション トークンが含まれており、後続の各要求で使用できます。

GET /protectedResource  --> includes the credential in the HTTP header

また、「ログアウト」をクリックするなど、一般的なアクティビティであるセッションを終了/無効化する

DELETE /session/sessionId

あなたが行ったこととの唯一の本当の違いは、クエリ パスまたは本文でトークンと資格情報を決して渡さないことです。唯一の例外は、フォーム ベースの認証を実行して送信する場合ですが、その場合でも、可能な場合は、Web 側で処理してヘッダーとして送信することを好みます。

その理由は 2 つあります。

  1. 秘密を公開せずに URL を公開できるようにしたい
  2. 公開せずに URL を再利用できるようにしたい

HTTP 認証 (ヘッダーにある) のもう 1 つの利点は、curl を使用して REST API をテストすることが非常に簡単になることです。

curl --user username:pass http://server/protectedResource

また、セッション トークンを生成して curl で使用することもできます。

nodejs に慣れている場合は、cansecurity http://github.com/deitch/cansecurityの README とソース コードを確認できます。

于 2013-10-08T09:24:26.637 に答える
0

おそらく、「ユーザー トークンを取得する」(または認証トークンを取得する) には、少し異なるアプローチに従う必要があります。

POST /authentication/{username} (HTTP ヘッダーにパスワードを含む)

または似たようなもので、必要な「リソース」は特定のユーザーの「トークン」または「認証トークン」であるという考えです。リソース「セッション」でPOSTしているため、使用していたPOSTはあまり「RESTful」ではないため、おそらく「セッションの詳細」になります...

PUT/GET に関しては、「正しい」ように思われます。つまり、各リクエストでトークンを送信して、「リソース」を操作します。

DELETEに関しては、それが行われるかどうかはわかりません...おそらく、サーバー（Webサービス）ロジックで定義するものです。たとえば、トークンのTTLです。「クライアント」側がトークンを削除できるとは思いませんが、他の要件があるかもしれません。

最後に、これを「プレーン テキスト」で使用する場合は十分に注意してください。つまり、この情報 (パスワードとトークン) を常に HTTP ヘッダーで暗号化されたチャネル (例: HTTPS) 経由で送信してください。さらに、このタイプの認証をすでに実装しているいくつかのアプローチ (HTTP 基本認証など) があるので、それらを確認する必要があります。

于 2013-10-08T08:03:55.047 に答える