[jcifs] This may be silly, but: How important is SmbFile to N TLM Authentication.

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	dave mobley [SMTP:scprotz at hotmail.com]
> Sent:	Tuesday, June 24, 2003 12:11 AM
> To:	jcifs at lists.samba.org
> Subject:	[jcifs] This may be silly, but: How important is SmbFile to NTLM Authentication.
> 
> So, before everyone blasts me, I've read through the code and noticed that 
> some of the files used for the NTLM authentication component eventually rely 
> on SmbFile (I don't know exactly how at this point, other than UniAddress 
> needs Netbios which needs Lmhosts which needs SmbFileInputStream which needs 
> SmbFile....whew...thats a mouthful!)
> 
	That's it. The only thing the ntlm http code needs is SmbSession.logon().

> My project is to port the NTLM authentication piece to 1.1.8 (sorry, I don't 
> need the file sharing...I just want to use it to authenticate in my 
> servlets).
> 
	The one thing that would really hold you back here is jcifs.smb.Handler. It
	uses the 1.3 version of URL.set. That's it. If you copy over the (broken)
	Handler from jcifs-0.6.8 that might be it. Or maybe you can nix
	jcifs.smb.Handler entirely. There might be some Java 2-isms since we
	commited to Java 1.3 but nothing serious.

> I'm using an outdated servlet engine and jdk (2.0 and 1.1.8 respectively - 
> trust me...I'd change if I could).
> 
> I can (with some mild changes back to 'deprecated' forms of methods) get 
> everything to compile except for SmbFile (looking at it a bit, I don't even 
> thing it would compile under jdk1.2.2)
> 
	Nix jcifs.smb.Handler. Factor out "extends URLConnection". It has hooks
	into the URL protocol handler.

> So, back to my question, how important is SmbFile for the authentication 
> piece? (can it be subbed out with something else that is happy inside 
> jdk1.1.8)?
> 
	Dropping it entirely is probably more trouble than it's worth. The protocol
	handler was the whole reason for requiring 1.3. If you can factor that our it
	should compile with 1.1.

	Mike