zend-framework - Web アプリケーションでの HTTP ステータスコードの使用

Question

私は現在、(Zend Framework を使用して) Web アプリケーションを構築しており、次のような基本的なHTTP ステータスコードのいくつかを取得しています。

現時点では、ユーザーが特定のリソースへのアクセスを許可されていることを確認する基本的なACLチェックを実装しました。これはコントローラープラグインとして実装され、routeShutdown イベントで実行されます。次のように機能します。

ユーザーの役割を取得します。ユーザーがログインしていない場合は、「ゲスト」の役割を割り当てます
ユーザーのルールがリソースへのアクセス権を持っていることを確認してください

2.1. がリソースにアクセスできず、ゲストである場合は、アクセスしようとしていたリソースを保存し、ログインプロンプトに転送します。認証情報を提供すると、(HTTP リダイレクトステータスコードを介して) 元のリソースにリダイレクトされます。

2.2. ユーザーが認証され、ACL がリソースへのアクセスを拒否した場合、ユーザーはエラーコントローラーに転送され、noPrivilegies と呼ばれるアクションに転送されます。
ユーザーがアクセス権を持っている場合は、リクエストを通常どおり続行します。

さて、私の質問：

2.1 シナリオで HTTP 401 を使用できますか? クライアントから送信された WWW-Authenticate ヘッダーフィールドが必要なわけではありません。ログインフォームからログインするだけです。しかし、彼は要求されたリソースにアクセスできなかったため、要求は 200 OK ではなかったと思います。
2.2 シナリオで HTTP 401 を使用できますか? ここでも同じ理由で、WWW-Authenticate は役に立ちません。おそらく、HTTP 403 Forbidden を使用する方が良いでしょうか?
これら 2 つのシナリオについて、他に推奨するステータスコードはありますか?
アプリケーションから通常返されるその他のステータスコードは何ですか?また、それらが適用されるのはいつですか?

score 2 · Accepted Answer

ゲストロールが一部のアクションの実行を許可されている場合、ログインしていないことはエラーではないため、プロセスのステージ2.1で4xx応答またはその他の形式のエラーは保証されません。
401も403も、アプリケーションレベルの「許可が拒否されました」には理想的ではありませんが、401の「応答にはWWW認証ヘッダーフィールドが含まれている必要があります」と403の「承認は役に立ちません」を比較検討します（ほとんどの場合、私はこれまでに遭遇したことは同意しているようです）続行する前にHTTPレベルの認証を要求している場合は、401が適切な応答であり、他のすべての場合は403が適切です。したがって、おそらく403です。

score 2 · Accepted Answer

403が正しい反応だと思います。HTTP仕様では、401 は HTTP レベルの認証が可能で必要な場合、403 はユーザーがリソースへのアクセス許可を持っていない場合です。あなたのアプリの場合、ユーザーはログイン済みであり、別のアカウントを使用できると期待するのは合理的ではありません。

score 1 · Accepted Answer

通常、ステータスコードを使用して「アプリケーション」レベルの認証の失敗を報告することはありません。それは通常、アプリを介して報告されます。

そして、それを行うことは理にかなっています。「http」の意味で「ページ」にアクセスできるため。それが理にかなっている場合、彼らはそのページのアプリケーション処理にアクセスできません。

私が言いたいのは、通常、クライアントにデータを返すときに、コードを気にしたり、自分でコードを設定したりする必要がないということです。ウェブサーバーに任せて、「抽象化された」応答方法を提供します。つまり、典型的な「無効なユーザー名またはパスワード」ページなどです。

あくまで私見ですが。

score 1 · Accepted Answer

私は最近、同様の方法で機能するものを実装しました。ユーザーがログインする必要がある場合は 401 応答を返し、ログイン後にアクセス許可のないものにアクセスしようとした場合は 403 を返します。

http 応答の理由フレーズを何かに設定して、失敗の理由を示すこともできます。

zend-framework - Web アプリケーションでの HTTP ステータス コードの使用