私の Web アプリでは、Tomcat 宣言型セキュリティを使用して、ログイン資格情報を会社の Active Directory に関連付けています。2 つのサーバーでは、1 分間操作がないとログインがタイムアウトになりました。他の 2 つのサーバーでは、30 分間のタイムアウトがあります (これが必要です)。
昨日、私は問題の原因を見つけました。タイムアウトが 1 分の 2 つのサーバーでは、Tomcat Persistence Manager が有効になっており、セッション情報をディスクに書き込むことができます。私たちの IT 担当者は今週不在なので、彼がこれで何を達成しようとしていたのか正確な詳細はわかりませんが、彼は context.xml で次のように PersistenceManager を設定していました。
<Manager sessionIdLength="64" className="org.apache.catalina.session.PersistentManager"
maxIdleBackup="10" maxIdleSwap="30">
<Store className="org.apache.catalina.session.JDBCStore" dataSourceName="jdbc/Auth"
sessionTable="sessions" sessionAppCol="app_name" sessionDataCol="session_data" sessionIdCol="session_id"
sessionLastAccessedCol="last_access" sessionMaxInactiveCol="max_inactive" sessionValidCol="valid_session" />
</Manager>
いくつかの調査を行ったところ、アイドル数が秒単位であることがわかりました。それが原因かもしれないと考えて、マネージャーの部分を次のように変更しました。
<Manager sessionIdLength="16" className="org.apache.catalina.session.PersistentManager"
maxIdleBackup="600" maxIdleSwap="3600" minIdleSwap="1800">
これで問題が解決しました。そのため、30 秒間非アクティブになった後に Persistence Manager に強制的にセッションをディスクに書き出させると、セッション ログインが強制終了されたようです。JSESSIONID Cookie を追跡したところ、ユーザーが強制的にログイン画面に戻った後も Cookie が同じままであることがわかりました。再ログインするだけで変わります。セッションをディスクに永続化してもセッション ID を変更できない可能性があるため、これは当然のことです。ただし、宣言型セキュリティ モデルでは、ユーザーが再度ログインする必要があります。
maxIdleSwap 変数は、ディスクへのセッションの永続化を制御するだけでなく、「サーバー メモリからのセッションのパッシベーション」も引き起こすことがマニュアルでわかりました。これは私には少し疑わしいように聞こえます。
誰もこの問題の経験がありますか? Persistence Manager がセッションをディスクに永続化するときに Web アプリのログインを強制終了するのはなぜですか? 私のようにスワップ制御変数を変更せずにこれを回避する方法はありますか?