tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: request for servlet filter
Date Thu, 18 Sep 2008 19:36:32 GMT
Christopher Schultz wrote:
> 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 
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, 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
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla -
> 8kwAniT1ayMQ6DHG6gqOpbgM4L7Eia0V
> =+X87
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message