Re: [EXT]Re: Tomcat 10 session replication fails

[Jonathan S. Fisher]

Sort of off topic, but sort of related. If you're having tremendous
trouble using the built in replication methods, we built a redis based
session manager: https://github.com/exabrial/redex-sm

Currently redex-sm only works with Tomcat 8.5, but it wouldn't be a
big leap to make it work with Tomcat 10. The advantage of using Redis
to store your sessions is it's a well trodden path to set up a
replicated Redis cluster, you have a lot of tooling around exploring
sessions stored inside there, and you can store hundreds-of-thousands
of sessions, or even set them to absurd timeouts (weeks).

I hate to see people struggle with session replication, as I think it
really is the secret to making server-side-rendering scale out.


On Sat, Apr 13, 2024 at 3:01 PM Chuck Caldarale  wrote:
>
>
> > On Apr 11, 2024, at 09:07, Rick Noel  wrote:
> >
> > We are getting closer
> > Changing ports from the 5000 range to the 4000 range stopped two errors
> > But now I get this..
> >
> > INFO: Manager [##0001]: skipping state transfer. No members active in 
> > cluster group
> >
> > How to I make the member machine in the cluster active?
>
>
> There’s a cluster configuration option that may be coming into play here: 
> localLoopbackDisabled. Once upon a time, the JDK method:
> MulticastSocket.setLoopbackMode(boolean disable)
> did the opposite of what one might think from just the method name - passing 
> in true disabled local receipt of multicast packets. That method has since 
> been deprecated, and Tomcat currently uses this method:
>  DatagramSocket.setOption(SocketOption name, T value)
> which, at least in Java 21, operates as you might expect from the name - 
> specifying true enables multicast loopback.
>
> However, there’s some interesting logic in Tomcat's handling of 
> localLoopbackDisabled that can inverts the config value based on the Java 
> level, along with this comment:
> Java < 14, a value of true means loopback is disabled. Java 14+ a 
> value of true means loopback is enabled.
>
> Having not dug into the JRE source code for the various Java versions, I’m 
> not yet convinced the version checking logic is correct. You might try 
> setting localLoopbackDisabled to true in your  config to see 
> if that has an effect on your dev system.
>
> Also, let us know what Java version you’re using.
>
>   - Chuck
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as
half full.
Engineers, of course, understand the glass is twice as big as it needs to be.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [External] Re: Supporting Proxy Protocol in Tomcat

[Jonathan S. Fisher]

Hello Adwait,
I originally was going to sponsor this to get it done before year end.
Unfortunately my timeline got pushed to 2024 as we found a more
impactful area to make performance improvements. It's still a very
valuable and important Tomcat feature. The original PR is a good
starting place, and needs Mark's feedback implemented along with the
discussion notes I sent a few months back. After that, some tests
written to check for edge cases, especially around protocol parsing.

On Tue, Nov 21, 2023 at 3:56 PM Adwait Kumar Singh  wrote:
>
> Hey,
>
> Checking in on this thread. Is someone actively working on this?
>
> I am more than happy to contribute/help in any way to move this forward
> quickly.
>
>
> Thanks,
> Adwait.
>
> On Tue, Sep 5, 2023 at 1:11 PM Mark Thomas  wrote:
>
> > On 04/09/2023 15:41, Jonathan S. Fisher wrote:
> > > Mark thank you again for your leadership and setting expectations. I'm
> > > going to commit to working on this with anyone else that wants to help
> > with
> > > the goal of a patch by year end. I want to nail the patch with minimal
> > > rework that meets Tomcat project quality standards. To that end, I'll
> > > attempt to summarize what you expect here and if you could comment and
> > > correct my understanding that would be appreciated.
> > >
> > > It sounds like you're satisfied with the ubiquity of the Proxy protocol
> > and
> > > that it has an RFC
> > > We'll target just implementing the latest version of the Proxy protocol
> > > We'll implement a "TrustedProxies" feature similar to what the Remote IP
> > > Valve does
> > > We'll implement a, or modify the RemoteIp, valve to be able to set the
> > > remote IP from Proxy protocol headers
> > > We'll follow the RFC spec and reject any request that does a proper Proxy
> > > protocol header
> > > I'm particularly interested in the Proxy protocol over Unix Domain
> > Sockets,
> > > so expect to see a lot of the work focused on this, but accepting Proxy
> > > Protocol over TCP looks to be quite important from the comments on this
> > > email chain
> > >
> > > If I may ask two things:
> > > Can you summarize your desired implementation? What point in the stack
> > > should we target to implement this?
> >
> > See my response earlier in this thread that suggested it sits alongside
> > SNI processing. I still think that makes sense. If during implementation
> > you reach a different conclusion then make the case for the alternative
> > approach on list.
> >
> > > One thing I'm not familiar with on Tomcat is the testing expectations. If
> > > you can point to a set of unit tests and a set of integration tests and
> > say
> > > "Do it like this"
> >
> > Something like (only a guide)
> >
> >
> > https://github.com/apache/tomcat/blob/main/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java
> >
> > to test the implementation directly and probably something based on
> > SimpleHttpClient see
> >
> >
> > https://github.com/apache/tomcat/blob/main/test/org/apache/coyote/http11/TestHttp11Processor.java
> >
> > for various examples. The main thing is I suspect you'll need control of
> > the individual bytes and SimpleHttpClient provides a reasonably simple
> > basis for that.
> >
> > What we often do when we want to test things like setting remote IP
> > addresses etc. is echo the value in the response body and then check
> > that value in the client.
> >
> > > Anything else on the original patch you liked/didn't like? (
> > > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)
> >
> > It helps if you enable Checkstyle for your local build. It helps keep
> > things in roughly the same coding style (we are slowly tightening up on
> > that). Ideally, use the clean-up and formatting configurations we have
> > for Eclipse in res/ide-support/eclipse .
> >
> > This is sufficiently complex that I am expecting several iterations to
> > be required. if it is simpler for you to manage with a PR then that is
> > fine and probably easier to work with than a patch in Bugzilla.
> >
> > Mark
> >
> > >
> > > Thank you,
> > >
> > >
> > > On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas  wrote:
> > >
> > >> On 28/08/2023 18:44, Amit Pande wrote:
> > >>> Oh, sure. So, what would be the best way to get some conclusion on this
> > >> thread?
> > >>
> > &

