tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Jay" <>
Subject Re: Basic and Form Authentication
Date Tue, 01 Dec 2009 11:38:55 GMT
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)

Hash: SHA1


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
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message