使用したHTTPステータスコードのような

Question

私は現在、（Zend Frameworkのを利用して）、Webアプリケーションを構築することだし、ダウン基本HTTP statusコードの一部を得ている、：

• 404行方不明コントローラ/アクション
に現時点ではApache

によって返されたサーバーの例外の

の3xxは、私はちょうど、ユーザーが許可していることを確認するいくつかの基本的なACLを実装していますdを使用して特定のリソースにアクセスします。これはcontroller pluginとして実装され、routeShutdownイベントでその処理を行います。次のように動作します。

1. ユーザーの役割を取得します。ユーザーがログインしていない場合は、「ゲスト」ユーザのルールは、リソース

   2.1へのアクセス権を持っていることを

2. チェックの役割を割り当てます。 ではなく、がリソースにアクセスでき、ゲストである場合は、アクセスしようとしていたリソースを保存し、ログインプロンプトに転送します。資格情報を入力すると、元のリソースにリダイレクトされます（HTTPリダイレクトステータスコード経由）

   2.2。ユーザが認証され、ACLがリソースへのアクセスを拒否した場合、彼はエラーコントローラに転送され、noPrivilegiesと呼ばれる動作に転送されます。

3. ユーザーがアクセス権を持っている場合は、通常どおりリクエストを続行します。

さて、私の質問：

1. CAN /私はHTTP 401が2.1シナリオのために使うべきでしょうか？クライアントから送信されたWWW-Authenticateヘッダーフィールドが必要なのと同じではありません。私はログインフォームを使ってログインする必要があります。しかし、依頼されたリソースにアクセスできないので依然として200 OKではないと私は考えています。
2. 2.2シナリオでHTTP 401を使用できますか。同じ理由で、WWW-Authenticateは役に立ちません。おそらく、HTTP 403 Forbiddenを使用する方が良いでしょうか？
3. これらの2つのシナリオでは、他のステータスコードをお勧めしますか？
4. 通常、アプリケーションから返されるその他のステータスコードは、どのような場合に適用されますか？

Answer 1

1. 。

2. アプリケーションレベルの「許可が拒否されました」では401も403も実際には理想的ではありませんが、401の「重み付けはWWW-Authenticateヘッダーフィールドを含む必要があります」という403の「認証は役に立ちません」に対して、私がこれまでに遭遇したほとんどの場合）は、進行する前にHTTPレベルの認証を要求し、他のすべてのケースで403が適切であれば、401が適切な応答であると思われます。あなたのケースでおそらく403。

Answer 2

通常、ステータスコードを使用して「アプリケーション」レベルの認証エラーを報告することはありません。これは一般的にアプリを通じて報告されています。

それを行うのが理にかなっています。彼らはがの 'http'の意味から 'ページ'にアクセスできるので、そのページの処理にアクセスすることはできません。

私が言っていることは、一般に、コードを心配することはなく、クライアントにデータを返す際には、自分で設定することです。それをウェブサーバーに任せ、応答の「抽象化」方法を提供します。すなわち、典型的な「無効なユーザー名またはパスワード」ページなど

私の見解ですが、

Answer 3

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

また、http応答に理由の句を設定して、失敗の理由を示すこともできます。

Answer 4

私は403が正しい応答だと思います。 HTTP specによると、401はHTTPレベルの認証が可能で必要な場合、403はユーザーにリソースへのアクセス権がない場合です。あなたのアプリの場合、ユーザーはログインしており、別のアカウントを使用できると期待するのは無理です。ゲスト役割はエラーではありませんに記録されていないので、その後何の4xx応答またはエラーの他のフォームはあなたのプロセスの段階2.1で保証されていない、いくつかのアクションを実行させることができることを提供

Answer 5

であっても、具体的HTTPの仕様に記載されていない、一般的な方法は

401です - 認証エラーのために 403 - 許可エラーのために

あなたが認証を必要としない場合は401を使用しないようにしてくださいユーザー。私は最近、HTTPクライアント（一般的なブラウザではない）で、WWW認証ヘッダーではなく401が表示されたときにエラーを記録するという問題に直面しました。これはクライアント側のバグですが、人々が401をどのように認識しているかを示しています。