You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2019/12/31 07:36:22 UTC

[Bug 64043] New: DeltaManager Form Authentication Fails to Replicate Changes in Sessions

https://bz.apache.org/bugzilla/show_bug.cgi?id=64043

            Bug ID: 64043
           Summary: DeltaManager Form Authentication Fails to Replicate
                    Changes in Sessions
           Product: Tomcat 9
           Version: 9.0.30
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Cluster
          Assignee: dev@tomcat.apache.org
          Reporter: kenneth.gendron@gmail.com
  Target Milestone: -----

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 64043] DeltaManager Form Authentication Fails to Replicate Changes in Sessions

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64043

Christopher Schultz <ch...@christopherschultz.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All
             Status|NEW                         |NEEDINFO

--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 64043] DeltaManager Form Authentication Fails to Replicate Changes in Sessions

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64043

Keiichi Fujino <kf...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEEDINFO                    |RESOLVED

--- Comment #3 from Keiichi Fujino <kf...@apache.org> ---
Fixed in:
- master for 9.0.31 onwards
- 8.5.x for 8.5.51 onwards
- 7.0.x for 7.0.100 onwards

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 64043] DeltaManager Form Authentication Fails to Replicate Changes in Sessions

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64043

--- Comment #2 from Kenneth Gendron <ke...@gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org