昔は spring.session.store-type の選択肢に hash_map というものがあったようですが、現在は存在しません。(ちなみに none は Spring Session を利用しない、という意味になるようで、挙動が変わってしまいます( JSESSIONID と SESSIONID とか))

Http403ForbiddenEntryPoint がデフォルトで設定されているため、 ExceptionTranslationFilter において AuthenticationException のサブクラスは全て 403 になっている模様。

認証通った上でunauthorizedってことはforbiddenなんだよな？ということでしょうか。…この言い方だと全然ニュアンス伝わらないか。

Spring Framework 5.3.3 で対応された

の影響で、 HttpServletRequest#getDispatcherType() メソッドが呼ばれるようになっています。

これにより、 HttpServletRequest をモック化して実行していたテストケースが(想定外のメソッド呼び出しで null を返すため)失敗するようになっていました。

さて2021年にもなったし、そろそろUbuntuアップグレードしても解消できない地雷は無くなっているだろう、と思い18.04からアップグレードを敢行しました。

調査したところSpring Bootの問題と言うよりは、Lombokのバージョンが 1.18.12 から 1.18.16 に上がったことによる非互換性の問題でした。

Lombokのchangelogに説明があります:

Spring Security OAuth 2.0 Login を利用してログインしたのですが、通常ログイン後 UserInfo Endpoint へアクセスしてくれるはずなのにこの処理がスキップされてしまうような事象に出会いました。

Spring Boot開発中、再起動するとsessionは消失すると思いこんでいたのですが、どうも引き継がれているように見えて混乱しました。

その後、調査してみると server.servlet.session.persistent プロパティで再起動時セッションを破棄するか保持するかを設定できることがわかりました。ただし、デフォルト値は false で、もちろんデフォルトからは変更していません(存在を知らなかったので)。

でそれぞれ、 CentOS6 + Rails6, CentOS7 + Rails6 の Vagrant Box を作成しました。ググってみたけれど、あまり無いものなんですね。

ビルド作業は次のページを参考にしました:

環境は こちら に記載したものです。

つづいて ldoconfig での登録ですが、そのまま行うとエラーが出たので こちら を参照にして事前に1つのファイルをリネームしておきました:

gccをビルドしようと思ったのですが、結構時間がかかるイメージがあって、先にどれくらいかかるのか調べたかったのだけれど検索しても見つかりませんでした。