tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: enabling/disabling a servlet filter conditionally
Date Sun, 03 Aug 2008 10:10:51 GMT
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> André,
> 
> André Warnier wrote:
> | Can one dynamically disable a servlet filter under some conditions, from
> | within another preceding filter ?
> |
> | In other words, suppose I have a servlet configured approximately like
> | this :
> 
> [snip]
> 
> | And suppose that I control the code of filter A but have no access to
> | the code of filter B, and filter B has no parameter allowing to make it
> | conditional.
> 
> Do you have the ability to alter the configuration? I have another idea...

Yes, I have.  And I'm interested, though I have to tell you, my 
knowledge in these matters is limited.

> 
> Take Filter B completely out of the configuration for the webapp and
> install Filter D in its place.
> 
> Filter D is a newly-written filter you write that does nothing but
> dispatch to a private instance of Filter B after checking the
> appropriate conditional that you set up (and probably note in the
> request attributes).
> 
> If you want, you can fake the FilterChain object so that doFilter does
> nothing and then do the dispatch back to the FilterChain after
> FilterB.doFilter returns, or you can just let FilterB.doFilter call back
> into the filter chain itself. I think that should work.
> 
> This strategy allows you to accomplish your goal with a minimum of effort.
> 
That last bit is what I'm intested in. :-)

To talk in concrete terms, this here is filter B :
http://jcifs.samba.org/src/docs/ntlmhttpauth.html

So, it's not that I have no access to the code, it is that I don't want 
to mess with the code, as I'm not smart enough to do that.

After filter B, I have my own filter C, which must remain in place.

The reason of it all is :
The JCIFS filter enforces Windows Domain NTLM authentication on the 
callers, and then sets the Tomcat user-id accordingly for the request.
That's fine if the callers all are prepared to do NTLM authentication, 
but in this case I have a situation where some callers can, some others 
can't. (See for example : 
http://jcifs.samba.org/src/docs/ntlmhttpauth.html#transparent)
However, JCIFS does not give a choice.  If it is in the filter chain, it 
forces NTLM authentication on the browser, and a browser that can't gets 
stuck in an endless loop of browser login popups.

It would be easiest if I could ask the JCIFS developers to add to JCIFS 
a test on some request attribute, and maybe just let the request through 
if this attribute is set.  But I feel a bit shy about asking them that, 
and I don't know if this would open some enormous security hole or so.

So instead, I want to check, when the request comes in, if it has an 
NTLM "Authorization:" header.
If it has, I want to let JCIFS do it's stuff.
If it hasn't, I want to bypass JCIFS, and set some flag.
My filter C runs after JCIFS. Its role is (right now) to pick up the 
Tomcat user-id (as set by JCIFS), and add it to the request as a HTTP 
header with the user-id, because that is what, finally, the application 
behind the servlet (which I do not control either) expects.

Thus what my (new) filter A should do is check the request, and 
depending on some condition either "run" (or "let run") the JCIFS 
filter, or else set a request attribute, which will allow filter C later 
to decide to either get the authenticated user-id from Tomcat (as set by 
JCIFS), or set it by default to "anonymous" (if JCIFS did not run).

The only servlet filter I have written so far is filter C.  In order to 
do that, I had to "wrap" the request by subclassing 
HttpServletRequestWrapper, and pass a modified request to the servlet.
That I know how to do, and that is about the state of my knowledge on 
Java servlets and servlet filters.

So, to get back to the problem at hand, where do I start ?
Or, considering my limited knowledge, do you think this is beyond what I 
can reasonably undertake ?

One concern I have with the scheme you outline above, is that JCIFS 
expects a lot of configuration parameters, normally in the web.xml.  If 
I make it into a private instance, how do I set up things so that it 
still finds these parameters ?

And thank you very much for the interest.

André


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message