[jcifs] Linux and Windows

[Tyrrell, James]

Eric,

That is what I was talking about.  With the way our network is set up
hitting an IP address appears to go out all the way to the firewall and then
back in.  

IE has settings under tools/internet options/security and under custom level
there is at the very bottom for 
User Authentication/Logon that under internet is "prompt for user name and
password".  I am guessing that our network setup creates a case where this
is set as I specified above and the server and the browser just keep talking
forever.  At least that is what I am guessing looking at the debugging
output I added to your class.  I think if you set it to automatic logon it
would probably just work.

I will try to look into this and see if I can get it to break, but I think
you can maybe get it to break the way I am talking about by playing with the
IE settings I spoke about above.

Thank you
Jim Tyrrell



-----Original Message-----
From: eglass1 at attbi.com [mailto:eglass1 at attbi.com]
Sent: Thursday, March 27, 2003 1:00 PM
To: Tyrrell, James
Cc: jcifs at lists.samba.org
Subject: RE: [jcifs] Linux and Windows


I wasn't able to reproduce this... are you talking about just accessing the 
site like

http://10.10.2.20/path/page.jsp

This worked properly for me.  If you could provide instructions on
reproducing, 
I will take a look at it.  Thanks!

Eric
> 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