[jcifs] How long is a NtlmPasswordAuthentication object valid ?

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Eric [SMTP:eglass1 at comcast.net]
> 
> > Here's the tricky part. The NPA password hases should be updated *in-place* if the
> > client reauthenticates NTLM. So in theory the client could negotiate NTLM http
> > authentication from which you get an NPA object and use that to access files, named
> > pipes, etc. Then the transport to the target SMB server closes invalidating the NPA
> > password hashes because the server challenge is now wrong. Now the client makes
> > another request re-negotiating NTLM http authentication which updates the NPA
> > password hashes *in-place* and you can go about your business with the *same*
> > NtlmPasswordAuthenctication object.
> > 
> > At one time this did work like that but I haven't tested this in a while. Can you confirm
> > Eric?
> > 
> 
> Currently it creates a new NPA with the new hashes (rather than updating 
>   the ansiHash/unicodeHash) and replaces the NPA in the session.  I 
> don't remember it doing an in-place changeout, but it may have before I 
> was involved; currently I don't think the NPA has a facility for 
> changing out the hashes once the object is constructed.  I don't see any 
> reason why it *couldn't*; from the HTTP side of things, we would just do 
> something like:
> 
> if (auth == null) {
>      auth = new NtlmPasswordAuthentication(domain, user,
>              lmResponse, ntResponse);
> } else {
>      synchronized (auth) {
>          auth.setAnsiHash(lmResponse);
>          auth.setUnicodeHash(ntResponse);
>      }
> }
> 
	For some reason I don't think this would work. I distinctly remember the
	NPA constructor that accepted byte[] arrays was used so that the NTLM
	code could save references to those arrays and update them after the
	NPA object was created and handed out. I remember having a lot of
	trouble making it work correctly though. Although I've searched through all
	the archives (pretty much every one of the 0.7.0bX-0.7.3) and I don't see
	where I was updating these in-place so maybe I refactored it out early.

	Doesn't matter. The important question is, if you un-hardcode the
	soTimeout in NtlmHttpFilter so that you can let the SmbTransport close
	after 15 seconds while your app is holding an SmbFile reference created
	with the NPA of the session does a new request that trys to access the
	file again now fail? If it does that's a problem.

	Mike