Bug 64043 - DeltaManager Form Authentication Fails to Replicate Changes in Sessions
Summary: DeltaManager Form Authentication Fails to Replicate Changes in Sessions
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Cluster (show other bugs)
Version: 9.0.30
Hardware: PC All
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2019-12-31 07:36 UTC by Kenneth Gendron
Modified: 2020-01-12 15:11 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Gendron 2019-12-31 07:36:22 UTC
Perhaps I am doing something wrong.  When using FORM authentication with a DeltaManager cluster, the sessions do not get replicated properly.  The manager will send the initial "session-created" message to the cluster members when a browser first connects; however, when authenticated, the new session ID (which is generated during the authentication process) is not replicated with a new "session-created" message.  Instead, the manager skips over sending a new "session-created" message, and proceeds directly to "session-delta" messages using the new session ID.  The only problem is the manager cannot find a matching session, and drops the offending messages.

The following is the basic cluster configuration I am using.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
	<Manager className="org.apache.catalina.ha.session.DeltaManager"
	<Channel className="org.apache.catalina.tribes.group.GroupChannel">
		<Membership className="org.apache.catalina.tribes.membership.StaticMembershipService">
			<Member className="org.apache.catalina.tribes.membership.StaticMember"
			<Member className="org.apache.catalina.tribes.membership.StaticMember"
		<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
		<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
			<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
	<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>

To address this, I created my own DeltaManager implementation that overrides handleSESSION_DELTA(), calling handleSESSION_CREATED() in the event the session cannot be found before calling super.handleSESSION_DELTA().  This seems to work.
Comment 1 Christopher Schultz 2019-12-31 16:06:49 UTC
Can you confirm you are using 9.0.30? A "minor" change was made to the post-login-session-id-changing code recently and it's possible a bug was introduced.

Would it be possible for you to re-try with 9.0.29 or 9.0.29?

Please leave this issue open (in case there really is a bug) but post everything to the users' mailing list instead of Bugzilla, which is not intended to be a support forum.

When posting, please also post your reverse-proxy configuration.
Comment 2 Kenneth Gendron 2020-01-01 11:20:04 UTC
I tried with 9.0.29 also, all the way back to 9.0.17.  None worked.

For my testing I was not using a reverse proxy, but simply using a secondary IP between two machines, and having the browser connect to that IP, seeing if the session would hold as I moved the IP.

I did notice that if I move the cluster configuration into the Host, and add ClusterSingleSignOn, it seems to work properly.

And I do apologize for going here and not through the mailing list.
Comment 3 Keiichi Fujino 2020-01-12 15:11:38 UTC
Fixed in:
- master for 9.0.31 onwards
- 8.5.x for 8.5.51 onwards
- 7.0.x for 7.0.100 onwards