14

私はモバイルアプリ用のAPIを設計していますが、それをRESTfulに保ちたいと思っています。
APIは基本HTTP認証を使用して承認されますが、ユーザーが初めてアプリを開くときは、最初にログインする必要があるため、ユーザーの資格情報を確認するAPIを設計する必要があります。これにより、ユーザー名とパスワードのペアが受け入れられます。成功を返すか、それに応じて失敗します。
問題は、URLがどうあるべきかということです。/loginは良いものではないと思います。

4

5 に答える 5

13

通常、HTTPリクエストを介して機密データを渡すことは、不適切な方法と見なされています。GET

パスワード情報は機密データであり、べき等操作GETは要求であるというルールを破る例外の 1 つです。

なぜこれが例外なのですか？ブラウザの履歴とサーバー ログにGETリクエストが保存されます。この機密情報は、両方の場所でプレーン テキストとして表示されることを意味します。したがって、誰かがどちらかを手に入れた場合、その情報は彼らの手に渡ったことになります。

POSTこの機密情報を RESTful API に渡すには、HTTP 要求を使用する必要があります。これは、ブラウザーが機密情報を保存せず、サーバーがログに記録しないためです。ただし、防御の最前線は、セキュア HTTP (HTTPS) を使用して、この情報が部外者から確実に保護されるようにすることです。

したがって、この情報をHTTP 要求の本文に入れて HTTPS URL に渡します。

于 2014-05-14T17:33:58.383 に答える
9

適切なアプローチはGET、現在のユーザーのアカウント/プロファイル情報を要求することです。ユーザー名、設定、アバターの URL などを返すようにしますme。これは、認証ユーザーの省略形の識別子として頻繁に使用されます。

GET https://api.example.com/profiles/me
HTTP/1.1 200 OK
{
  "username": "bob",
  "id": "xyz",
  "created_at": 123,
  "image_url": "https://example.com/bob.png"
}
于 2012-04-14T01:03:10.613 に答える
7

ウィキペディアから：

クライアントとサーバーの通信は、リクエスト間でクライアント コンテキストがサーバーに保存されないため、さらに制限されます。クライアントからの各リクエストには、リクエストを処理するために必要なすべての情報が含まれており、セッション状態はすべてクライアントに保持されます。

サーバーはクライアントからのセッション状態を保存しないため、APIはログイン/ログアウト機能を公開すべきではありません: 各リクエストでユーザー資格情報を送信する必要があり、サーバーは毎回それらを検証する必要があります。

SO でこの議論を確認してください。この概念を明確にしています。

于 2012-04-14T02:22:22.153 に答える
0

カルロスに同意します-通常の安静なAPIではセッションがないため、一度認証してからセッションを再利用することはできません。実際には、すべての呼び出しで資格情報セットを渡す必要があります(理想的ではありません)。

このシナリオでは、openAuth (http://www.oAuth.net) のいずれかを使用する方がよいように思えます。これは、アプリが最初に実行されたときに認証を行い、すべての呼び出しでアクセスを許可するアクセス トークンを生成することで機能します。 (+ リフレッシュ トークン)。

(アクセス トークンは状態であると主張することもできますが、少なくとも一般的にはかなり長生きします)。

于 2012-04-14T07:35:26.433 に答える