0

Web サーバーからの応答で 401 ステータス コードを受け取りました。ただし、401 例外をトラップしてデータを処理すると、応答には実際には承認された要求と同じ情報が含まれます。これを確認するためのデータでステータス 200 を受信した別のクライアントがあります。Fiddler もデータを確認します。

これはサーバーの不適切な動作だと思います。ただし、そのように確認するための仕様が見つかりません。RFC 2616 と 2617 を読みましたが、最も関連性の高いスニペットは次のようです。

401 応答に前の応答と同じチャレンジが含まれており、ユーザー エージェントが少なくとも 1 回認証を試みている場合、応答で指定されたエンティティをユーザーに提示する必要があります。そのエンティティには関連する診断情報が含まれている可能性があるためです。

ただし、エンティティの一般的な定義により、エンティティは理論的には、承認された要求に送信されるデータになる可能性があります。

401 でデータ/認証拒否データがない場合、または許可されたデータがある 200 の方が快適です。しかし、これは欠陥であり、今後問題が発生する可能性があるのではないかと心配しています. 適切に 401 されているかどうかはわかりません。

401 応答を生成するクライアント リクエストに承認済みデータを返してはならないという仕様はありますか? それとも、このシナリオは有効ですか?

4

1 に答える 1

0

思わない the entity could theoretically be the data that would be sent to an authorized request.

RFC 2616から:

401 応答に前の応答と同じチャレンジが含まれており、ユーザー エージェントが少なくとも 1 回認証を試みている場合、応答で指定されたエンティティをユーザーに提示する必要があります。そのエンティティには関連する診断情報が含まれている可能性があるためです。

したがって、エンティティを認証されていないユーザーに提示することは合法です。

あなたが言っauthorized data should not be returned to a client...たように、あなたの場合、エンティティは認証されたユーザーと認証されていないユーザーの両方で同じです。

一方、Google のログイン ページ200では、認証に失敗した場合の応答コードとして使用されます。

ご了承ください：

応答には、要求されたリソースに適用可能なチャレンジを含む WWW-Authenticate ヘッダー フィールド (セクション 14.47) を含める必要があります。クライアントは、適切な Authorization ヘッダー フィールド (セクション 14.8) を使用してリクエストを繰り返すことができます。

その理由は、ほとんどのブラウザーが、WWW-Authenticate ヘッダー フィールドを受信したときに、ユーザー名とパスワードを入力するためのポップアップ ウィンドウを開くためです。ただし、これはプレーン テキストに基づいているため、セキュリティ上の問題が発生する可能性があります。

于 2013-12-24T09:43:53.060 に答える