Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution.
Regards sascha -----Ursprüngliche Nachricht----- Von: Rainer Jung [mailto:rainer.j...@kippdata.de] Gesendet: Dienstag, 17. März 2015 15:00 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem Hi Sascha, Am 17.03.2015 um 13:02 schrieb Sascha Skorupa: > Rainer, thank you for this hint, but unfortunately, this feature is too new > to be included in any current mod_jk linux package and building it from > source it not an option for a production environment. Too bad because that is > exactly what we need that. are you using Apache 2.4? In that case I might have an alternative recipe for you. Regards, Rainer > Christopher, your suggestion sounds interesting. Would it be an option for > future releases of tomcat? > > Sascha > > -----Ursprüngliche Nachricht----- > Von: Christopher Schultz [mailto:ch...@christopherschultz.net] > Gesendet: Freitag, 13. März 2015 19:24 > An: Tomcat Users List > Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest > Authentication problem > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Rainer, > > On 3/13/15 12:15 PM, Rainer Jung wrote: >> Am 13.03.2015 um 16:28 schrieb Christopher Schultz: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> Mark, >>> >>> On 3/12/15 1:13 PM, Mark Thomas wrote: >>>> 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. >>> >>> Perhaps an option in Tomcat that will force the creation of a >>> session when a DIGEST authentication is requested might be useful. >>> This would tie e.g. mod_jk to the proper back-end server. >>> >>> I'm not sure how this could be done using mod_jk without such a >>> feature, or changes to mod_jk itself to annotate the request with >>> the chosen worker, which could then be converted into a cookie in >>> order to keep the node-hint associated with the client. >> >> Yes, mod_jk can help since version 1.2.38: Look for >> "set_session_cookie" on >> http://tomcat.apache.org/connectors-doc/reference/workers.html. >> Using that attribute you can let mod_jk set the cookie, if it doesn't >> find one already set by Tomcat. You need to also set >> "session_cookie=JSESSIONID" and "session_cookie_path=/myapp" where >> you adjust myapp to your context path. > > Oh, good: I had missed that feature. Thanks for pointing it out! > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz > NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh > wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ > 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn > FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d > 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq > x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 > UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP > 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S > V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR > UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 > XROKEh5OIpcNKOPxBoof > =w+jN > -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org