ログインフォームのHTTPステータスコードを修正しますか？

Question

私はアプリの認証を実装しており、プラグイン可能なシステムには「認証方法」を使用しています。これにより、HTTP Basic認証とHTMLベース認証の両方を実装することができます。

HTTP Basic/Digest認証の場合、サーバーは401 Unauthorized応答ヘッダーを送信します。しかし、HTTP/1.1 RFCに従って：

応答は、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダフィールド（セクション14.47）を含まなければなりません。

「html」WWW-Authenticateヘッダーがわからないので、401をHTMLログインフォームで送信することは不適切です。これに代わる方法はありますか？私はRESTfulな方法で私のアプリを設計したい。

HTMLベースのログインフォームの正しいHTTPステータスコード（およびヘッダー）は何ですか？そして、ログインに失敗したときの正しいコードは何ですか？

注：：私はダイジェスト認証には興味がありません。

Answer 1

私はあなたが401を限り、私はそれがよりそのコンテンツへのリクエストに応答するように設計を理解しているので、これは、同様に非HTML要求のための真のかもしれ400

で対応すべきだと思います認証を要求し、認証要求に応答しない。

HTMLは常にRESTful APIを純粋に使用できるとは限りません。したがって、ここでは角を切り取っても問題ありませんが、この特殊なケースでは表示されない場合があります。

Answer 2

これは、人によって使用される最も確立されたHTTPクライアントがブラウザであることが主な理由で、難しい質問です。 RFCによれば、WWW-Authenticateヘッダーには何も含めることができます。基本認証とダイジェスト認証は、さらに標準化されたチャレンジ/レスポンスメカニズムの2つの例にすぎません。 html-form id=fooのようなチャレンジを指定して、401とHTMLフォームを返すだけです。また、同一のWWW-Authenticateヘッダー内で複数の課題を指定できることを仕様から思い出してください。しかし、私はさまざまなスキームで広範囲にブラウザをテストした経験がありません。 HTMLの場合

Answer 3

login form HTTPステータスが200 OKあるべき

を更新しました2016年2月17日@。

error httpステータスをよく使う401 Unauthorized。 名前を混同することができる（、401は認証についてです。RFC7235

3.1。401権限

401（Unauthorized）ステータスコードは、要求が は、それが有効な認証資格情報がないため、適用されていないことを示し、は、 に少なくとも1つのチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション4.1）を送信しなければならない（MUST）ターゲットリソースに対して を含む。

要求に認証資格情報が含まれている場合、401応答は、その資格情報に対して許可が拒否されたことを示します。ユーザエージェントは、新しいか置換されたAuthorizationヘッダフィールド（4.2節）で要求を繰り返すことができる（MAY）。 401レスポンスが以前のレスポンスと同じチャレンジを含み、ユーザエージェントが少なくとも1回はすでに認証を試みた場合、ユーザエージェントは通常、関連する診断情報を含んでいるので、囲まれた表現をユーザに提示すべきである（SHOULD）。

あなたがもし何の許可権を処理しないようにしたい場合は、403 Forbidden [RFC7231]

HTTP 422を必要とするかもしれないWebDAVのために使用されますが、意味がニーズに合うかもしれません。 （ほとんどの場合は推奨されません）

詳細については、Cássio Mazzochi Molinのコメントをご覧ください。 2016年2月12日更新@

---

（これが受け入れ答えへの参照です。）

login form HTTPステータスが200する必要があります。

error httpステータスをよく使う400。

HTTP 422がWebDAVに使用されていますが、その意味はニーズに合うかもしれません。 HTTP 401は承認用です。認証には適していません。

---

オリジナル2016年2月12日@ HTTP 422 422は、代替選択肢である今400/401 HTTP以外のより良い選択です。

サーバーがデータを理解しているが、データの一部が正しくないためです。つまり、ユーザー名/パスワードが間違っていることをクライアントに示すことができます。

11.2。 422処理不可能エンティティ

422（処理不可能なエンティティ）ステータスコード（したがって 415（サポートされていないメディアタイプ）ステータスコードは不適切である）サーバ は、要求エンティティのコンテンツタイプを理解する手段、および要求の 構文エンティティが正しい（したがって、400（Bad Request） ステータスコードは不適切です）、含まれている 命令を処理できませんでした。例えば、このエラー状態は、XML リクエストボディが、整形式（すなわち、構文的に正しい）が、意味的に誤りのあるXML命令 を含む場合に発生し得る。この約1

RFC4918

Answer 4

何？

公開ページでログインフォームを要求する場合、あなたが望む結果を得るので、200のステータスコードです：

GET /login -> 200 

あなたが「didnのHTTPレベルの認証を必要とするページを要求あなたが既に持っている、認証はクッキーベースのセッションのとき

GET /secured -> 401 with WWW-Authenticate header 

：T開始（基本的なHTTP、SSL証明書など）は、ブラウザ自体を伝える必要があるアプリケーションは、それはあなたのために、この認証を開始する必要があることクッキー（もしそうでなければ、あなたは1つはページを要求するときにクッキーヘッダーが設定されています）、このCookieはあなたが/securedというURIにアクセスすることを許可されているとは言いません。したがって、このURIにアクセスしようとすると、「403禁じられた」状態になるはずです。そして、「ログイン」アクションが悪いの資格情報としてちょうどこのクッキーのアプリケーションの許可のアクセスを行うためのPOSTリクエストを使用してアプリケーションの状態を変更する以上のものではありませんので...

ログイン：

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 403 with HTML login form, displaying errors 

良い資格情報ではなく、十分な権限を持つログイン：良い資格情報との十分な権限を持つ中

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 403 with HTML page saying "I know you are John, but you can't get this page" 

ログイン：

GET /secured -> 403 with HTML login form (with action="/login") 
POST /login -> 302 (temporary redirection to /secured) 
GET /secured -> 200