[jcifs] jcifs.http.NtlmHttpFilter and POST

[Giampaolo Tomassoni]

> -----Original Message-----
> From: jcifs-bounces+giampaolo=tomassoni.biz at lists.samba.org
> [mailto:jcifs-bounces+giampaolo=tomassoni.biz at lists.samba.org] On
> Behalf Of Robert Baldock
> Sent: Thursday, August 21, 2008 12:00 PM
> To: jcifs at lists.samba.org
> Subject: RE: [jcifs] jcifs.http.NtlmHttpFilter and POST
> 
> Looking further into this, I found Kevin Tapperson's NTLMPostFilter
> from
> 2004 on this page:
> 
> http://article.gmane.org/gmane.network.samba.java/3708/
> 
> However, when I use the logic in this code in my filter, this check for
> an Authorization header:
> 
> String msg = httpRequest.getHeader("Authorization");
> if ((msg != null) && (msg.startsWith("NTLM "))) ...
> 
> always results in a msg with a null value.  As a result, the subsequent
> code that tries to fool IE is never actually entered.  The end result
> is
> that POST requests end up being ignored completely by the filter.
> 
> Does anyone know why this might be the case?

My really really broad guess.

NTLM is a per-channel authentication protocol, not a per-request one.

When you post something using an already-authenticated channel (which may
happen with servers configured for keep-alive channels), the POST request
needs not be authenticated again.

If you experience occasional problems in the content of a page or in a post,
it *may* be that the content you can't see or the post you can't submit
happens to run on an already-authenticated channel. If you run without
session support in the client and/or in the server, the NTLMHttpFilter would
issue again an SC_UNAUTHORIZED (404 I think) response code to the browser in
order to force it to authenticate. Unfortunately, since NTLM is a
per-channel protocol and that request isn't the first of the channel, IE
doesn't retries authenticating, but simply reports the error to the user.

More unfortunately, Tomcat and, more generally, J2EE-based content delivery
servers don't provide any easy way to known if an HTTP request is the first
of a channel or not, thereby you may need to disable any keep-alive
functionality in order to solve your issues. I have a custom-made version of
the NTLMHttpFilter which keeps track of the active connections by storing
the authentication state in an expireable map keyed by
SourceIP/SourcePort/DestIP/DestPort (which is the "unique key" TCP/IP adopts
for connections). At a request, the filter inspect the table to see if such
a connection is already known. If this is the case, it forwards the request,
otherwise it starts the NTLM authentication process.

Try tracking you http connections with Wireshark or the like. If you find
this is your case, try disabling keep-alives. If you really want
keep-alives, I can eventually spare my sources, but please note they are
meant for my own app, so you will definitely need to tune them to your own
needs.

Giampaolo


> 
> 
> Robert