質問

単純な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
ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top