2

私の理解では、RESTful サービスは完全にステートレスであるべきです。サービスを呼び出すたびに、正しく動作するために必要なすべての情報を渡す必要があります。

ただし、認証に関しては、特にセッション管理に関して、これがどのように機能するかについてかなり混乱しています。

基本認証を使用していますが、初めて要求を行うと、クライアントは挑戦を受けます (または、最初からヘッダーで認証情報を渡すことができます)。ただし、ユーザーが認証されると、セッションが存続している限り、サーバーはこのクライアントにチャレンジしなくなります。

これは、現在のユーザーがログアウトする (セッションを終了する) ためのメカニズムを提供する必要があることを意味します。

これを行う正しい方法は、構成を何らかの形で変更して、すべてのリクエストが認証のために挑戦されるように見えるでしょうが、これがセッション管理でどのように機能するかはわかりません.

  • リクエストごとにセッションを手動で無効にする必要がありますか?
  • または、リクエストが行われるたびにクライアントに挑戦するよう強制する方法はありますか?

REST を使用したセキュリティに関する多くの質問や、さまざまな認証モデルの実装方法に関する書籍を見つけることができます。しかし、セッション管理、ログイン、ログアウトの処理方法については、良い答えが見つかりませんでした。したがって、私は何か間違ったことをしている、またはここで重要なことを誤解しています。

これを適切に処理する方法についての考えやガイダンスをいただければ幸いです。

Tomcat 7 で Jersey 2.4 を使用しています。

4

2 に答える 2

1

HTTP Basic で認証している場合、Authorization ヘッダーがクライアントから送信されていないため、クライアントは初めてチャレンジされます。それが送信され、サーバーが 401 以外のものを送信すると、クライアントはそれらの資格情報をキャッシュし、すべての要求でそれらを再送信します。

ステートレス アプリでセッションを作成しないでください。セッションが使用されないだけでなく、管理にオーバーヘッドが必要になるためです (空のセッションであっても)。httpServletRequest.getSession()ただし、サーブレット アーキテクチャでは、コードがまたはを呼び出す場合などに、コードがセッションを作成するのを防ぐことはできませんhttpServletRequest.getSession(true)。したがって、これを行うコード (またはフレームワーク) を使用しないようにする必要があります。

興味深いことに、Tomcat はクライアントが使用する JSESSIONID Cookie を引き続き生成します。コンテナのほとんどの構成では、これをオフにすることはできません。ただし、セッションが作成されていない場合、Cookie は基本的に無視されます (リクエストごとに新しい JSESSIONID Cookie が生成されます)。

また、アプリはステートレスであるため、ログインやログアウトの概念はありません。すべての認証はリクエストごとに行われます。

特定のアプリによっては、プラグマティズムが純粋な RESTfulness に勝る可能性があることに注意してください。アプリにある種のセキュリティを提供する唯一の方法が、サーバー状態の "少し" である場合があります (クロスサイト リクエスト フォージェリ、ナンスのあるものなど)。

于 2013-11-07T17:51:54.083 に答える
0

RESTful Web サービスを実行している場合は、セッションを処理しないでください。初めて API に接続するときは、認証キーを取得するために認証チェックに合格する必要があります。このキーは、API がユーザーを識別する方法です。

セッションを無効にしたり、ユーザーに再認証を強制したりしないでください。

于 2013-11-07T16:36:12.410 に答える