tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Contexts and Path and Authentication
Date Thu, 10 Dec 2009 22:56:58 GMT
Hash: SHA1


On 12/9/2009 5:40 PM, André Warnier wrote:
> Ok, my try here.  And by the same token - haha - I will give a chance to
> Chris to jump in.

Sure, why not?

> - there is (preferably) one application.  As Chuck is saying, it should
> not care /how/ the user was authenticated, just that he is.
> That's just a getRemoteUser() for you, isn't it?


> - unfortunately, the Holy Servlet Spec does not foresee nor allow that 2
> alternative methods of authentication would be used.


> This looks to me the perfect case for a servlet filter.


> The filter applies to all requests to the webapp.

- -1 (see below)

> - the request itself contains an "Authorization:" header.


> - the request contains an authentication cookie (header).


> B) Neither of the above is true, so the request is not authenticated.

I think Anthony wants to /always/ use FORM for some URLs, and /always/
use BASIC for others. He hasn't said whether he wants either
authentication to allow access to the "other" part of the site.

securityfilter ( can be tricked
into doing this. Although the standard operating procedure is to map sf
to all URLs (i.e. <url-pattern>/*</url-pattern), one can choose to map
it to different patterns and deploy it /twice/:

        <filter-name>Security Filter BASIC</filter-name>

        <filter-name>Security Filter FORM</filter-name>

/secure/yyy  -->Form based auth
/secure/xxx  -->Form based auth
/public/  -->Form based auth
/secure/xml/  -->basic auth
/xml/  -->basic auth
- -->

        <filter-name>Security Filter FORM</filter-name>

        <filter-name>Security Filter BASIC</filter-name>

Now, you simply have to configure each filter's instance with a
different configuration file (one using BASIC, one using FORM) and
you're good to go.

URLs that don't match any of the patterns above will basically be unable
to correctly use request.isUserInRole() and request.getPrincipal(), so
you ought to think about that very carefully.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message