6

SO には、REST とセキュリティに関する優れた質問 (および回答) が多数あります。多くの人が「純粋主義者はこれを好まないだろうが、何とか何とか」と言い、他の人は「何とかやってはいけない」と言います。

しかし、「純粋主義者」が次のシナリオに対して提案している解決策を見たことがありません。私の質問は、次のシナリオに対する「純粋な RESTful ソリューション」とは何ですか?

シンプルなシナリオ...

ユーザーがお気に入りのレシピを管理できるデータベース/ウェブサイトを構築することを想像してみてください。この Web サイトは RESTful API を公開しているため、ユーザーは自分が作成したい (この API を利用する) カスタム プログラムからリストを照会および操作できます。

したがって、ユーザー「A」には、ID「1」、「2」、「3」の 3 つのお気に入りレシピがあります。

ユーザー「B」には、ID「4」と「5」の 2 つのお気に入りレシピがあります。

DELETEユーザー A がコマンドを送信すると、応答/Recipes/4が得られることを確認する必要があります。Forbidden (403)

普段ならどうしよう…

私が通常行うことは、最初に認証メソッドを呼び出して、30 分間有効なある種の認証トークンを送信することです。通常、このトークンは Cookie を介して渡されます。

純粋な解決策は何ですか？

クエリ文字列の変数として渡す純粋な REST ソリューションですか? クッキーは悪魔ですか？トークンを (クエリ文字列パラメーターではなく) URL のセグメントとして使用する必要がありますか? この質問に明確に答える何かが他にありますか?

4

3 に答える 3

4

認証ヘッダーでトークンを渡します。そのために設計されています。http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-12.htmlを参照してください。

于 2012-06-02T12:26:55.723 に答える
1

Treat the auth token as a resource.

You authenticate by GETting an auth token with parameters being credentials (basic auth over https for example).

Logout by DELETE'ing the auth token resource you got when logging in.

于 2012-06-02T03:09:05.330 に答える
0

シンプルなステートレスで Cookie を使用しないソリューションは、各ユーザーに同一のトークンを与えることです。

これらのトークンを生成して、セキュリティ上の懸念に対して十分にまばらにする方法があります。

例: https://www.grc.com/passwords.htm

ユーザー A とユーザー B がいるとします。ユーザー A のトークン X とユーザー B のトークン Y を生成します。

したがって、ユーザーAは次のようなものを使用します/X/Recipes/1

ユーザーBは次のようなものを使用します/Y/Recipes/4

ユーザー A だけが自分のトークンを知っているので安全です。前に述べたように、トークンを生成する方法により、他のユーザーがそのトークンを推測することは「不可能」であることを確認できます。

したがって、ユーザー B のような他の誰かが URL で他のトークンを使用している場合、たとえば/Z/Recipes/1を認識して、対応するエラー メッセージを返すことができるはずです。

上記のように、ユーザーにトークンを URL で配信させるか、認証メッセージとして HTTP リクエストに埋め込むことができます。

于 2012-06-02T02:48:52.293 に答える