Web ページは存在するが、ユーザーが十分な権限を持っていない (ログインしていない、または適切なユーザー グループに属していない) 場合、提供する適切な HTTP 応答は何ですか?
401 Unauthorized?
403 Forbidden?
他の何か？
これまでにそれぞれについて読んだことは、2つの違いについてあまり明確ではありません. 各レスポンスに適したユースケースは?
1291778 次
19 に答える
4758
Daniel Irvineからの明確な説明:
認証エラーの HTTP ステータス コードである401 Unauthorizedに問題があります。それだけです。これは認証用であり、承認用ではありません。401 応答を受信すると、サーバーは「あなたは認証されていません。まったく認証されていないか、正しく認証されていませんが、再認証して再試行してください。」と通知します。役立つように、認証方法を説明するWWW-Authenticateヘッダーが常に含まれています。
これは通常、Web アプリケーションではなく、Web サーバーから返される応答です。
それは非常に一時的なものでもあります。サーバーが再試行を求めています。
そのため、承認には403 Forbiddenレスポンスを使用します。これは永続的で、アプリケーション ロジックに関連付けられており、401 よりも具体的な応答です。
403 応答を受信すると、サーバーは「申し訳ありません。あなたが誰であるかは知っていますが、あなたが誰であるかは信じていますが、このリソースにアクセスする権限がありません。うまくシステム管理者に聞けば許可が下りるかもしれません。しかし、あなたの苦境が変わるまで、二度と私を悩ませないでください。」</p>
要約すると、401 Unauthorized応答は、認証の欠落または不適切な認証に使用する必要があり、403 Forbidden応答は、ユーザーが認証されているが、指定されたリソースで要求された操作を実行する権限がない場合に後で使用する必要があります。
http ステータス コードの使用方法を示すもう 1 つの優れた図形式。
于 2011-08-04T06:24:41.817 に答える
477
編集: RFC2616は廃止されました。RFC7231およびRFC7235を参照してください。
401 無許可:
リクエストに承認資格情報がすでに含まれている場合、401 応答は、それらの資格情報に対する承認が拒否されたことを示します。
403禁止します：
サーバーは要求を理解しましたが、要求を満たすことを拒否しています。
ユースケースから、ユーザーが認証されていないようです。401を返します。
于 2010-07-21T07:28:08.790 に答える
325
他の答えが欠けているのは、RFC2616のコンテキストでの認証と承認はRFC2617のHTTP認証プロトコルのみを参照していることを理解する必要があるということです。RFC2617以外のスキームによる認証はHTTPステータスコードではサポートされておらず、考慮されません。 401または403のどちらを使用するかを決定するとき。
簡潔で簡潔
Unauthorizedは、クライアントがRFC2617で認証されておらず、サーバーが認証プロセスを開始していることを示します。Forbiddenは、クライアントがRFC2617で認証されており、許可がないか、サーバーが要求されたリソースに対してRFC2617をサポートしていないことを示します。
つまり、独自のログインプロセスがあり、HTTP認証を使用したことがない場合、403は常に適切な応答であり、401は使用しないでください。
詳細かつ詳細
RFC2616から
10.4.2401無許可
リクエストにはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション14.47）を含める必要があります。クライアントは、適切なAuthorizationヘッダーフィールド（セクション14.8）を使用してリクエストを繰り返すことができます（MAY）。
と
10.4.4 403 Forbiddenサーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。
最初に覚えておくべきことは、このドキュメントのコンテキストでの「認証」と「承認」は、RFC 2617のHTTP認証プロトコルを具体的に指しているということです。これらは、作成した独自の認証プロトコルを指していません。ログインページなどを使用します。RFC2617以外の方法による認証と承認を指すために「ログイン」を使用します
したがって、本当の違いは、問題が何であるか、または解決策があるとしてもではありません。違いは、サーバーがクライアントに次に実行することを期待することです。
401は、リソースを提供できないことを示しますが、サーバーは、クライアントがHTTP認証を介してログインし、プロセスを開始するために応答ヘッダーを送信したことを要求しています。リソースへのアクセスを許可する承認がある場合もあれば、許可されていない場合もありますが、試してみて、何が起こるか見てみましょう。
403は、リソースを提供できず、現在のユーザーにとって、RFC2617を介してこれを解決する方法がなく、試行しても意味がないことを示します。これは、認証のレベルが十分でないことがわかっているため（たとえば、IPブラックリストのため）である可能性がありますが、ユーザーがすでに認証されており、権限を持っていないことが原因である可能性があります。RFC2617モデルは1ユーザー、1クレデンシャルであるため、ユーザーが許可される可能性のある2番目のクレデンシャルセットを持っている場合は無視できます。これは、ある種のログインページまたは他の非RFC2617認証プロトコルが役立つ場合もあれば、役に立たない場合もあることを示唆も暗示していません。これは、RFC2616の標準と定義の範囲外です。
編集：RFC2616は廃止されました。RFC7231およびRFC7235を参照してください。
于 2013-02-05T17:14:37.073 に答える
119
RFC 2616 (HTTP/1.1)によると、次の場合に 403 が送信されます。
サーバーは要求を理解しましたが、要求を満たすことを拒否しています。承認は役に立たず、要求を繰り返すべきではありません。リクエスト メソッドが HEAD ではなく、サーバーがリクエストが実行されなかった理由を公開したい場合、拒否の理由をエンティティに記述する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータス コード 404 (Not Found) を使用できます。
つまり、クライアントが認証によってリソースにアクセスできる場合は、401 を送信する必要があります。
于 2010-07-21T07:26:43.333 に答える
54
HTTP 認証( WWW-AuthenticateおよびAuthorizationヘッダー)が使用されていると仮定すると、別のユーザーとして認証すると要求されたリソースへのアクセスが許可される場合、401 Unauthorized が返されます。
403 Forbidden は、リソースへのアクセスがすべての人に禁止されているか、特定のネットワークに制限されているか、SSL 経由でのみ許可されている場合に使用されます。
HTTP 認証が使用されておらず、現在の標準である Cookie ベースの認証スキームがサービスにある場合は、403 または 404 が返されます。
401 に関しては、これはRFC 7235 (Hypertext Transfer Protocol (HTTP/1.1): Authentication)からのものです。
3.1. 401無許可
401 (Unauthorized) ステータス コードは、ターゲット リソースの有効な認証資格情報が不足しているため、リクエストが適用されなかったことを示します。 オリジンサーバーは、ターゲットリソースに適用可能なチャレンジを少なくとも 1 つ含む WWW-Authenticate ヘッダーフィールド (セクション 4.4) を送信する必要があります。要求に認証資格情報が含まれていた場合、401 応答は、それらの資格情報に対する承認が拒否されたことを示します。. クライアントは、新しいまたは置き換えられた Authorization ヘッダー フィールド (セクション 4.1) を使用してリクエストを繰り返すことができます。401 応答に前の応答と同じチャレンジが含まれており、ユーザー エージェントが既に少なくとも 1 回は認証を試みている場合、ユーザー エージェントは、通常、関連する診断情報が含まれているため、同封の表現をユーザーに提示する必要があります。
403 (および 404) のセマンティクスは、時間の経過とともに変化しました。これは 1999 年のものです ( RFC 2616 ):
10.4.4 403 禁止
サーバーは要求を理解しましたが、要求を満たすことを拒否しています。 承認は役に立たず、要求を繰り返すべきではありません。リクエスト メソッドが HEAD ではなく、サーバーがリクエストが実行されなかった理由を公開したい場合、拒否の理由をエンティティに記述する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータス コード 404 (Not Found) を使用できます。
2014 年にRFC 7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content)で 403 の意味が変更されました。
6.5.3. 403禁止します
403 (Forbidden) ステータス コードは、サーバーが要求を理解したが、承認を拒否したことを示します。リクエストが禁止された理由を公開したいサーバーは、その理由をレスポンス ペイロード (存在する場合) に記述することができます。
要求で認証資格情報が提供された場合、サーバーはそれらがアクセスを許可するには不十分であると見なします。クライアントは、同じ資格情報でリクエストを自動的に繰り返すべきではありません。クライアントは、新しい資格情報または異なる資格情報で要求を繰り返すことができます。ただし、資格情報とは関係のない理由で要求が禁止される場合があります。
禁止されたターゲット リソースの現在の存在を「隠す」ことを望むオリジン サーバーは、代わりにステータス コード 404 (Not Found) で応答する場合があります。
したがって、403 (または 404) は、現在では何の意味も持たない可能性があります。新しい資格情報を提供すると役立つ場合もありますが、そうでない場合もあります。
これが変更された理由は、RFC 2616 が、実際に今日の Web アプリがフォームや Cookie などを使用してカスタム認証スキームを構築するときに HTTP 認証が使用されると想定していたためだと思います。
于 2013-02-27T09:44:36.507 に答える
31
これは古い質問ですが、404 を返すという選択肢が実際に持ち出されることはありませんでした。たとえば、問題の安全な Web ページがシステム管理ページであるとします。または、より一般的には、ユーザーがアクセスできないシステム内のレコードであるとします。理想的には、アクセス権がないことは言うまでもなく、そこにページ/レコードがあることさえ悪意のあるユーザーに知られたくないでしょう。このようなものを構築しているとき、認証されていない/承認されていないリクエストを内部ログに記録しようとしますが、404 を返します。
OWASP には、攻撃者がこの種の情報を攻撃の一部としてどのように使用できるかについて、さらに詳しい情報があります。
于 2014-12-25T09:09:45.023 に答える
22
この質問は少し前に尋ねられましたが、人々の思考は進みます。
このドラフト (Fielding と Reschke が作成) のセクション 6.5.3では、ステータス コード 403 にRFC 2616で文書化されているものとは少し異なる意味が与えられています。
これは、多くの一般的な Web サーバーやフレームワークで採用されている認証および承認スキームで何が起こるかを反映しています。
最も顕著なと思われる部分を強調しました。
6.5.3. 403禁止します
403 (Forbidden) ステータス コードは、サーバーが要求を理解したが、承認を拒否したことを示します。リクエストが禁止された理由を公開したいサーバーは、その理由をレスポンス ペイロード (存在する場合) に記述することができます。
要求で認証資格情報が提供された場合、サーバーはそれらがアクセスを許可するには不十分であると見なします。 クライアントは、同じ資格情報でリクエストを繰り返すべきではありません。クライアントは、新しい資格情報または異なる資格情報で要求を繰り返すことができます。 ただし、資格情報とは関係のない理由で要求が禁止される場合があります。
禁止されたターゲット リソースの現在の存在を「隠す」ことを望むオリジン サーバーは、代わりにステータス コード 404 (Not Found) で応答する場合があります。
どのような規則を使用するにせよ、重要なことは、サイト/API 全体で統一性を提供することです。
于 2014-05-22T10:54:48.053 に答える
11
ログインしていないか、適切なユーザー グループに属していない
あなたは2つの異なるケースを述べました。ケースごとに異なる応答が必要です。
- まったくログインしていない場合は、401 Unauthorizedを返す必要があります。
- ログインしているが、適切なユーザー グループに属していない場合は、403 Forbiddenを返す必要があります。
この回答に対して受け取ったコメントに基づく RFC に関する注意:
ユーザーがログインしていない場合、認証されていません。これに相当する HTTP は 401 であり、誤解を招くように RFC では Unauthorized と呼ばれています。セクション 10.4.2が401 Unauthorizedについて述べているように:
「リクエストにはユーザー認証が必要です。」
認証されていない場合は、401 が正しい応答です。ただし、無許可の場合は、意味的に正しい意味で 403 が正しい応答です。
于 2012-10-01T14:34:32.210 に答える
-7
401対403の場合、これは何度も回答されています。これは本質的に「アプリケーション」の議論ではなく、「HTTP リクエスト環境」の議論です。
ロール・ユア・オウン・ログインの問題（アプリケーション）について質問があるようです。
この場合、HTTP Auth とログイン ページ (HTTP Auth の設定に関連付けられていない) を使用しない限り、ログインしていないだけでは 401 または 403 を送信するのに十分ではありません。ファイルへのアプリケーションレベルのアクセスのために、(要求されたリソースの代わりに) 独自のログイン画面が表示された「201 Created」を探しているようです。これは言います：
「聞いた、ここにあるけど、代わりにこれを試してみてください（あなたはそれを見ることはできません）」
于 2014-12-12T19:01:43.510 に答える