LoginSignup
6
6

More than 5 years have passed since last update.

Spring-Session@1.2.1の簡単な検証

Last updated at Posted at 2016-07-09

前回のSpring-Sessionを使ってみたの投稿から1年以上経過したので、現状どのくらい変わったのか自分が使いたい範囲だけ検証してみた。

まずは前回記事のTODOの内容から。

前回記事のTODO

@EnableRedisHttpSession.maxInactiveIntervalInSeconds()の値がCookieのExpireに反映されない

いや、これそもそも Inactiveな状態が何秒続いたらセッション破棄する という内容であってCookieの生存期間の話じゃなかった。

バージョン1.x.RELEASE系ではCookieにmaxAgeを設定しようとするとCookieHttpSessionStrategyを独自拡張して・・・
ってfinalだから拡張クラスも作れない。。

ということで諦めてCookieHttpSessionStrategyをコピペしてmaxAgeを設定する他なかった。

SessionAttributeで保存したデータ構造が変わった時の対応方法

これはどちらかというとJavaのシリアライズ/デシリアライズの話。

RedisにそのままJdkSerializationRedisSerializerを使用してシリアライズ/デシリアライズすると型の構造が変わった時にデシリアライズエラーになる。
避け方は色々あると思うのでここでの言及は割愛する。


1.2.1.RELEASE

ここから1.2.1.RELEASEの話。

CookieのMaxAgeの設定

Issueを見てみるとCookieHttpSessionStrategyにCookieの設定内容どんどん増えていくのが見える。
そこでCookieのシリアライズ設定だけ切り出したようだ。

これでセッションIDに関するCookieの細かな設定が可能となった。

@Bean
public CookieSerializer cookieSerializer() {
  DefaultCookieSerializer serializer = new DefaultCookieSerializer();
  serializer.setCookieName("JSESSIONID");
  serializer.setCookieMaxAge(365 * 24 * 60 * 60); // 365 days.
  return serializer;
}

Sessionの張り替え

前回記事でも検証したので、今回も検証してみる。

できた!

request1
User user = (User) session.getAttribute("user");
user.getName(); // Taro
session.invalidate();
request.getSession(true).setSessionAttribute("user", user);

って同じリクエスト内で実行すると生成されたJSESSIONIDがCookieに設定されたので、次回以降のリクエストで

request2
((User)session.getAttribute("user")).getName(); // Taro

SessionAttributeの書き換え

これは前回の記事から動作は変わらなかった。

まとめ

あんまりガッツリ動作を確認したわけではないから中身が薄い記事になってしまったけど、自分用のメモとしては良いかなと。
1.01.1系のspring-session使ってる方は1.2系に上げてみても良いかもしれません。

6
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
6