Thanks all for your comments, I do appreciate the expert assistance. As I suspected I will have to split the webapp into seperate apps based on the authentication method required. Seems like a funny way to arrange an application but such is life. As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. In terms of hacking code to fudge application access, this would be low on my list, I would not like to alter or maintain security related code. Many thanks again. (Much head scratching to continue) Tony
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony, On 11/30/2009 4:53 AM, Anthony Jay wrote: > Is is possible to have an application that serves content protected by > BASIC and FORM based auth? As Mark points out, the servlet spec says "not in the same webapp." Tomcat implements the servlet specification and no more, so you are out of luck, there. > I could deploy seperate apps for each type but I would then lose access > to application specific information e.g. Singletons and Statics, which > will cause big problems. I would strongly advise you to separate your webapps: one webapp for your XML-based API and the other for human interaction. Don't forget that your human UI could make use of the XML API behind the scenes. This is typically called "drinking your own Cool-Aid". If it's possible for you to do so, you could put your shared singleton/static classes into a shared ClassLoader. What kinds of things are you using that you would need to share across webapps? Could those things be converted into services that both webapps could share? Note that an XML service whose URL contains a jsessionid parameter will be associated with the indicated session. You could use such a URL to avoid the FORM authentication (but getting the session id is, of course, an issue unresolved by this). Finally, you could go out on your own and implement your own authentication mechanism. Securityfilter is a simple, filter-based authentication and authorization mechanism that you could hack-up to do this type of thing. Actually, you could use it out-of-the-box and just use a Filter configured /in front/ of it to trick sf into trusting a Principal configured by your Filter (which comes from the request's HTTP AUTH data). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUHsEACgkQ9CaO5/Lv0PD/jACeKCyBSKRnZtnso5EzEPROUMXO i74An09m3QZY0GTl47KplbdCSu/NG1wr =t+z3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
