tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: enabling/disabling a servlet filter conditionally
Date Mon, 04 Aug 2008 04:00:54 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

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

The details of Filter B are entirely irrelevant.

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

No problem.

| 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.

So your "Filter D" looks something like this:

public static final String SKIPPED = "SkippedJCIFS";
private static final String NTLM_HEADER = "[whatever]";

private final JCIFSFilter _jcifs;

public void init(FilterConfig config)
{
~  _jcifs = new JCIFSFilter(); // or whatever
~  _jcifs.init(config);
}

public void destroy()
{
~  _jcifs.destroy();
}

public void doFilter(ServletRequest request,
~                     ServletResponse response,
~                     FilterChain chain
{
~  if(request instanceof HttpServletRequest)
~  {
~    if(null != ((HttpServletRequest)request).getHeader(NTLM_AUTH))
~    {
~      // Manually invoke the filter
~      _jcifs.doFilter(request, response, chain);
~    }
~    else
~    {
~      // Skip the JCIFS filter
~      request.setAttribute(SKIPPED, Boolean.TRUE);
~      chain.doFilter(request, response);
~    }
~  }
~  else
~  {
~    chain.doFilter(request, response);
~  }
}

| 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.

Hmm... this could be problematic, as I think request headers are
read-only. Unless you want to wrap the request and artificially insert
headers. Yuck.

| 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).

Using the above code, FilterC need only check for the SKIPPED key in the
request attributes.

| 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 ?

I'll leave that as an exercise for the reader ;) Here's a hint: I did
something in the init() method that will help you a lot.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiWfvYACgkQ9CaO5/Lv0PB7dgCfQM0xRxi4y2l8TPXqpgMa1zr2
fYwAni1UhZU+IoeJ5UM5ElzYgo+/DJ4E
=cSnI
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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