Re: [External] Re: Supporting Proxy Protocol in Tomcat

[Jonathan S. Fisher]

Mark thank you again for your leadership and setting expectations. I'm
going to commit to working on this with anyone else that wants to help with
the goal of a patch by year end. I want to nail the patch with minimal
rework that meets Tomcat project quality standards. To that end, I'll
attempt to summarize what you expect here and if you could comment and
correct my understanding that would be appreciated.

It sounds like you're satisfied with the ubiquity of the Proxy protocol and
that it has an RFC
We'll target just implementing the latest version of the Proxy protocol
We'll implement a "TrustedProxies" feature similar to what the Remote IP
Valve does
We'll implement a, or modify the RemoteIp, valve to be able to set the
remote IP from Proxy protocol headers
We'll follow the RFC spec and reject any request that does a proper Proxy
protocol header
I'm particularly interested in the Proxy protocol over Unix Domain Sockets,
so expect to see a lot of the work focused on this, but accepting Proxy
Protocol over TCP looks to be quite important from the comments on this
email chain

If I may ask two things:
Can you summarize your desired implementation? What point in the stack
should we target to implement this?
One thing I'm not familiar with on Tomcat is the testing expectations. If
you can point to a set of unit tests and a set of integration tests and say
"Do it like this"
Anything else on the original patch you liked/didn't like? (
https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)

Thank you,


On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas  wrote:

> On 28/08/2023 18:44, Amit Pande wrote:
> > Oh, sure. So, what would be the best way to get some conclusion on this
> thread?
>
> Provide a patch for review based on the feedback provided here and in
> the BZ issue.
>
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the
> ticket isn't updated for long. Perhaps add comments/ask the folks on user
> list to vote?
>
> That is more likely to irritate folks rather than encourage them to help
> you progress your patch.
>
> Mark
>
>
> >
> > Thanks,
> > Amit
> >
> > -Original Message-
> > From: Mark Thomas 
> > Sent: Monday, August 28, 2023 11:20 AM
> > To: Tomcat Users List 
> > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> >
> > CAUTION: This email originated from outside the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe. If you believe this is a phishing email, use the
> Report to Cybersecurity icon in Outlook.
> >
> >
> >
> > 28 Aug 2023 17:11:20 Amit Pande :
> >
> >> Mark,
> >>
> >> Just checking - Did this issue get discussed in any of the core
> >> members' meeting?
> >
> > There are no such meetings. Discussion happens on the mailing lists.
> >
> > Mark
> >
> >
> >>
> >> Thanks,
> >> Amit
> >>
> >> -Original Message-
> >> From: Amit Pande
> >> Sent: Monday, July 31, 2023 9:29 AM
> >> To: Tomcat Users List 
> >> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>
> >> Yes, understood.
> >>
> >> Thank you for clarifying. Even I was referring to initial consensus
> >> without any timeline or approach conclusion.
> >>
> >> Thanks,
> >> Amit
> >>
> >> -Original Message-
> >> From: Mark Thomas 
> >> Sent: Friday, July 28, 2023 2:48 PM
> >> To: users@tomcat.apache.org
> >> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>
> >> On 28/07/2023 19:21, Amit Pande wrote:
> >>> Thank you all for the valuable discussion on this topic.
> >>>
> >>> Is it okay to say that we're agreeing to adding proxy protocol
> >>> support in Tomcat?
> >>
> >> I think that is a little too strong. At this point there is a proposed
> >> approach and no one is objecting but until there is an actual patch to
> >> discuss...
> >>
> >> Keep in mind that any committer can veto a change.
> >>
> >> My sense is that it should be possible to implement this feature while
> >> addressing any concerns that may be raised but it is not guaranteed.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -Original Message-
> >>> From: Christopher Schultz 
> >>> Sent: Thursday, July 27, 2023 4:13 PM
> >>> To: users@tomcat.apach

Re: [External] Re: Supporting Proxy Protocol in Tomcat

[Jonathan S. Fisher]

