1. ホーム
  2. session

[解決済み] これを理解するのを助けてくれる?"よくあるRESTの間違い "です。セッションは無関係"

2022-04-25 07:15:52

質問

免責事項: 私はRESTの流派の初心者で、それを理解しようとしています。

で、このページを読んでいると RESTのよくある間違い そして、セッションが無関係であるというセクションに完全に困惑していることに気づきました。このページにはこう書かれています。

クライアントが ログインまたは接続を開始する必要があります。 HTTP認証は は、すべてのメッセージで自動的に クライアント アプリケーションは リソースであり、サービスではありません。したがって ログインする必要がない 例えば で飛行機を予約しているとします。 REST ウェブサービスです。を作成することはありません。 への新しいセッション接続を作成します。 サービスです。むしろ、quot;旅程 オブジェクトを作成します。 の旅程を作成します。を記入し始めることができます。 しかし、その後に全く別の 他の場所で別のコンポーネントを ウェブで他の空白を埋めることができます。 セッションは存在しないので セッションの状態を移行する問題 クライアント間で また のセッションアフィニティの問題です。 サーバに負荷がかかりますが バランシングの問題が続く)。

HTTP認証がすべてのメッセージで自動的に行われることはわかりましたが、どのように行われるのですか?ユーザー名やパスワードはリクエストごとに送信されるのでしょうか?それは単に攻撃対象領域を増やすだけではないのですか?パズルの一部が欠けているような気がします。

RESTサービスがあるとまずいかな、例えば。 /session GET リクエストを受け付け、ユーザー名とパスワードをリクエストの一部として渡し、認証が成功したらセッショントークンを返し、それを以降のリクエストに渡すことができますか?RESTの観点からは意味があるのでしょうか、それともポイントがずれているのでしょうか?

解決方法は?

RESTfulであるためには、HTTPのステートレスな性質と完全に調和するように、各HTTPリクエストは受信者がそれを処理するのに十分な情報をそれ自体で運ぶ必要があります。

<ブロッククオート

なるほど、HTTP認証は は、すべてのメッセージで自動的に行われます。 - が、どのように?

はい、ユーザー名とパスワードはすべてのリクエストで送信されます。 そのための一般的な方法は ベーシックアクセス認証 ダイジェストアクセス認証 . そして、そう、盗聴者はユーザーの認証情報を捕らえることができるのです。 そのため、送受信されるすべてのデータを トランスポート・レイヤー・セキュリティ(TLS) .

REST サービス、例えば /session、は GET リクエストに ユーザー名/パスワードの一部として というセッション・トークンを返します。 認証に成功した場合 を渡すことができます。 それ以降のリクエストは?それは RESTの観点からは意味があるのか、それとも というのは的外れなのでは?

とはならないでしょう。 RESTful しかし、これはユーザーにとって便利なものであるため、非常に一般的なものです。

セッション・トークンとは、一般に、「セッション・トークン」と呼ばれるものです。 ログインクッキー . 例えば、ヤフーのアカウントにログインしようとすると、「2週間ログインを維持する」というチェックボックスがあります。 これは本質的に(あなたの言葉で)「ログインに成功したら、2週間セッション・トークンを維持する」と言っているのです。ウェブ・ブラウザは、あなたのために行うよう依頼したHTTPリクエストごとに、こうしたログイン・クッキー(そしておそらく他のクッキーも)を送信します。