anonymous wrote : I'm having a possible related issue where a custom login servlet that we use to handle the Form authentication is doing something really bad, and not following any standards
I'd assumed from your mention of "j_security_check" that you were using container managed authentication. ClusteredSingleSignOn is based on Tomcat's SingleSignOn valve, and is tightly integrated with Tomcat's Authenticators (which provide container managed authentication). Unless your login servlet is somehow integrated with the Tomcat infrastructure, ClusteredSingleSignOn won't work; you'd need to use TC's form authentication configured through web.xml. anonymous wrote : I'm going to try another possible approach. From what I can tell about mod_jk and Tomcat, the Tomcat server.xml Host element needs the jvmRoute="node name" attribute to enable sticky sessions. Once we get that login servlet in a better state, I'll try enabling sticky sessions to see if this helps solve the "notes" replication issue. In my experience, sticky sessions are almost always the way to go for a web app that keeps any kind of server-side state. It should definitely prevent the "400 response from server B" scenario I described (but maybe not whatever's causing your login servlet to issue a 400). If using sticky sessions is possible in your app, and using container managed authentication is an option, ClusteredSingleSignOn will work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878654#3878654 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878654 ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