t can be done
> > separately and globally.
>
> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc) whereas I
> am thinking in terms of implementation (NIO, NIO2, etc).
>
> SNI is handled independently of implementation and I think PROXY should
> be handled the same way. They also sit at almost the same point in the
> processing (PROXY needs to be first). PROXY parsing could be implemented
> within the existing handshake() method but I think it would be much
> cleaner in a separate method.
>
> Without looking at it too closely I think the implementation would look
> something like:
>
> - a new method on SocketWrapperBase that
>- checks if PROXY is enabled
>- returns immediately if PROXY is not enabled or has already
>  been parsed
>- uses a new utility class (or classes) to parse the header
>  (reading via the read() methods on SocketWrapperBase)
>- sets the cached values for remoteAddr, remoteHost,
>  remotePort etc
> - The SocketProcessor.doRun() implementations add a call to this new
>method just before the TLS handshake
>
> If we want to support the TLS information then a little additional
> refactoring will be required (probably to cache the result of
> SocketWrapperBase.getSslSupport) so the new utility classes can insert a
> PROXY specific SSLSupport implementation.
>
> > Again, I'm speaking from a position of profound ignorance, here. Please
> > don't hear me say "oh, this is easy, Mark... just go do it!" :)
>
> :)
>
> Actually with the patch that has already been provided and the suggested
> implementation outline above I don't think there is too much work to do.
>
> >> Generally, I don't think implementing this is going to be possible as
> >> some sort of plug-in.
> >
> > +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
> > handlers" which is a rather serious commitment.
>
> On reflection, with the approach above we probably could implement this
> via a new plug-in framework but I am not sure it is worth the effort at
> this point. Something to keep in mind if we have more things wanting to
> integrate at this point in the processing chain.
>
> Mark
>
> >
> > -chris
> >
> > [1] https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for
> > "haproxy"
> >
> >> On 26/07/2023 17:44, Amit Pande wrote:
> >>> Missed to ask this:
> >>>
> >>> Looking the patch, it involves modifying Tomcat code.
> >>> Was wondering if it would be possible to refactor this patch and/or
> >>> allow Tomcat core code to extend and plug-in the proxy protocol
> support?
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -Original Message-
> >>> From: Amit Pande
> >>> Sent: Wednesday, July 26, 2023 11:43 AM
> >>> To: Tomcat Users List 
> >>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>> Chris, Mark,
> >>>
> >>> Any thoughts on this?
> >>>
> >>> Mark, if we clean up the patch and re-submit, do you will have any
> >>> concerns (specially security wise)?
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -Original Message-
> >>> From: Jonathan S. Fisher 
> >>> Sent: Monday, July 24, 2023 12:41 PM
> >>> To: Tomcat Users List 
> >>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>> Just a side note, because we're also very interested in this patch!
> >>>
> >>> Awhile back, I was successfully able to apply this patch and
> >>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix
> >>> domain socket and the Proxy protocol provided *most *of the
> >>> relevant/required information to tomcat. I believe we had to add a
> >>> Valve to tomcat to set the Remote IP however as the patch didn't
> >>> handle that case.
> >>>
> >>> I can find my notes from that experiment, but I do remember getting a
> >>> significant boost in throughput and decrease in latency.
> >>>
> >>> +1 for this patch and willing to help out!
> >>>
> >>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
> >>> 
> >>> wrote:
> >>>
> >>>> Thank you, Chris, again for inputs.
> >>>> And sorry to circle back on this, late.
> >>>>
> >>>> One rela

Re: [External] Re: Supporting Proxy Protocol in Tomcat

[Jonathan S. Fisher]

Mark, thankyou for your feedback. I hope to settle some worry here:
> I prefer supporting features backed by specifications rather than vendor
specific hacks.

I totally understand and agree. This is a standardized specification with a
control document.
Spec: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

The Proxy protocol is actually widely deployed and available today; I'll
provide as many references as I know of:

HaProxy Support: (See spec doc above)
Apache Support:
https://roadrunner2.github.io/mod-proxy-protocol/mod_proxy_protocol.html
Nginx Support:
https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol
Amazon Web Services Support:
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#proxy-protocol
Google Cloud Support:
https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#proxy-protocol
Cloudflare Support:
https://developers.cloudflare.com/spectrum/how-to/enable-proxy-protocol/
DigitalOcean Support:
https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage/#proxy-protocol
Linode Support:
https://www.linode.com/docs/products/networking/nodebalancers/guides/proxy-protocol

These are just the usages that I'm aware of. Having support in Tomcat for
Proxy Protocol means these load balancers above can speak to Tomcat in a
more direct manner. A Google search returns even wider support from
everything on databases to some people supporting this through F5 load
balancers scripts.

Thank you again for your consideration,


On Wed, Jul 26, 2023 at 12:58 PM Mark Thomas  wrote:

