舞台裏

Qiita が表でこっちが裏。こっそりやっていく。

6.3.3 Session Management

Java SpringFramework SpringSecurity 翻訳メモ

Detecting Timeouts

You can configure Spring Security to detect the submission of an invalid session ID and redirect the user to an appropriate URL.

あなたは、無効なセッションIDが渡されたことを検出し、適切な URL にリダイレクトするために Spring Security を設定することができます。

This is achieved through the session-management element:

これは、 session-management 要素を通じて実現できます。

<http>
...
<session-management invalid-session-url="/invalidSession.htm" />
</http>

Note that if you use this mechanism to detect session timeouts, it may falsely report an error if the user logs out and then logs back in without closing the browser.

もしあなたがセッションタイムアウトを検出するメカニズムを使っている場合は注意してください。 もしユーザがログアウトしたあとにブラウザを閉じる前に「戻る」などでアクセスしてきた場合に間違ってエラーの報告するかもしれません。

This is because the session cookie is not cleared when you invalidate the session and will be resubmitted even if the user has logged out.

これは、あなたがセッションを無効にしてログアウトした状態で再サブミットした場合にセッションクッキーがクリアされないのが原因です。

You may be able to explicitly delete the JSESSIONID cookie on logging out, for example by using the following syntax in the logout handler:

あなたは明示的に JSESSIONID クッキーをログアウトのときに削除することができます。
例えば、ログアウトハンドラーのなかで次のようなシンタックスを使います。

<http>
<logout delete-cookies="JSESSIONID" />
</http>

Unfortunately this can’t be guaranteed to work with every servlet container, so you will need to test it in your environment

残念ながら、これは全てのサーブレットで動作することは保証できません。
よって、あなたがあなたの環境でテストする必要があります。

If you are running your application behind a proxy, you may also be able to remove the session cookie by configuring the proxy server.

もしあなたがプロキシを経由してアプリケーションを走らせているなら、あなたはプロキシサーバーの設定でセッションクッキーを削除することができるかもしれません。

For example, using Apache HTTPD’s mod_headers, the following directive would delete the JSESSIONID cookie by expiring it in the response to a logout request (assuming the application is deployed under the path /tutorial):

たとえば、 Apache HTTPD の mod_headers を使っているなら、次のようなディレクティブで JSESSIONID クッキーをログアウトリクエストのレスポンスで無効にできます（アプリケーションが /tutorial パスの下にデプロイされていると想定してください）。

<LocationMatch "/tutorial/logout">
Header always set Set-Cookie "JSESSIONID=;Path=/tutorial;Expires=Thu, 01 Jan 1970 00:00:00 GMT"
</LocationMatch>

Concurrent Session Control

If you wish to place constraints on a single user’s ability to log in to your application, Spring Security supports this out of the box with the following simple additions.

もしあなたが単一のユーザがログインできるよう制約を設けたいのであれば、 Spring Security は次のシンプルな追記によってこれをサポートします。

First you need to add the following listener to your web.xml file to keep Spring Security updated about session lifecycle events:

最初に、あなたは Spring Security がセッションライフサイクルイベントを維持するために次のリスナーを web.xml に追加する必要があります。

<listener>
<listener-class>
    org.springframework.security.web.session.HttpSessionEventPublisher
</listener-class>
</listener>

Then add the following lines to your application context:

次の行をアプリケーションコンテキストに追加してください。

<http>
...
<session-management>
    <concurrency-control max-sessions="1" />
</session-management>
</http>

This will prevent a user from logging in multiple times - a second login will cause the first to be invalidated.

これは、ユーザが複数回ログインすることを防ぎます。
２回目のログインで、１回目のログインが無効になります。

Often you would prefer to prevent a second login, in which case you can use

しばしば、あなたは２回目のログインを防ぎたいと思うかもしれません。
その場合、次のようにすればできます。

<http>
...
<session-management>
    <concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />
</session-management>
</http>

The second login will then be rejected.

２回目のログインは拒否されます。

By “rejected”, we mean that the user will be sent to the authentication-failure-url if form-based login is being used.

