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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