> I'm not a huge fan of this feature in general. I prefer supporting
> features backed by specifications rather than vendor specific hacks.
>
> My support for any patch is going to depend on the specifics of the patch.
>
> In addition to the comments in the BZ
> - exposing the data as a request attribute is inconsistent with other
>mechanisms that solve the same problem (e.g. see RemoteIpFilter)
>
> - needs to be implemented for all Connectors
>
> - I'd expect it to look more like the SNI processing
>
> Generally, I don't think implementing this is going to be possible as
> some sort of plug-in.
>
> Mark
>
>
> On 26/07/2023 17:44, Amit Pande wrote:
> > Missed to ask this:
> >
> > Looking the patch, it involves modifying Tomcat code.
> > Was wondering if it would be possible to refactor this patch and/or
> allow Tomcat core code to extend and plug-in the proxy protocol support?
> >
> > Thanks,
> > Amit
> >
> > -Original Message-
> > From: Amit Pande
> > Sent: Wednesday, July 26, 2023 11:43 AM
> > To: Tomcat Users List 
> > Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Chris, Mark,
> >
> > Any thoughts on this?
> >
> > Mark, if we clean up the patch and re-submit, do you will have any
> concerns (specially security wise)?
> >
> > Thanks,
> > Amit
> >
> > -Original Message-
> > From: Jonathan S. Fisher 
> > Sent: Monday, July 24, 2023 12:41 PM
> > To: Tomcat Users List 
> > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Just a side note, because we're also very interested in this patch!
> >
> > Awhile back, I was successfully able to apply this patch and terminate
> TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket
> and the Proxy protocol provided *most *of the relevant/required information
> to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP
> however as the patch didn't handle that case.
> >
> > I can find my notes from that experiment, but I do remember getting a
> significant boost in throughput and decrease in latency.
> >
> > +1 for this patch and willing to help out!
> >
> > On Mon, Jul 24, 2023 at 11:22 AM Amit Pande  .invalid>
> > wrote:
> >
> >> Thank you, Chris, again for inputs.
> >> And sorry to circle back on this, late.
> >>
> >> One related question is - does it make sense to use the patch attached
> >> in
> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
> >> And potentially, get it integrated into Tomcat versions?
> >>
> >> There are concerns from Mark about using the patch in its current
> >> state, but I see last comment (#24) on the issue and looks like there
> >> are some more points to be concluded.
> >>
> >> Thanks,
> >> Amit
> >>
> >> -Original Message-
> >> From: Christopher Schultz 
> >> Sent: Wednesday, May 10, 2023 4:21 PM
> >> To: users@tomcat.apache.org
>

Re: Problem with session timeout

[Jonathan S. Fisher]

Find all implementations of Session, then set breakpoiunt on
session.invalidate() would be a good place to start. Another good place
would be your SessionManager as it has several interesting methods.

The JVM's JDI does not allow you to set breakpoint on an interface, but
some IDE's have a magic trick where they'll find the implementations for
you and set the breakpoints on the implementations as they're loaded.

On Tue, Jul 25, 2023 at 4:25 AM Wiemann, Helge (ESI)
 wrote:

> Hi all,
>
>
>
> we have a problem that we have set the tomcat timeout to 10 minutes. But
> after a successful login with a realm, the user is automatically logged
> out, sometimes after one minute, sometimes other times.
>
>
>
> I have downloaded the source code, want to set a breakpoint. Does anybody
> know a code place in tomcat where I can set a breakpoint when the session
> timeout is handled?
>
>
>
> Best regards,
>
>
>
> Helge
>
>
>
>
>
>
>
>   
>
> Helge Wiemann
> Application Developer
>
> Mary-Somerville-Str. 4, DE- 28359 Bremen
> T: +49 800 000 6898
>
> helge.wiem...@adp.com
>
>
>
> [image: LinkedIn] [image: Twitter]
> [image: Facebook]
> [image: YouTube]
> [image: Instagram]
> 
>
> ADP Employer Services
> GmbH; Sitz der Gesellschaft: Neu-Isenburg; Registergericht: Amtsgericht 
> Offenbach am
> Main HRB 11980;
> Geschäftsführer Martijn Brand (Vorsitzender), Virginia Magliulo;
> Aufsichtsratsvorsitzende: Marcela Uribe
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
>


-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.

Re: [External] Re: Supporting Proxy Protocol in Tomcat

[Jonathan S. Fisher]

Just a side note, because we're also very interested in this patch!

Awhile back, I was successfully able to apply this patch and terminate
TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket
and the Proxy protocol provided *most *of the relevant/required information
to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP
however as the patch didn't handle that case.

I can find my notes from that experiment, but I do remember getting a
significant boost in throughput and decrease in latency.

+1 for this patch and willing to help out!

On Mon, Jul 24, 2023 at 11:22 AM Amit Pande 
wrote:

> Thank you, Chris, again for inputs.
> And sorry to circle back on this, late.
>
> One related question is - does it make sense to use the patch attached in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
> And potentially, get it integrated into Tomcat versions?
>
> There are concerns from Mark about using the patch in its current state,
> but I see last comment (#24) on the issue and looks like there are some
> more points to be concluded.
>
> Thanks,
> Amit
>
> -Original Message-
> From: Christopher Schultz 
> Sent: Wednesday, May 10, 2023 4:21 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Amit,
>
> On 5/10/23 12:59, Amit Pande wrote:
> > Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
> >
> https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency
> which supports the proxy protocol.
> >
> > Since there is not much action on this
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830, does it imply that
> most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
> > Or does it mean that, Tomcat or applications running in Tomcat does not
> need the remote client address information?
>
> I can't speak for anybody else, but I use Apache httpd as my reverse-proxy
> and I do terminate TLS. I also use it for load-balancing/fail-over,
> caching, some authorization, etc. I wouldn't be able to use a TCP
> load-balancer because I hide multiple services behind my reverse-proxy
> which run in different places. It's not just s dumb pass-through.
>
> Hope that helps,
> -chris
>
> > -Original Message-
> > From: Christopher Schultz 
> > Sent: Monday, May 8, 2023 3:40 PM
> > To: users@tomcat.apache.org
> > Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Amit,
> >
> > On 5/4/23 16:07, Amit Pande wrote:
> >> We have a similar requirement as mentioned in the below enhancement
> request.
> >>
> >> https://bz/.
> >> a%2F=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b78720608
> >> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381935061356
> >> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3UFyiGJ9ZgtLqUzY9JM
> >> CK2MfwKN3OAOKdr6JmTUGkPw%3D=0
> >> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830=05%7C01%7CAmit.
> >> P
> >> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422c4
> >> c
> >> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb
> >> 3
> >> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> >> 7
> >> C3000%7C%7C%7C=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
> >> e
> >> served=0
> >>
> >> Is there any plan to add this support in Tomcat in future releases?
> >
> > Nothing at the moment that I know of.
> >
> > I thought that markt had looked at this a while back and said it didn't
> look too difficult. It does require Tomcat to handle the stream directly
> and not just rely on Java's SSLServerSocket. I thought that had been done
> at some point, but it may not have. Handling the stream directly may have
> some other advantages as well, though it definitely makes the code more
> complicated.
> >
> >> Also, since this was requested long time back and there is no update,
> >> are there any other alternatives to pass the client information from
> >> load balancer to Tomcat in situations where there is no SSL
> >> termination at load balancer?
> > You mean like a network load balancer where the lb is just proxying
> bytes and not looking at the data at all? The PROXY protocol really is the
> best way to do that, honestly.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> 

New Redis based SessionManager implementation: redex-sm

[Jonathan S. Fisher]

Hello Tomcat friends,

We recently published to Maven Central (com.github.exabrial:redex-sm:1.0.2)
a new Tomcat SessionManager that stores your serialized Sessions in Redis
instance. Details and usage are available here:
https://github.com/exabrial/redex-sm

The advantage of using a SessionManager like this is you may scale your
cluster very easily with sticky sessions and perform rolling upgrades
without user interruption. Redis is a great fit for a session storage use
case as it's basically a network-enabled Map. Many implementations of the
Redis protocol are available and creating  fault-tolerant scalable setup is
a well-trodden path.

redex-sm is very fast and tries to do the minimal amount of work on the
request thread. If a server dies, the user's session is retrieved from
Redis. If a session is updated, an event is broadcast to tell other servers
to evict their copy of the session in memory. If the session is
invalidated, an event is broadcast and all nodes invalidate the session.

We created this because the venerable memached-session-manager is very out
of date, and the Redisson session manager has a very large dependency list
that it does not shade and combines into a single jar, causing classpath
conflicts.

There are a few improvements to be made such as supporting multiple tomcat
revisions, writing tests, and pooling/broadcasting enhancements. We'd love
to see your pull requests or just if you find it useful.

Thank you,
-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.

Re: Enhancement: New option 'persistAuthentication' for session manager

[Jonathan S. Fisher]

https://github.com/cklein05/tomcat/pull/1/files

Remy:  Thank you for the feedback, but please see the other threads about
this. The feature is not there right now because not everyone can/wants to
use the Delta Session Manager. For instance, we do _not_ want a p2p
architecture as they create scalability problems with the one-to-many
problem. The session boils down to a key-value store, and there are some
very nice network enabled key-value stores in existence; cassandra, redis,
couchdb, memcached, et all. Tomcat's point-to-point replication options
aren't sufficient in many cases, which is why there ought to be an option
to allow this.

For older versions of tomcat, I'd suggest adding an additional option that
causes GenericPrincipal to drop the password after authentication is
complete, by default if persistAuthentication is enabled, which alleviates
your concern.



On Tue, Feb 18, 2020 at 10:13 AM Carsten Klein  wrote:

> > Open the pull request in your own fork... this link should work:
> >
> https://github.com/cklein05/tomcat/compare/cklein05:master...cklein05:session-manager-persist-authentication?expand=1
>
> Done.
>
> Carsten
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.

Re: Enhancement: New option 'persistAuthentication' for session manager

[Jonathan S. Fisher]

Open the pull request in your own fork... this link should work:
https://github.com/cklein05/tomcat/compare/cklein05:master...cklein05:session-manager-persist-authentication?expand=1

On Tue, Feb 18, 2020 at 6:42 AM Carsten Klein  wrote:

> Mark,
>
> > Please don't be put off by the number of comments and suggested changes.
> > I think the core idea is sound and meets a valid requirement that some
> > users have. To some extent, the volume of comments reflects that fact
> > I'm responding to a clear proposal and explanation. This is a good thing
> > in my eyes.
> >
> > In the order I thought of them:
> >
> > a) Please don't add author tags. ASF policy is not to add them. The ones
> > you see in the Tomcat codebase pre-date that policy. You will be
> > credited in the changelog. Which brings me on to...
>
> +1 OK
>
> >
> > b) Please add a changelog entry for this addition.
>
> Where is the changelog? Sorry, didn't find anything so far...
>
> >
> > c) Please add this new attribute to the documentation.
>
> +1 OK
>
> >
> >> 1. The new boolean option 'persistAuthentication' is implemented in
> >> ManagerBase and so can be configured for StandardManager or
> >> PersistentManager (defaults to false). Also added this to
> >> mbeans-descriptor.xml, so it's writable through JMX.
> >
> > +1
> >
> >> 2. That option is set for any new StandardSession upon creation (in
> >> method ManagerBase.createSession(String)). Once a session got this
> >> option, it's not being changed during the session's lifetime.
> >
> > d) Why do it this way as opposed to looking at the current setting in
> > the Manager when the session is persisted?
>
> That was my first idea, too. However, the StandardSession only knows a
> Manager (interface). I could have added the get/setPersistAuthentication
> methods to that interface (but didn't want to introduce such
> far-reaching changes) or need to test with instanceof for every session
> being written.
>
> Furthermore, some locking mechanism would be a good idea while sessions
> are stored, so that the option cannot be changed while a bunch of
> sessions is currently persisted (StandardManager synchronizes with
> sessions itself, however, PersistentManager does not). Actually a new
> lock monitor would be ideal.
>
> On the other side, one will likely not re-decide whether sessions shall
> be persisted or not from one day to another. I guess, that setting will
> remain quit constant for a certain installation, so my solution seemed
> not much worse.
>
> However, a simple instanceof ManageBase is also cheap and saves the
> setters and getters in StandardSession. Shall I refactor it acoordingly?
>
> >
> > e) I am very much against using system properties for configuration
> > except as a last resort. I don't see why PRINCIPAL_SERIALIZABLE_CHECK
> > can't be a property on the Manager. Although see g) below first.
>
> No longer needed, if a simple instanceof Serializable is enough. My idea
> was, that this option is true by default (a Principal is not a big class
> and the dry-run test should be fast enough). So, I did not see that this
> option was worth a config option (initially, that was just an internal
> constant).
>
> >
> >> 3. In StandardSession, method doWriteObject writes authentication
> >> information (authType and principal) only, if 'persistAuthentication' is
> >> true, the session is authenticated (authType or principal != null) and
> >> principal is serializable.
> >
> > f) Would the code be cleaner if these were always written and null
> > values used if authentication persistence is disabled?
>
> The idea was to be able to read the old-style object stream as well (a
> file created with the version without that enhancement). But, this can
> be achieved even without the Boolean tag. I will make that a bit more
> straight.
>
> >
> >> 4. The "is principal serializable" test is, by default, a deep
> >> (expensive?) check, which actually serializes the whole principal object
> >> to an ObjectOutputStream backed by a new NullInputStream, which just
> >> discards all bytes written. This check can be skipped by setting system
> >> property
> >> org.apache.catalina.session.StandardSession.PRINCIPAL_SERIALIZABLE_CHECK
> >> to false (defaults to true, however). If skipped, the principal is
> >> considered serializable if (principal instanceof Serializable). That's
> >> how the session's attribute values are checked for being serializable or
> >> not.
> >>
> >> However, that is odd, if such a serialized object has a child object
> >> which is not serializable. In that case, the ObjectOutputStream is left
> >> in an inconsistent state and no so called fatal exception code is
> >> written to the stream (that is, when reading such a stream, no
> >> WriteAbortedException is not thrown for such an error).
> >
> > g) The instanceof Serializable check should be sufficient. It a class
> > has that and then is not serializable that is a bug but not one I think
> > the Manager needs to protect itself 

