構成ファイルにあるすべてのものを表示できなくても、エラー ページへの「すべての」ユーザー アクセスを事前に拒否したために、問題が発生していることは明らかです。
つまり、基本認証によって保護されているエラー ページを返送することはできません。サーバーは、この再帰的な状況を適切に処理する方法を認識していません。
.htaccessカスタム エラー ページを含むディレクトリに対して要求された承認を明示的にオーバーライドして無効にしていることを確認してください。
たとえば、エラー ファイル ディレクトリが/error/指定したとおりである場合:
<Directory /error/>
Order allow,deny
Allow from all
</Directory>
@フレッド・ガント
あなたの質問に答えるために、401 プロセスについて少し詳しく説明させてください。HTTP がステートフル プロトコルではないことを理解しておくと役立ちます。言い換えれば、すべてのリクエストとすべてのレスポンスは、後続のリクエストとレスポンスから分離して存在します (実際の HTTP プロトコルに関しては、もちろん、ブラウザとサーバーの両方が各リクエストに関するステートフルな情報を維持し、一連のリクエストを関連付けようとすることができます)。相互の要求の)。
- サーバー構成では、保護されるサーバー上の領域を定義し、アクセスを可能にする資格情報を定義します。
- 保護領域内のオブジェクトが最初に要求されると、サーバーは 401 ヘッダー、
WWW-Authenticateヘッダーと認証チャレンジ、およびオプションのコンテンツで応答します。リクエストとレスポンスのプロセスが完了しました。
- ブラウザーは完全な応答を受け取り、サーバーの応答で送信された認証チャレンジを解析し、人間が判読できる形式で表示します。
- 承認プロセスをキャンセルすることを選択した場合、ブラウザーは応答本文 (存在する場合) を表示します。
- ログイン認証情報を提供することを選択した場合、ブラウザはサーバーから要求された形式でそれらをエンコードし、新しい要求を開始します。
- この 2 番目の要求によって保護領域内のオブジェクトが要求されると、サーバーは提供された資格情報を検証または無効化し、要求されたオブジェクトを返すか、以前と同じ 401 ヘッダーとコンテンツを返します。
- 資格情報を提供しようとした後にブラウザーが同じ 401 ヘッダー/コンテンツを受信した場合、資格情報を再度要求されるか、サーバーから 401 ヘッダーと共に送信された応答本文が表示されます。
- サーバーが提供された資格情報を検証し、要求されたオブジェクトを返す場合、ブラウザーは現在のブラウザー セッションが終了するまで、各要求で同じ資格情報を送信し続けます。これをブラウザの「認証後モード」と呼びましょう。
注意すべき最も重要なことは、ブラウザーからのログイン資格情報からの要求を見る前に、サーバーから完全な応答を受信することです。
また、ログイン資格情報の要求を提示する必要があることをブラウザーが認識する唯一の方法は、401 応答ヘッダーだけでなく、WWW-Authenticateヘッダーとチャレンジも存在する場合です。
401 カスタム エラー ドキュメントが原因で、ブラウザーがログイン資格情報を要求するのではなく、エラー ページを表示する場合は、認証ヘッダーとチャレンジ、または 401 ステータス コード自体が、401 エラー ドキュメントに付随するように構成されていないことが原因である必要があります。
私たちにはばかげているように聞こえますが、サーバーの人間以外のロジックにとっては、認証チャレンジが送信されなくても、認証されていないすべてのリクエストにエラー ドキュメントを送信し、実際のオブジェクトをすべてのブラウザーに送信することは完全に理にかなっています。 「認証後モード」。
カスタム 401 エラー ファイル ディレクティブをコメント アウトし、ブラウザでログインして、保護されたページをロードし、カスタム 401 エラー ファイル ディレクティブを再度有効にしてから、保護されたすでに「認証後モード」になっているブラウザのページ。
私が期待しているのは、事前承認されたブラウザーがこの要求で資格情報を送信し続け、サーバーが要求された保護されたオブジェクトで応答することです。
そのため、承認されたすべてのリクエストはいつものように適切に機能していますが、401 エラー ドキュメントやヘッダーに認証チャレンジ トリガーが含まれていないため、ブラウザーに資格情報の入力を求める必要があることがわかります。