web-dev-qa-db-ja.com

RESTfulログインの失敗:401またはカスタム応答を返します

これは概念的な質問です。

RESTful Webサービスに対するログインアクションをサポートする必要があるクライアント(モバイル)アプリケーションがあります。 WebサービスはRESTfulであるため、これはクライアントがユーザーからユーザー名/パスワードを受け入れ、サービスでそのユーザー名/パスワードを確認し、その後のすべてのリクエストでそのユーザー名/パスワードを送信することを覚えていることになります。

このWebサービスの他のすべての応答は、JSON形式で提供されます。

問題は、Webサービスを照会して、特定のユーザー名/パスワードが有効かどうかを確認するとき、Webサービスが常に成功または失敗を示すJSONデータで応答するのか、または適切な資格情報とHTTPでHTTP 200を返すのかを調べることです不正な資格情報で401。

私が尋ねる理由は、他の一部のRESTfulサービスが、資格情報が有効であるかどうかだけを尋ねている場合でも、不正な資格情報に401を使用するためです。ただし、401応答の私の理解は、それらが有効な資格情報なしでアクセスすることになっていないリソースを表すことです。ただし、ログインリソースの目的はすべて、資格情報が有効かどうかを通知することなので、ログインリソースは誰でもアクセスできるようにする必要があります。

別の言い方をすれば、私には次のようなリクエストがあるようです。

myservice.com/this/is/a/user/action 

不正な資格情報が提供された場合は401を返します。しかし、次のようなリクエスト:

myservice.com/are/these/credentials/valid

その特定のURL(要求)は有効な資格情報を使用して、または使用せずに承認されるため、401を返さないでください。

これについて何らかの形で正当な意見を聞きたいです。これを処理する標準的な方法は何ですか?これを論理的に適切に処理する標準的な方法は何ですか?

86
Matt

最初に。 401は、失敗したログインが発生したときに送信する適切な応答コードです。

401 Unauthorized 403 Forbiddenと似ていますが、特に認証が必要で、失敗したか、まだ提供されていない場合に使用します。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールドが含まれている必要があります。

あなたの混乱、myservice.com/are/these/credentials/validをチェックするだけで401を送り返す、私は、RESTでブール要求を行うことはしばしばRESTful制約によって間違っているという事実に基づいていると思います。すべてのリクエストはリソースを返す必要があります。 RESTfulサービスでブール型の質問を行うことは、RPCに至るまで滑りやすいスループです。

今、私はあなたが見たサービスがどのように振る舞っているのか知りません。しかし、これを解決する良い方法は、GETしようとするAccountオブジェクトのようなものを用意することです。資格情報が正しい場合は、アカウントオブジェクトを取得します。「チェック」のためだけに帯域幅を無駄にしたくない場合は、同じリソースでHEADを実行できます。

アカウントオブジェクトは、個々のリソースを作成するのが難しい厄介なブール値をすべて格納するのに適した場所でもあります。

105
Cleric

401は、リクエストが認証ヘッダーフィールドを必要とし、認証が失敗した場合にのみ送信する必要があります。 Login APIは認証を必要としないため、401は私の意見では間違ったエラーコードです

ここの標準に従って https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

* 10.4.2 401不正

要求にはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド(セクション14.47)を含める必要があります。クライアントは、適切なAuthorizationヘッダーフィールドを使用してリクエストを繰り返すことができます(セクション14.8)。要求にすでに認証資格情報が含まれていた場合、401応答は、それらの資格情報に対する認証が拒否されたことを示します。 401応答に以前の応答と同じチャレンジが含まれており、ユーザーエージェントがすでに少なくとも1回認証を試みている場合、ユーザーは応答で指定されたエンティティを提示する必要があります。 HTTPアクセス認証については、「HTTP認証:基本およびダイジェストアクセス認証」[43]で説明されています。*

16
vinksharma