Re: Enhancement: New option 'persistAuthentication' for session manager

[Jonathan S. Fisher]

Can you open a PR so we can diff your changes? Very excited to see this! We
used a workaround in a Valve to add the authentication information into the
session.

On Mon, Feb 17, 2020 at 11:31 AM Carsten Klein  wrote:

> Hi there,
>
> finally, I got my first Tomcat enhancement ready. You can view its code
> at my Tomcat fork on GitHub:
>
>
> https://github.com/cklein05/tomcat/tree/session-manager-persist-authentication
>
> Before I'm opening an enhancement in Tomcat's Bugzilla, maybe, Mark and
> Christopher (or whoever else is interested), could you please have a
> quick look at the code?
>
> BTW, recent versions of Tomcat do no longer save and store passwords in
> GenericPrincipal. That makes using this enhancement even less critical.
>
>
> Some brief description of what I've done:
>
> 1. The new boolean option 'persistAuthentication' is implemented in
> ManagerBase and so can be configured for StandardManager or
> PersistentManager (defaults to false). Also added this to
> mbeans-descriptor.xml, so it's writable through JMX.
>
> 2. That option is set for any new StandardSession upon creation (in
> method ManagerBase.createSession(String)). Once a session got this
> option, it's not being changed during the session's lifetime.
>
> 3. In StandardSession, method doWriteObject writes authentication
> information (authType and principal) only, if 'persistAuthentication' is
> true, the session is authenticated (authType or principal != null) and
> principal is serializable.
>
> 4. The "is principal serializable" test is, by default, a deep
> (expensive?) check, which actually serializes the whole principal object
> to an ObjectOutputStream backed by a new NullInputStream, which just
> discards all bytes written. This check can be skipped by setting system
> property
> org.apache.catalina.session.StandardSession.PRINCIPAL_SERIALIZABLE_CHECK
> to false (defaults to true, however). If skipped, the principal is
> considered serializable if (principal instanceof Serializable). That's
> how the session's attribute values are checked for being serializable or
> not.
>
> However, that is odd, if such a serialized object has a child object
> which is not serializable. In that case, the ObjectOutputStream is left
> in an inconsistent state and no so called fatal exception code is
> written to the stream (that is, when reading such a stream, no
> WriteAbortedException is not thrown for such an error).
>
> 5. A Boolean object is used as a tag/marker that determines, whether
> authentication information is present id the stream or not. If none of
> the above conditions are met, both authType and principal are not
> serialized (than, only the initial Boolean false marker has been emitted
> to the stream).
>
> BTW, the Boolean false marker is not even required (if there is no
> authentication information in the stream) since the reading code works
> fine without any Boolean in the stream. So emitting Boolean false for
> signalling "no auth info" is actually optional (we could consider
> omitting it).
>
> 6. When sessions are loaded, ManagerBase provides a
> org.apache.catalina.util.CustomObjectInputStream instance to read
> sessions from. That instance is configured with the session's
> sessionAttributeValueClassNamePattern property. This essentially defines
> the classes, session attribute values may consist of. This pattern
> defaults to "java\\.lang\\.(?:Boolean|Integer|Long|Number|String)", so
> only attributes with these simple types can be loaded from a session.
>
> That filter pattern is only in effect, if a security manager is active,
> or if a pattern has been configured for the manager (e.g. in context.xml).
>
> Currently, however, all session data (including its base properties like
> creationTime, isNew, isValid etc) is loaded with that filter mechanism
> in place. Since those so called 'scalar instance properties' actually
> only consist of those simple types, that was not a problem.
>
> However, loading the serialized principal from the object stream is now
> subject to that filter mechanism (BTW, HA's DeltaManager and
> DeltaSession just do not utilize the CustomObjectInputStream).
>
> Since, as the name implies, the sessionAttributeValueClassNamePattern
> applies to attribute values only, I decided to give the
> CustomObjectInputStream a boolean 'filterActive' property, which is set
> to true, just before StandardSession starts deserializing attributes.
> The initial value of 'filterActive' can be specified though the
> constructor, to which both StandardManager and StoreBase pass false
> (actually, only StandardManager and PersistenManager (through StoreBase)
> do use the CustomObjectInputStream class).
>
> 7. Conclusion
>
> - Tomcat still builds with that enhancement in place
> - The enhancement obviously works as expected
> - Minor decisions can still be made (e.g. pull NullInputStream into a
> new file, maybe in ...catalina.util)
> - What about the Tomcat documentation? Where to document all this?
>
>
> 

