[jcifs] RFE's for NTLM HTTP Authentication

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Karl [SMTP:karlduesentrieb at compuserve.de]
> Sent:	Sunday, February 16, 2003 12:57 PM
> To:	jcifs at lists.samba.org
> Subject:	[jcifs] RFE's for NTLM HTTP Authentication
> 
> Hello,
> 
> I have RFE's for NTLM HTTP Authentication in jCIFS.
> I don't know where I should send so I send this to this list.
> 
> 1. RFE
> when SmbSession.logon throws an Exception because of invalid credentials,
> this exception is not catched and an Authentication fails without giving the
> Browser/user giving a chance to provide other credentials.
> Better would be in such case to catch the exception and to send another
> "WWW-Authenticate", "NTLM"  header.
> 
	This was done in 0.7.3.

> Also useful would be an interface which gives the application the
> possibility
> to reject the credentials and to demand others even if they are valid for
> the DC.
> For example they maybe  not valid for the application.
> 
	This is very application specific behavior that I don't quite understand and sould
	be done by writing your own Filter with the NtlmSsp class.

> 2. RFE
> sometimes NTLM HTTP Authentication is failing or is suppressed for some
> reason.
> (for example some proxys are disrupting NTLM HTTP Authentication)
> this would leave a blank page in the IE window, because the jCIFS
> WWW-Authenticate
> response sends an empty body.
> Better would be an possibility/interface/responsebuffer for the application
> to provide
> a html body and/or additional response headers which could deal with such an
> incident.
> (For example a timed redirect to a fallback url or webpage which gives the
> user a hint)
> 
	The bodies aren't empty but they are sent in a different packet. It's not clear to
	me why this should be a real problem because they just contain error message
	junk. I don't recall exactly why the body is in a separate packet. I believe it was
	necessary to keep the connection open during the 3 message dialog. This NTLM
	over HTTP thing is non standard so maintaining state accross the negotiate
	presented some problems. To pursue this further we would need to see a packet
	trace of the errant dialog.

> Hope this is also useful for others.
> 
> 
>  Charly
> 
> 
> appended class NtlmServlet
> 
	What is this supposed to show us?