[jcifs] Linux and Windows

[Tyrrell, James]

I installed this update and used it.  Thank you Eric.  There is one thing
that I have noticed.  When getting at the site with a ipaddress in the URL
this filter and browser get in a loop passing info back and forth without
the browser ever sending in the proper authentication or the filter timing
out.  I will try to isolate this a little more and hopefully come up with a
fix.

I agree with Eric that this kind of functionality needs to be around so that
we can replace IIS servers with much better free Java Web servers.  This is
a great package and I thank all who have worked on it.

Thank You
Jim

-----Original Message-----
From: eglass1 at attbi.com [mailto:eglass1 at attbi.com]
Sent: Thursday, March 27, 2003 7:59 AM
To: Tyrrell, James
Cc: miallen at eskimo.com; jcifs at lists.samba.org
Subject: Re: [jcifs] Linux and Windows


> The real solution here is to stick with the method selected and enable
> Mozilla to negotiate NTLM password authentication. Unfortunately,
> last I heard, there is a bug in Mozilla's that has to do with reissuing
> requests over *the same* connection. Mozilla is not incorrect to close
> and reissue requests on a new connect. In fact NTLM HTTP authentication
> is non-standard in this respect. So those two facts have not compelled
> the Mozilla folks to incorporate this functionality. Still, I think this
> is really a Mozilla problem. It's certaintly not a jCIFS problem! :~)
> 

Persistent connections are actually the default behavior in HTTP 1.1
(although NTLM is still weird in that it REQUIRES persistence).


> See Mozilla bug reports:
> 
>   http://bugzilla.mozilla.org/show_bug.cgi?id=23679
> 
> Also the below describes a patch that implements some kind of Windows
> passwordless authentication however it's not clear to me what it does
> exactly:
> 
>   http://bugzilla.mozilla.org/show_bug.cgi?id=159015
> 
> Quite a few people have had their hands in this problem. If you look
> closely even Andrew Bartlett from Samba is involved.
> 
> Mike
> 

This uses the Microsoft SSPI libraries, so it is a Windows-only fix
(basically,
rather than implementing the client side of NTLM, they just pass the tokens
to
the native APIs).  This approach was probably taken for simplicity's sake.
There is an NTLM HTTP client in the Jakarta Commons which contains an open
source Java implementation; it would be interesting to examine that further.
I'm not at all familiar with the Mozilla codebase, but it would at least
seem
feasible to try incorporating this logic into Mozilla and give NTLM to the
non-Wintel world.

That being said, there are a few compelling reasons to add HTTP Basic
support.
I'm not sure it's reasonable to expect every HTTP client on the planet to
start
supporting NTLM.  Even if Mozilla gets this working, there are still lots of
clients that will never provide support.  Also, IIS can be configured to
provide both Basic and NTLM authentication.  Currently, if a servlet needs
this
functionality (i.e., to service non-IE clients but still authenticate them
against a domain), the only real alternative is to install a servlet
container
under IIS and use IIS to provide authentication.  It would be nice to be
able
to replace this IIS niche market completely with jCIFS.

Attached is my take on this; this version defines two properties:

jcifs.http.basicRealm -- realm for basic authentication (defaults to
"jCIFS")
jcifs.http.enableBasic -- enable basic authentication
jcifs.http.insecureBasic -- enable basic authentication over plain HTTP

By default, basic is disabled completely.  By setting enableBasic to true,
Basic authentication is enabled over HTTPS only.  By setting insecureBasic
to
true, Basic authentication is also offered over insecure HTTP.

I think this provides a pretty fair balance, in that a conscious effort has
to
be made on the part of the jCIFS user to enable an insecure configuration.

In any case, this should serve James' needs.

Eric