Re: cloud cluster

[Jonathan S. Fisher]

We're doing the second: sessions stored in a Redis cluster with
sticky sessions. This topology is simple and it scales pretty easily until
it doesn't anymore [couple thousand simultaneous users]. You'll need to
judiciously use your debugger and unix tools to find bottlenecks, as
they're often hidden deep within the stack and present themselves in
non-obvious ways. Important caveat: See the discussion from earlier this
week on the mailing list about session replication and user authentication
with the redisson session manager.

On Sun, Feb 16, 2020 at 9:06 AM Jonathan Yom-Tov 
wrote:

> hi,
>
> What kind of configuration do people usually use when deploying on a public
> cloud (e.g. AWS)? An auto-scaling cluster with session replication? A
> auto-scaling cluster with all sessions stored in an external cache?
>
> Jon.
>


-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.

Re: Tomcat doesn't propogate Security Credentials during session failover

[Jonathan S. Fisher]

So the manager would be this, I've noticed it uses the StandardSession,
which explicitly prevents serialization of the user principal and auth
type: org.redisson.tomcat.RedissonSessionManager

Two questions, on org.apache.catalina.Session, do the values getNote and
setNote replicate across the cluster by default? I'm curious if we could
solve this whole thing with a valve that copies the principal into
the org.apache.catalina.Session or the HttpSession.

