HTMLベースのログインフォームでhttp 401ステータスコードを返す必要がありますか？

HTMLベースのログインフォームでhttp 401ステータスコードを返す必要がありますか？このページは専用のログインフォームであり、他の意味のあるコンテンツはありません。サイトフレームワークのみです。ただし、URLは、意味のあるコンテンツはあるが、ログインが必要なページの場合もあります。このセットアップではステータスコード401のみが返され、ユーザーに基本認証を求めるプロンプトは表示されないことに注意してください。

標準を見ると、401はHTMLベースのログインフォームには不適切なステータスコードのようです。しかし、私はそうすることの悪い結果を経験したり聞いたりしたことがありません。

401を送信するとき、「応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション14.47）を含める必要があります。」

ここで言及されている要件：

http://tools.ietf.org/html/rfc2616#section-10.4.2

詳細はこちら：

http://tools.ietf.org/html/rfc2617#section-3.2.1

ログインフォームの存在に基づいて、ページをインデックス付けするかどうかにかかわらず、検索エンジンを回避できる方法があることはわかっていますが、httpステータスコード、具体的には401を使用することをお勧めします。 WWW-Authenticateヘッダー要件に適合しない場合は完全一致。

この場合に401を使用しない理由はありますか？意味論的に、httpレベルで承認されないこととアプリケーションレベルで承認されることの間に違いはありますか？もちろん、両方を使用できますが、アプリケーションレベルで実装しないようにするためだけに、httpレベルでの認証ではないのですか

お気づきのように、RFC 2616では、401応答にRFC 2617 WWW-Authenticateヘッダーを添付する必要があります。次のような偽のヘッダーを送信することで、その要件に技術的に準拠できると思います。

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

しかし、ブラウザーが理解できるチャレンジを含まない401応答が表示された場合にブラウザーが何をするかはわかりません。すべてではないにしても、ほとんどの場合、ユーザーにリクエスト本文を提示すると思いますが（RFC 2616は、認証が失敗した場合に実行する必要があるとしています）、どちらのRFCもそう明示していないようで、合法的に一般的なエラーメッセージを表示するだけです。代わりに。

可能な代替方法（他の誰もがそうであるように200応答だけを使用したくない場合）は、403 Forbiddenステータスコードを使用することです。これは広く使用されている応答コードであり、私が知る限り、ほぼすべてのインタラクティブなユーザーエージェント（つまり、検索エンジンやダウンロードマネージャーではなくブラウザー）は、少なくともユーザーにコンテンツを提示することによって、それに応答する必要があります。それが十分に長い場合。

403ステータスコードの説明には「[a] uthorizationは役に立たない」と書かれていますが、IMOは、RFC 2617認証または類似のプロトコルレベルの承認メカニズムを参照していると理解すべきです。ブラウザに関する限り、フォームを送信して、それに応答してCookieを受信することは、「承認」または他の何かとしてカウントされるかどうかはわかりません。

より一般的に使用されているメカニズムの1つは、認証されていない要求に別のログインページに一時的にリダイレクトして応答し、元のURLをパラメーターとして渡して、ユーザーが認証に成功した後にリダイレクトできるようにすることです。ただし、ナイーブな実装では、悪意のあるユーザーがログイン後にユーザーを任意のURLにリダイレクトするログインリンクを作成できる可能性があることに注意してください。これがセキュリティ上の問題である可能性がある場合は、たとえば既知の安全なパターンに一致するURLを返すか、変更を防ぐためにメッセージ認証コードで戻りURLを保護します。

いずれの場合も、ログイン後に認証トークンを格納するためにHTTP Cookieを使用している場合は、Varyヘッダーを応答（認証の前と後の両方）に含めて、不適切なキャッシュを防止する必要がありVary: Cookieます。

まず、ページにログインが必要な場合は、robots.txtでブロックする必要があります

次に、ロボットがページに到達した場合、401エラーは適切です。

おそらく、ステータスコードは人間以外の人にも[一部のブラウザにも役立ちますか？]

ログインメソッドによって独立して、正しいヘッダーが送信されるべきです

たとえば、将来的には、HTMLコード全体ではなく、ページヘッダーを要求することによってのみそれ自体を認証するラッパークライアント（Webブラウザーではない）を記述する必要があるかもしれません

ユーザーリストと同じデータベースを使用して、両方の方法でログインアプリケーションを実装できます