[jcifs] Alternative to jcifs.http.NtlmHttpFilter

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	eglass1 at attbi.com [SMTP:eglass1 at attbi.com]
> Sent:	Tuesday, October 22, 2002 3:30 AM
> To:	Allen, Michael B (RSCH)
> Cc:	'Michael Piscatello'; jcifs at lists.samba.org
> Subject:	RE: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
> 
> I thought about this as well -- one thing that might be 
> useful would be to include the HttpServletRequestWrapper 
> in the filter (to provide getPrincipal(), getRemoteUser
> (), etc.),
> 
	Not sure what you mean by this. Do you mean include the
	HttpServletRequestWrapper class with the jCIFS package?

>  but then set the "NtlmHttpFilter" session 
> flag to the principal name (i.e., 'DOMAIN\user') instead 
> of just the string "1".  That way, it provides a quick 
> and dirty means of obtaining that information under 2.2-.
> 
	Actually I did change the attribute name to NtlmHttpAuth
	and I put the NtlmPasswordAuthentication object in the
	session instead of "1". I realize this was the sort of thing
	that got me in trouble the last time but take a look. I think
	you'll agree it should work just fine. Pre-2.3 users can
	retrive that. It now implements java.security.Principal so I
	need to put that in the session so I can pass it to the
	NtlmHttpServletRequest (a.k.a your NtlmRequest). Doing
	this avoids performing NTLM SSP with each and every
	request which is noticably slower and provides the
	getRemoteUser functionality at the same time.

> Also, it might be clearer to use a more "generic" 
> attribute name ("NtlmUser" or something) since I used 
> the same attribute for the servlet; that way, if you use 
> both the servlet and the filter in a post-2.3 
> environment, the authentication can interoperate.  On a 
> more pedantic note, the servlet spec recommends that 
> attribute names use the "jcifs.http..." convention for 
> naming (to avoid collisions).
> 
	Then we should change it to jcifs.http.ntlmdomain and
	jcifs.http.ntlmuser. It would also be nice to extract the
	workgroup and netbios hostname like I was doing
	previously.