Next, Chris are you saying RedissonSessionManager should use their own
implementation of StandardSession that preserves the principal? I guess I
never got the questions answered, why isn't this the default behavior? It
seems tomcat goes well out of its way to *not serialize *the principal. I
was wondering if there was a reason for that.

Thanks!




On Wed, Feb 12, 2020 at 10:07 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Carsten,
>
> On 2/12/20 10:54 AM, Klein, Carsten wrote:
> > actually, Tomcat just does not serialize authentication
> > information, that is AuthType (BASIC, DIGEST etc.) and the
> > Principal, during session serialization. That affects session
> > persistence across restarts (no> matter what manager is used) as
> > well as session transfer between cluster nodes.
> The DeltaManager does indeed handle this information. Both the
> AuthType and the Principal.
>
> > As a result, persisted and reloaded sessions as well as sessions
> > transferred between cluster nodes are no longer authenticated.
>
> I have to admit, I've never actually set up a Tomcat cluster (because
> I think it's overkill for my purposes), but the code /is/ there.
>
> > I was pointing that out in this mailing list in late 2019 (Topic
> > "Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o
> > authentication related information").
> >
> > To overcome this, I have a simple solution in mind. It's only about
> > 10 new lines of code. Basically, it's a new boolean property
> > 'persistAuthentication' for the manager. Mark Thomas agreed with
> > optionally saving authentication information along with the
> > persisted session (only, if the new option is true). He encouraged
> > me to write an enhancement/patch and provide it as a Pull Request.
> >
> > The only problem for me is lack of time. Although the code itself
> > is quite simple, the things making me holding back are the Git
> > stuff, making Tomcat build in my Eclipse etc...
>
> Forget Eclipse. We can get you started very easily:
>
> $ git clone https://github.com/apache/tomcat
> $ cd tomcat
> $ ant deploy
>
> (done)
>
> - -chris
>
> > On 2/11/20 9:33 PM, Jonathan S. Fisher wrote:
> >>>> Apologies, I'm not seeing how this helps, I don't see where
> >>>> authentication information is transmitted
> >
> > No, seriously, what session manager are you using?
> >
> > -chris
> >
> >>>> On Tue, Feb 11, 2020 at 5:39 PM Christopher Schultz <
> >>>> ch...@christopherschultz.net> wrote:
> >>>>
> >>>> Jon,
> >>>>
> >>>> On 2/11/20 5:36 PM, Jonathan S. Fisher wrote:
> >>>>>>>> What do you mean by logged out If it's one from
> >>>>>>>> Redisson, then you should look at their code and not
> >>>>>>> Tomcat's code.
> >>>>>>>
> >>>>>>> So you have two tomcat nodes: A & B, clustered in any
> >>>>>>> fashion (forget I mentioned redisson) of your choosing;
> >>>>>>> let's say they're clustered using the built in tcp
> >>>>>>> point-to-point replication.
> >>>> The choice of session manager is ... pretty critical, here.
> >>>> So which session manager are you using/
> >>>>
> >>>>>>> Have 5 people logged into an application on the first
> >>>>>>> server using standard JavaEE APIs
> >>>>>>> (HttpServletrequest.login) Now turn off server A. Your
> >>>>>>> load balancer starts sending traffic to server B. Their
> >>>>>>> sessions will be there, BUT they will be logged out;
> >>>>>>> one has to call HttpServletRequest.login() again. Upon
> >>>>>>> login, Tomcat destroys the previous session (as it
> >>>>>>> should), nullifying any benefit for clustering the
> >>>>>>> application in the first place.
> >>>> Tomcat do

Re: Tomcat doesn't propogate Security Credentials during session failover

[Jonathan S. Fisher]

Apologies, I'm not seeing how this helps, I don't see where authentication
information is transmitted

On Tue, Feb 11, 2020 at 5:39 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jon,
>
> On 2/11/20 5:36 PM, Jonathan S. Fisher wrote:
> >> What do you mean by logged out If it's one from Redisson, then
> >> you should look at their code and not
> > Tomcat's code.
> >
> > So you have two tomcat nodes: A & B, clustered in any fashion
> > (forget I mentioned redisson) of your choosing; let's say they're
> > clustered using the built in tcp point-to-point replication.
> The choice of session manager is ... pretty critical, here. So which
> session manager are you using/
>
> > Have 5 people logged into an application on the first server using
> > standard JavaEE APIs (HttpServletrequest.login) Now turn off
> > server A. Your load balancer starts sending traffic to server B.
> > Their sessions will be there, BUT they will be logged out; one has
> > to call HttpServletRequest.login() again. Upon login, Tomcat
> > destroys the previous session (as it should), nullifying any
> > benefit for clustering the application in the first place.
> Tomcat does not destroy sessions when authenticating.
>
> > In the two links I provided, the StandardSession object goes to
> > great length to ensure that the security principal is not
> > serialized into the session
>
> True.
>
> > and therefore [not] replicated in the cluster.
>
> False.
>
> > Why is that? Why not serialize the security credential so the user
> > can bounce between servers?
>
> Authentication information is transmitted in a different way.
>
> I would really encourage you to look at the code for DeltaManager,
> which is the session manager typically used for clustering in Tomcat.
> If you are not using the DeltaManager, then you need to look at the
> code being used for your actual SessionManager.
>
> - -chris
>
> > On Tue, Feb 11, 2020 at 4:27 PM Christopher Schultz
> >  > <mailto:ch...@christopherschultz.net>> wrote:
> >
> > Jon,
> >
> > On 2/11/20 2:35 PM, exabrial wrote:
> >> https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-dur
> i
> >
> >>
> ng-session-failover-event-and-restarts
> > <https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-dur
> ing-session-failover-event-and-restarts
> <https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-during-session-failover-event-and-restarts>
> >
> >
> >
> >
> >
> >
> > We've implemented session replication using Redisson, but we
> > noticed
> >> that if we intentionally fail a node, the user's sessions do get
> >> replicated, but they're logged out when they're restored on the
> >> new server.
> >
> > What exactly do you mean when you say "logged-out"?
> >
> >> Is there a way to make this work properly so the user doesn't
> >> get logged out during a failover event?
> >
> >> Most /More importantly, is there a technical or security reason
> >> for this?
> >
> > FYI the servlet specification does not guarantee that
> >  web applications also transfer authentication
> > information.
> >
> >> If you look at the Tomcat code, they actively try and avoid
> >> serialization the Security Principal:
> >
> >> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina
> /
> >
> >>
> session/StandardSession.java#L1559
> > <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina
> /session/StandardSession.java#L1559
> <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/session/StandardSession.java#L1559>
> >
> >
> >
> >
> > https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/
> se
> >
> >
> ssion/StandardSession.java#L234
> > <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina
> /session/StandardSession.java#L234
> <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/session/StandardSession.java#L234>
> >
> >
> >  That code is for serializing the whole session, not transmitting
> > session information between cluster nodes. You need to read the
> > code for the various ClusterManagers and (more importantly), the
> > DeltaSession class.
> >
> > Which SessionManager are you using? If it's one from Redisson,
> > then you should look at their co

Re: Tomcat doesn't propogate Security Credentials during session failover

[Jonathan S. Fisher]

> What do you mean by logged out
>  If it's one from Redisson, then you should look at their code and not
Tomcat's code.

So you have two tomcat nodes: A & B, clustered in any fashion (forget I
mentioned redisson) of your choosing; let's say they're clustered using the
built in tcp point-to-point replication. Have 5 people logged into an
application on the first server using standard JavaEE APIs
(HttpServletrequest.login) Now turn off server A. Your load balancer starts
sending traffic to server B. Their sessions will be there, BUT they will be
logged out; one has to call HttpServletRequest.login() again. Upon login,
Tomcat destroys the previous session (as it should), nullifying any benefit
for clustering the application in the first place.

In the two links I provided, the StandardSession object goes to great
length to ensure that the security principal is not serialized into the
session, and therefore replicated in the cluster. Why is that? Why not
serialize the security credential so the user can bounce between servers?



On Tue, Feb 11, 2020 at 4:27 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jon,
>
> On 2/11/20 2:35 PM, exabrial wrote:
> > https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-duri
> ng-session-failover-event-and-restarts
> 
> >
> >
> >
> >
> We've implemented session replication using Redisson, but we noticed
> > that if we intentionally fail a node, the user's sessions do get
> > replicated, but they're logged out when they're restored on the new
> >  server.
>
> What exactly do you mean when you say "logged-out"?
>
> > Is there a way to make this work properly so the user doesn't get
> > logged out during a failover event?
> >
> > Most /More importantly, is there a technical or security reason for
> >  this?
>
> FYI the servlet specification does not guarantee that 
> web applications also transfer authentication information.
>
> > If you look at the Tomcat code, they actively try and avoid
> > serialization the Security Principal:
> >
> > https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/
> session/StandardSession.java#L1559
> 
> >
> >
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/se
> ssion/StandardSession.java#L234
> 
>
> That code is for serializing the whole session, not transmitting
> session information between cluster nodes. You need to read the code
> for the various ClusterManagers and (more importantly), the
> DeltaSession class.
>
> Which SessionManager are you using? If it's one from Redisson, then
> you should look at their code and not Tomcat's code.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5DKmgACgkQHPApP6U8
> pFj5fA/+MtxPWjtoiRCcfPJSvjdZjjZA1PbiTPSxXqtizg17071kQJVXy3GONP6O
> AONwDkm/+2yNo6RJvRH2WW5qLZgX9FvNekUVkDeM+MvNOwszqAx/doXgCwO1ljy3
> Dv1uOgWCGE2ktAig3Cul9BICGmq6hhcfI9yT0oicrrxKI9njpVKhhJijLvJEZNFp
> GeSwU2QMRR25asinBvCJ2L6wMFM5ppXjpwoWVvI1G+UlFYEUOZAAlNAsq/Dblmuo
> 45GrNQdw2LyKfjt/lLaQrjEOx3KoHtfIKBOxSBgwJFykx/w3RmoEXONrwj6tuTyG
> HVSvLITH0rky301YvXPqrEAseW0816grwbCkP1HrmDfbpVCQ/1QUb+ceKEHzLuOr
> 8XPha3M0xDhFF9daEqJcYurcIC6NCMy0UuvaSfvh3ICy/RFL2K4Sql9SRGnj4eLV
> 8QJTMHgKDD3Gie2wHr9gYDwj7gtkjHGJrMyCNOh1bTNSQKkabFlsUL1uiEOJ0QgR
> EkLketZAhWNGMiaS4X41jtqQymL5zJI7P7KqGy0LmuZErZt6qot/5If0osgnl1V+
> wjP6YjBU2i9YajNJB57JFtx3AkCRXUXZm4vAQnG8v//ECsWOrggdlQvF+W5r2mXr
> 50z5n2LUbUrKTX9N3ailoNczmZ/MyEhUhyTT7xmqSjLXtlFPO7g=
> =UkyD
> -END PGP SIGNATURE-
>


-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.