シンプルなREST風のHTTP APIを公開する小さなアプリケーションを書いています。権限がないために失敗を通知する方法を決定しようとして立ち往生しています。
アプリには認証用のAPIがありませんが、代わりに、別のサービスを介してクライアントが取得したセッショントークンを含むCookieの存在に依存しています。アプリはセッションを検証し、検証プロセスで取得したIDを使用してアプリ固有の承認を実行します。クライアントがこのアプリに対して直接認証する方法はありません。
私の問題は、不正な要求を拒否するための明白なHTTPステータスコード「401 Unauthorized」が「WWW-Authenticate」ヘッダーで指定されていることです。 rfc2616 sec 10.4.2 を参照してください。
応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド(セクション14.47)を含める必要があります。
これは珍しい問題だとは信じられません。より一般的な用途を含めるために単に401をオーバーロードすることは一般的ですか? auth/eダイアログをポップアップするブラウザーについてはどうですか(偶然にもテストで見たことがないため、POSTで発生しない可能性があります)?
結論:このコンテキストで401を使用しても大丈夫ですか、それとももっと良い解決策がありますか?
通常、クライアントが認証して問題を解決できる場合は401を送信しますが、APIで認証する方法を提供していないため、代わりに403エラー(禁止)を返すことをお勧めします。これはヘッダーを必要とせず、サービスにアクセスできないことをクライアントに示します。
次のようなものを返します:
HTTP/1.1 401 Unauthorized
Location: https://example.com/auth-app/login