Sascha, you can configure source address stickyness as well as destination address stickyness, both will provide the same result which will work for you.
2015-03-12 18:13 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 12/03/2015 15:20, Sascha Skorupa wrote: >> Hi, >> >> here: >> >> http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication >> >> the same problem is described and the recommended solution is to use sticky >> load balancing. But, the problem in a tomcat cluster is that the session ID >> is generated after a successful authentication. The first http response (401 >> with Authentication Header) does not contain a session ID. >> >> How should sticky load balancing be configured or how to enforce session id >> generation before authentication? > > Most load-balancers have various options for doing this that don't > depend on the back-end server at all. > > Mark > > >> >> Regards >> >> Olschi >> >> >> Von: Sascha Skorupa >> Gesendet: Mittwoch, 4. März 2015 16:21 >> An: 'users@tomcat.apache.org' >> Cc: Sebastian Olscher >> Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest >> Authentication problem >> >> Hi, >> >> because of changes in the HTTP digest implementation within the JDK 8 >> (https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate >> from tomcat 6 to 7. >> >> The problem is that we have a tomcat cluster (several tomcats behind an >> apache/modjk server) and we cannot guarantee that both HTTP requests >> resulting from the digest authentication are sent to the same tomcat >> instance. In Tomcat 6 it was no problem because nonces were not cached or >> rather unknown nonces did not force a re-authentication like it is done in >> the DigestAuthenticator of Tomcat 7: >> >> if (info == null) { >> // Nonce is valid but not in cache. It must have dropped >> out >> // of the cache - force a re-authentication >> nonceStale = true; >> } >> >> Some clients have the problem that the second 401 response to the request >> with authorization header leads to an authentication failure although the >> credentials are correct. Other clients like e.g. JMeter keep trying to send >> authorisation header, if stale is true, until a HTTP 200 is responded. >> >> So, what is the recommendation here? How to use Digest authentication within >> tomcat clusters if nonces are cached in a map within DigestAuthenticator? >> >> Best regards >> >> Sascha >> >> > > > --------------------------------------------------------------------- > 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
