| Summary: | DeltaManager Form Authentication Fails to Replicate Changes in Sessions | ||
|---|---|---|---|
| Product: | Tomcat 9 | Reporter: | Kenneth Gendron <kenneth.gendron> |
| Component: | Cluster | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 9.0.30 | ||
| Target Milestone: | ----- | ||
| Hardware: | PC | ||
| OS: | All | ||
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. 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. Fixed in: - master for 9.0.31 onwards - 8.5.x for 8.5.51 onwards - 7.0.x for 7.0.100 onwards |
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" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> <Channel className="org.apache.catalina.tribes.group.GroupChannel"> <Membership className="org.apache.catalina.tribes.membership.StaticMembershipService"> <Member className="org.apache.catalina.tribes.membership.StaticMember" port="4000" host="host1" uniqueId="{1,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/> <Member className="org.apache.catalina.tribes.membership.StaticMember" port="4000" host="host2" uniqueId="{2,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/> </Membership> <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" address="auto" port="4000" selectorTimeout="100" maxThreads="6"/> <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> </Sender> </Channel> <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/> </Cluster> 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.