拒否されるとは、 Form ログインを使っている場合は authentication-failure-url で指定した URL にユーザを送ります。

If the second authentication takes place through another non-interactive mechanism, such as “remember-me”, an “unauthorized” (401) error will be sent to the client.

もし２回目の認証が他の非対話的なメカニズムを通じてやってきた場合（例えば Remember-Me など）は、 “unauthorized” 401 エラーがクライアントに送信されます。

If instead you want to use an error page, you can add the attribute session-authentication-error-url to the session-management element.

もしエラーページを指定したい場合は、 session-authentication-error-url 属性を session-management 要素に追加することでできます。

If you are using a customized authentication filter for form-based login, then you have to configure concurrent session control support explicitly.

もしあなたが Form ログインにカスタマイズした認証フィルターを使っている場合、同時セッションサポートを明示的に設定する必要があります。

More details can be found in the Session Management chapter.

さらなる詳細については、 Session Management の章 で見つけることができます。

Session Fixation Attack Protection

Session fixation attacks are a potential risk where it is possible for a malicious attacker to create a session by accessing a site, then persuade another user to log in with the same session (by sending them a link containing the session identifier as a parameter, for example).

セッション固定化攻撃は、悪意ある攻撃者がサイトにアクセスして作ったセッションで、他のユーザがログインできる可能性があるというリスクです（例えば、リンクに含まれたセッションを識別するパラメータで他のユーザに送信します）。

Spring Security protects against this automatically by creating a new session or otherwise changing the session ID when a user logs in.

Spring Security は、ユーザがログインしたときに新しいセッションを作るかセッションIDを変更することで、これを自動的に防ぎます。

If you don’t require this protection, or it conflicts with some other requirement, you can control the behavior using the session-fixation-protection attribute on <session-management>, which has four options

もしあなたがこの防御を必要としないか、もしくは他の要求と衝突する場合は、 <session-management> 要素の session-fixation-protection 属性の４つのオプションで、振る舞いを制御することができます。

  • none - Don’t do anything. The original session will be retained.

none は、何もしません。オリジナルのセッションが保持されます。

  • newSession - Create a new “clean” session, without copying the existing session data (Spring Security-related attributes will still be copied).

newSession - 既存のセッションデータをコピーせずに、新しいきれいなセッションを作成します（Spring Security に関係する属性はコピーされます）。

  • migrateSession - Create a new session and copy all existing session attributes to the new session. This is the default in Servlet 3.0 or older containers.

migrateSession - 既存のセッションが持つ属性を全てコピーして新しいセッションを作成します。これは Servlet 3.0 以前のコンテナではデフォルトです。

  • changeSessionId - Do not create a new session. Instead, use the session fixation protection provided by the Servlet container (HttpServletRequest#changeSessionId()). This option is only available in Servlet 3.1 (Java EE 7) and newer containers. Specifying it in older containers will result in an exception. This is the default in Servlet 3.1 and newer containers.

changeSessionId - 新しいセッションを作成しません。
代わりに、サーブレットコンテナが提供するセッション固定化攻撃対策（HttpServletRequest#changeSessionId()）を使用します。
このオプションは、 Servlet 3.1 (Java EE 7) かそれ以上のコンテナで有効です。
それ以前のコンテナで指定した場合は、例外が発生します。
これは Servlet 3.1 以上のコンテナではデフォルトです。

When session fixation protection occurs, it results in a SessionFixationProtectionEvent being published in the application context.

セッション固定の防御が実行されると、 SessionFixationProtectionEvent がアプリケーションコンテキストに通知されます。

If you use changeSessionId, this protection will also result in any javax.servlet.http.HttpSessionIdListener s being notified, so use caution if your code listens for both events.

もしあなたが changeSessionId を使用しているのであれば、この防御は javax.servlet.http.HttpSessionIdListener にも通知されます。
よって、あなたのリスナーは両方のイベントを受け取ることに注意してください。

See the Session Management chapter for additional information.

追加の情報は Session Management の章 を見てください。