2

この質問に対する @Veraticus の回答によると、Web 認証フレームワークは current_user の ID をセッション IDに保存して、データベースからユーザーをすばやく簡単に取得します (データベースで新しいクエリを使用して毎回ユーザーを取得する必要はありません)。 .

これは、私が書いている API を通じて、(パフォーマンス上の理由から) 自分のサーバーでまさにやりたいことなので、素晴らしいことです。

しかし、セッションIDについて疑問に思っています...つまり、サーバーがセッションを処理する場合、クライアントはセッションIDを提供する必要があります。

ただし、別のことについても疑問に思っています。一般に、Web API はAPI キー(たとえば、https://api-docs.heroku.com/ ) を使用しています。また、API キーとセッション IDの使用は、クライアントにとって複雑な場合があります...

各 HTTP リクエストで受信した認証トークンを使用して Heroku がデータベース クエリを実行しないことを願っています。しかし、そうでない場合、セッション IDなしでユーザーを認証するにはどうすればよいでしょうか?

よくわかりません。アイデアをありがとうございました。

4

1 に答える 1

5

セッション トークンと認証トークン/API キーは、認証に対するアプローチが大きく異なり、さまざまなユース ケースに対応します。

セッションは、たとえば HTML Web サイトで最も一般的に使用されます。たとえば、ユーザーはサーバーで一度認証され (通常はユーザー名とパスワードを提示することによって)、その後、要求ごとに再認証することなくサイトを閲覧します。これには、セッション状態を維持してメモリに保存できる必要があるサーバーと、セッション ID (通常は Cookie に) を保存して毎回提示できる必要があるクライアントの要件があります。リクエスト。

認証トークン/API キーは、リクエスト間で維持する状態がないという意味で、より軽量であると見なすことができます (サーバーはステートレスです)。すべての操作はほぼアトミックであり、クライアントは要求ごとに (トークン/キーを使用して) 自分自身を認証する必要があります。このアプローチは、ユーザーの Web ブラウザーではなく、「プログラム」を介したサーバー リソースへのプログラムによるアクセスに適しています。

IMO、クライアントが両方を同時に使用するのは本当に意味がありません。ユーザーがセッションですでに認証されている場合、サーバーは誰がそれを呼び出しているかを既に認識しており、追加の API キーを要求する必要はありません。

OTOH、サーバーWeb API は、クライアントから両方の形式の認証を受け入れるのに十分スマートである可能性があります。呼び出されると、クライアントがすでにセッションを確立しているかどうかを確認し (この場合、誰が呼び出しているかを認識しています)、そうでない場合は、クライアントが何らかの API キー/認証トークンを渡しているかどうかを確認し、その場でユーザーを認証します。

最後の質問に答えるには、キーまたはトークンで保護された API はステートレスであるため、各呼び出しを個別に認証する必要があります。つまり、キーを検証するために、リクエストごとにクライアントに関する情報をロードする必要があります。通常、この情報は DB に保存されるため、サーバーが処理を高速化するために何らかのキャッシュを実装していない限り (Heroku の場合が最も可能性が高い)、リクエストごとに DB ヒットが発生する可能性があります。

于 2012-11-03T19:14:58.360 に答える