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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
