6

私は新しい実験的なWebアプリケーションフレームワークを開発しており、RESTfulに注意を向けることにしました。基本を読み終えて、RESTfulを概念としてかなりよく理解しているように感じます。

システムを稼働させ、URLを使用してシステム内の「名詞」を厳密に定義し、HTTPリクエストメソッドから「動詞」を取得しました。私はjavascriptajax呼び出しを使用して、HTMLフォームでは提供できないDELETEメソッドとPUTメソッドへのアクセスを提供しています。（これらの手段は厳密にはRESTfulである必要はありませんが、「UniformInterface」要件を満たしています）。

問題は、認証によるステートレス性とキャッシュ可能性にあります。Webサイトでのユーザー認証の標準モデルには、「ログイン」認証イベントが含まれます。その後、（成功した場合）ユーザーは永続的な安全なセッションで「壁の内側」にいて、認証されていないユーザーができない後続の要求を確認して実行できます。この認証の永続性は、RESTful性を損なうようです。認証されたユーザーには、認証されていないユーザーが同じリクエストに対して表示するHTMLとは異なるHTMLが表示される可能性があるため、キャッシュとステートレスは壊れているように見えます（たとえば、ログに記録されたユーザーのサイドバーにログインフォームがある場合があります。アウトユーザー）。

www-authenticate戦略を使用して、認証を必要とする要求に対してのみユーザーを認証することは、永続的な安全なセッションの概念を含まないため、正しい方向への一歩のようです。しかし、私たち全員がWebサイトに期待するようになったことに合わせて、エンドユーザーに「ログインした」外観をどのように表現するかという問題がまだあります。

それで、現在の考えでは、HTMLでログインした装飾を許可しながら、厳密にRESTfulな方法でWebページの認証と許可を処理するための好ましい方法は何ですか？

4

7 に答える 7

4

「Webサイトでのユーザー認証の標準モデルには、「ログイン」認証イベントが含まれます。その後、（成功した場合）ユーザーは永続的な安全なセッションで「壁の内側」にいます。」

  1. これは本当に正しくありません。これは部分的には真実ですが、独自の認証を発明したWebサイトにのみ当てはまります。

  2. 「ダイジェスト認証」を使用する場合、ブラウザはリクエストごとにクレデンシャルを送信する必要があります。

ダイジェスト認証（各リクエストのクレデンシャル）は完全にRESTfulです。

それを行う。

物事をもう少し合理化するために、時間に基づいてダイジェスト認証Nonceを計算して、一定期間（6分、0.1時間が適切）有効になるようにすることができます。数分ごとに、リクエストは401ステータスを送信し、ダイジェストの再計算が必要になります。

于 2010-01-06T03:44:07.167 に答える
3

この認証の永続性は、RESTful性を損なうようです

ユーザーを認証する代わりに、セッションの作成を検討することもできます。新しい「セッションID」と適切なHTTPステータスコード（200：OK、403：禁止など）が返されます。

ユーザーには、認証されていないユーザーが同じリクエストに対して表示するHTMLとは異なるHTMLが表示される可能性があります。

RESTサーバーに「このセッションIDのHTML（または任意のリソース）を取得できますか？」と尋ねます。HTMLは、「セッションID」に基づいて異なります。

この方法では、「永続的な安全なセッション」の壁はありません。あなたは単にセッションに基づいて行動しているだけです。

この方法を選択した場合、名詞（またはリソース）は実際のセッションを表します。

于 2010-01-06T03:29:42.127 に答える
2

ユーザー固有の要素を持つページの仲介でcachabilityを維持するための1つのオプションは、Ajaxを介してユーザー固有のマークアップを追加することです。ユーザーのログインに基づいて異なるものを返すリソースに対してXHRリクエストを実行するJavaScriptを含め、すべての使用で同じページを提供します。次に、これをクライアント側のページにマージします。ページの大部分は、すべてのユーザーで同じであるため、キャッシュ可能になります。

もう1つのオプションは、ESI（Edge Side Includes）を使用することです。これらを使用すると、キャッシュ自体がさまざまな表現をマージして、最終結果を構築できます。

于 2010-01-08T15:33:06.057 に答える
1

「この認証の永続性はRESTful-nessを壊すようです。認証されたユーザーはおそらく認証されていないユーザーが同じリクエストに対して見るものとは異なるHTMLを見るので、キャッシングとステートレスは壊れているように見えます。」

認証情報に基づいてリソースの表現がわずかに異なっていても問題ありません。認証情報はメッセージの一部であるため、メッセージは依然として「自己記述的」です。概念的には、引き続き同じリソースにアクセスしており、編集リンクと削除リンクには、追加のデータではなく、遷移が許可されています。リソースにアクセスするユーザーに基づいて使用可能な遷移を制御することは、私には有効だと思われます。

于 2010-01-09T03:00:04.173 に答える
1

Re：ダニエルの答え：

セッションがすぐに削除される一時的なオブジェクトである場合、これはあまりキャッシュできません。作成するキャッシュの有効期間はおそらく1日だけですが、とにかくキャッシュ内のスペースを使い果たし続けるからです。

USERをオブジェクトとして作成し、ダイジェスト認証（または必要に応じてCookie）を使用して認証する方がよいのではないでしょうか。そうすれば、各ユーザーは、1日持続して消えるキャッシュではなく、独自の永続キャッシュを取得します。

これは、ユーザーによってページの外観が異なるため（「hello [name]」などを追加）、「ログイン」状態と「ログアウト」状態の違いが異なるため、私にとっても論理的に意味があります。ユーザーがURLに含まれているかどうかについて。特定のユーザーにそのユーザー固有のURLへのアクセスが許可されるかどうかは、そのユーザーがそのユーザーとして認証できるかどうかによって異なります。

于 2010-03-05T03:46:17.137 に答える
1

私はそれを次のように考えています。ユーザー認証の「名詞」はセッションです。したがって、ログインフォームはPOSTリクエストを使用して新しいセッションを「作成」し、ログアウトはDELETEリクエストを使用してセッションを「削除」します。

RESTfulnessに反する認証の永続性についてあなたが何を意味するのかは知っていますが、Cookie（永続性の錯覚を与える）は単に各要求の一部です。

于 2010-01-06T03:19:32.577 に答える
0

RESTfulフレームワークがWebアプリケーションでのみ使用され、サードパーティのAPIとして使用されない場合、アプリケーションの他の部分と同じ認証スキームを使用できない理由はわかりません。この認証は、「アプリケーション」レベルよりも下位レベルのレイヤーと考えることができます。アプリケーションレベルは、純粋なRESTfulな方法でステートレスのままである可​​能性があります。

もちろん、RESTful Web APIの作成を計画している場合は、これについてさらに検討する必要があります。

于 2010-01-06T03:23:23.550 に答える