Adam, I thought that this was a spec issue and a quick review of the bugzilla postings confirms this. The best place to follow this up is with the servlet spec team.
Mark > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 18, 2004 10:46 AM > To: [EMAIL PROTECTED] > Subject: [Fwd: container managed security] > > Nobody responded to my previous message, but I am still searching for > information on the subject. Any references to docs would be > welcome. I > have searched for threads on this list in the archives but had no joy > either. > > Thanks > Adam > > -------- Original Message -------- > From: - Fri Mar 12 18:50:10 2004 > To: [EMAIL PROTECTED] > Subject: container managed security > > In tomcat 4 I was able to to protect my app with non-SSL > security-constraints while using SSL form-based authentication so that > the passwords were not sent in clear text. This has been a > specification > of the last 3 projects I have worked on. > > In tomcat 5 this is impossible without coding a work-around. > > I logged this as a bug in tomcat but it was closed as 'invalid'. > > http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 > > I remember 6 months ago someone saying that the tomcat developers had > decided that due to the danger of session-hijacking, if it was worth > encrypting the login, it was worth encrypting the whole > session traffic. > > Due to the charges that the extra hardware brings when doing all > logged-in sessions in SSL, amongst other reasons, I disagreed and > developed a work-around to let me carry on using the Struts & Tomcat > security features. > > This took me a few days back then, and then this week something else > cropped up which caused me to revisit the work-around code and spend 2 > days adding to it (and documenting it - it's pretty arcane). > > It occurred to me that this will always happen. The work-around is > vulnerable to any changes in the servlet spec of course, but also in > tomcat and in struts. > > I would appreciate finding out the whole story on this - last time I > just let it go through lack of time. If I'm in the wrong > place - perhaps > the JCP Servlet working group would be better - can someone > point me in > the right direction? > > Adam > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
