You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2008/09/18 15:32:25 UTC
request for servlet filter
Hi.
In a Tomcat servlet application context, I use the jCIFS filter (see
jcifs.samba.org) to perform Windows NTLM authentication of IE clients.
It works well.
However, to work around a problem of browsers not being set up properly,
I would need a servlet filter inserted *before* jCIFS in the chain,
which would :
- detect if a client attempts a Basic (or Digest) authentication
- if yes, either return a static non-no html page top the client
immediately as a response, or re-direct the client to such a page (1)
- if no, then simply let the request through to jCIFS and the application
I can write such a servlet filter myself, but if it already exists I
might as well save myself the time.
Would anyone know if such a module is already available ?
In principle, I have a preference for a filter that would be
light-weight and do approximatively the above and nothing much else, but
something usable under Tomcat and offering capabilities similar to the
mod_rewrite module of Apache would also interest me.
Since in this case I also have an Apache http front-end, I could use
mod_rewrite in the front-end to do it, but I prefer for maintenance
reasons to keep everything related in one place.
(1) and, as a subsidiary question, what would the Tomcat gurus here
suggest as the best alternative between these two ?
Thanks in advance,
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
Re: request for servlet filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
André Warnier wrote:
> <note>
> The rule means that any request including Basic authentication
> will be redirected to the indicated page.
> </note>
> <condition name="auth" type="auth-type">BASIC_AUTH</condition>
> <from>^/.*$</from>
> <to
> type="temporary-redirect">%{context-path}/errors/IE_settings.html</to>
> </rule>
Nice... I've never used this package; I only knew that it existed. I'm
happy to see that it supports somewhat complicated conditions, etc.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjXl3sACgkQ9CaO5/Lv0PD/hACeOFVjoCmRgKqDvYTMqL2ilb3O
v9gAn3EMNdmqTrsU7le39zSB4f8zDsV1
=dzay
-----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
Re: request for servlet filter
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
[lots of good stuff snipped]
>
> You could check out http://tuckey.org/urlrewrite/, but I think that
> mod-rewrite is a full Swiss Army Chainsaw while urlrewrite is more of a
> santoku knife.
>
Went there, saw it, downloaded it. It seems to do what I want, and lots
more. Haven't tested it yet, but seems serious.
Thanks for the tip.
It does lots of the same things as mod_rewrite, a bit less in some
respects, but also a bit more in a Java servlet-oriented way.
Good documentation too.
From the look of it, I would think that if mod_rewrite is the 7-layer
Swiss Army knife for Apache, then urlrewrite certainly qualifies for the
5-blade level Swiss Army knife for Tomcat. Definitely better than a
kitchen knife, and way above what I could come up with.
Sample config file to do what I need :
<urlrewrite>
<rule enabled="true">
<name>Wrong IE auth settings</name>
<note>
The rule means that any request including Basic authentication
will be redirected to the indicated page.
</note>
<condition name="auth" type="auth-type">BASIC_AUTH</condition>
<from>^/.*$</from>
<to
type="temporary-redirect">%{context-path}/errors/IE_settings.html</to>
</rule>
</urlrewrite>
---------------------------------------------------------------------
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
Re: request for servlet filter
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> André,
>
> André Warnier wrote:
>> However, to work around a problem of browsers not being set up properly,
>> I would need a servlet filter inserted *before* jCIFS in the chain,
>> which would :
>> - detect if a client attempts a Basic (or Digest) authentication
>> - if yes, either return a static non-no html page top the client
>> immediately as a response, or re-direct the client to such a page (1)
>> - if no, then simply let the request through to jCIFS and the application
>
> So... the user is rejected if they are using Basic or Digest
> authentication? That seems backward.
Not really. To quench your thirst of knowledge, this is the problem :
in this environment, users are supposed to login using NTLM, always.
When they do that, they get logged into the Tomcat application using
their NTLM id, automatically thanks to jCIFS. This also acts as SSO,
which is nice and friendly.
However, this being a corporation with lots of employees and partners
all over the world, some users are not necessarily aware of what to do
in order to set up their browsers to do NTLM properly.
When they don't, and their browser receives a 401 from the server, the
browser (since it is not prepared to do NTLM) by itself falls back to
doing Basic authentication (IE does that). Which means that the browser
pops up a login dialog for the user to enter their user-id and password.
So they do, and the browser duly re-sends the request with a Basic
authentication.
But this not being acceptable to the server, the server sends a 401
again asking for NTLM. Which causes the browser to pop-up a login
dialog again. And this goes on and on.
All the poor user ever sees is this login dialog, and although he enters
his correct user-id and password repeatedly, the popup dialog keeps on
coming back, without any explanation.
So now the Service Desk in Mumbai gets a call at 3:00 AM, asking if
someone speaks Mongolian.
One way I can think of to avoid this, is when in response to the initial
401-NTLM from the server, the browser re-sends the request with a Basic
authentication (IE does that, nothing to do about it), instead of
letting this go through jCIFS again (which would return the 401-NTLM,
nothing to do about it), catch the request earlier, and upon detection
of a Basic authentication header, send a nice page to the user telling
him why this happens, and how to correct it.
Makes sense ?
I should add that the above idea being rather experimental, I have at
this time only an inclination to believe it would work, not a certainty,
which is why ..
>
>> I can write such a servlet filter myself, but if it already exists I
>> might as well save myself the time.
>
> Didn't I already write this one for you? ;)
To tell the truth, you might have..
I remember asking a similar (but probably not the same) question a while
ago, and there might be something I could use there. I'll go check.
But my problem then was to find a way, under certain circumstances, to
disable the next filter (jCIFS) while this filter would not cooperate
(it doesn't have a parameter for that, and I'm unwilling to mess with
the code).
>
>> something usable under Tomcat and offering capabilities similar to the
>> mod_rewrite module of Apache would also interest me.
>
> You could check out http://tuckey.org/urlrewrite/, but I think that
> mod-rewrite is a full Swiss Army Chainsaw while urlrewrite is more of a
> santoku knife.
I'll go check that one, it might be enough if it can check headers and
do redirects. Anything but writing something myself and having to
complain to myself afterward about bugs and the like.
I don't know what a santoku knife is, but I'll go Google that too. One
is never too old to learn. From your use of it, I guess it's a small but
sharp Japanese Army knife.
(Did that. Wrong, it's a sharp and not necessarily small Japanese
kitchen knife. Being myself a cook first, a programmer second, I should
have known that.)
>
>> (1) and, as a subsidiary question, what would the Tomcat gurus here
>> suggest as the best alternative between [redirect versus not]?
>
> That depends on what you want your users' experiences to be. What if
> they hit RELOAD? Do you want to re-run the test just in case they have
> logged-in again? My guess is that you'll want them to be able to
> re-load, so I wouldn't redirect. On the other hand, if you want to
> essentially ignore reloads and continue showing the "go away" page, then
> you should do a redirect.
> It seems more likely that you'll want to return a 401 response to the
> initial request, rather than returning any 3xx response.
If I understand this correctly, then my previous explanation should also
answer this. They are not likely to reload, unless they like the look
of the IE login dialog, or unless they have in the meantime corrected
their settings to allow NTLM. In which case they should now be ok.
And the page is not a rude "go away", it's more like a "Dear colleague
and friend, we would love to let you enjoy our services, but your
current browser settings don't allow it, according to internal company
regulation 23.II(bis), 3rd paragraph. So go away."
The fact that this is a German company is purely incidental.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjSgSQACgkQ9CaO5/Lv0PDDNwCgvqIMD+K4PYlTO7QZMjZbI77s
> 8kwAniT1ayMQ6DHG6gqOpbgM4L7Eia0V
> =+X87
> -----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
>
---------------------------------------------------------------------
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
Re: request for servlet filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
André Warnier wrote:
> However, to work around a problem of browsers not being set up properly,
> I would need a servlet filter inserted *before* jCIFS in the chain,
> which would :
> - detect if a client attempts a Basic (or Digest) authentication
> - if yes, either return a static non-no html page top the client
> immediately as a response, or re-direct the client to such a page (1)
> - if no, then simply let the request through to jCIFS and the application
So... the user is rejected if they are using Basic or Digest
authentication? That seems backward.
> I can write such a servlet filter myself, but if it already exists I
> might as well save myself the time.
Didn't I already write this one for you? ;)
> something usable under Tomcat and offering capabilities similar to the
> mod_rewrite module of Apache would also interest me.
You could check out http://tuckey.org/urlrewrite/, but I think that
mod-rewrite is a full Swiss Army Chainsaw while urlrewrite is more of a
santoku knife.
> (1) and, as a subsidiary question, what would the Tomcat gurus here
> suggest as the best alternative between [redirect versus not]?
That depends on what you want your users' experiences to be. What if
they hit RELOAD? Do you want to re-run the test just in case they have
logged-in again? My guess is that you'll want them to be able to
re-load, so I wouldn't redirect. On the other hand, if you want to
essentially ignore reloads and continue showing the "go away" page, then
you should do a redirect.
It seems more likely that you'll want to return a 401 response to the
initial request, rather than returning any 3xx response.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjSgSQACgkQ9CaO5/Lv0PDDNwCgvqIMD+K4PYlTO7QZMjZbI77s
8kwAniT1ayMQ6DHG6gqOpbgM4L7Eia0V
=+X87
-----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