アプリの認証を実装しており、「認証方法」を備えたプラグ可能なシステムを使用しています。これにより、HTTP基本認証とHTMLベースの認証の両方を実装できます。
HTTP基本/ダイジェスト認証を使用すると、サーバーは401 Unauthorized
応答ヘッダーを送信します。ただし、 HTTP/1.1 RFC によると:
応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド(セクション14.47)を含める必要があります。
「html」WWW-Authenticateヘッダーがわからないため、HTMLログインフォームを使用して401
を送信することは不適切と思われます。これに代わるものはありますか?アプリをRESTfulな方法で設計したいと思います。
HTMLベースのログインフォームの正しいHTTPステータスコード(およびヘッダー)は何ですか?そして、ログインが失敗したときの正しいコードは何ですか?
注:ダイジェスト認証には興味がありません。
HTMLの場合、400で応答する必要があると思います。
401は、認証要求に応答するのではなく、認証を必要とするコンテンツへの要求に応答するように設計されていると私が理解している限り、これはHTML以外の要求にも当てはまります。
HTMLではRESTfulAPIを純粋に使用できるとは限らないため、あちこちでコーナーを切り取っても問題ありませんが、この特定のケースでは見られないより良い方法があるかもしれません。
これはどうですか ?
公開ページであるログインフォームをリクエストすると、必要なものが得られるので、200のステータスコードになります。
GET /login -> 200
開始していないhttpレベルの認証(基本http、SSL証明書など)が必要なページを要求する場合、アプリケーションはブラウザー自体に、この認証を開始する必要があることを通知する必要があります。
GET /secured -> 401 with WWW-Authenticate header
認証がCookieベースのセッションである場合、既にCookieがあります(そうでない場合は、ページを要求するときにset-cookieヘッダーが付いたCookieを取得します)が、このCookieはアクセスが許可されていることを通知しません/secured
ウリ。したがって、このURIにアクセスしようとすると、「403forbidden」ステータスが表示されます。その場合、「ログイン」アクションは、POSTリクエストを使用してアプリケーションの状態を変更するだけで、アプリケーションにこのCookieへのアクセスを許可させるだけです。
不正な資格情報でログインします。
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
これは難しい質問です。これは主に、人々が使用する最も確立されたHTTPクライアントがブラウザであるためです。 RFCによると、WWW-Authenticate
ヘッダーには何でも含めることができます。基本認証とダイジェスト認証は、さらに標準化されたチャレンジ/レスポンスメカニズムの2つの例にすぎません。 html-form id=foo
のようなチャレンジを指定して、HTMLフォームとともに401
を返すだけです。また、同じWWW-Authenticate
ヘッダー内で複数のチャレンジを指定できることを仕様から思い出してください。ただし、さまざまなスキームでブラウザーを広範囲にテストした経験はありません。