[jcifs] Re: Davenport and Resin

[Eric]

> 
> There is still a problem however. If I browse up into a workgroup and then
> drill back into a server I get ACCESS_DENIED trying to enumerate shares
> with a blank screen in the web browser. If I try to force it by adding the
> share name a password dialog appears but entering credentials does not
> work and there is no SMB communication going on at all.
> 
> I think what might be happening is the credentials are lost or degraded to
> GUEST but cannot be promoted back. I don't recommend changing credentials
> like that. I think you should just negotiate credentials with IE right
> from the start and associate the resulting NPA with the server that
> provided the challenge as that NPA is useless with any other server. This
> is what NetworkExplorer does with setProperty( "npa-" + servername ). If
> the user is denied access it is natrual to just reply with 401 which will
> provide the user with the Network Password Dialog into which they can
> provide new credentials. Now if the user browses back to a previous server
> during the same session the appropriate NPA will be used minimizing
> negotiations.
> 
> 

I'll have to poke around a bit with this to see if I can figure out 
what's going on.  Are you using the new (0.9.4) jCIFS jar, or the 0.9.2 
it comes with?  This sounds similar to the "uninherited credentials" 
issue previously reported.

Davenport should cache the credentials on a per-server basis (similar to 
the "npa-", but we store a single hashtable with servername as the key 
and NPA as the value).  The default auth exception behavior should be 
pretty much what you're describing (prompt for authentication).


> 
> With NT 4 any non-Latin1 characters are not displayed correctly and
> clicking on entries that are rendered as mostly ?????? results in enless
> directories or circular references. After a little while IE gets hung up.
> I think it might have crashed when I logged out too. It wasn't pretty.
> 
> 
>>, but I *think* it should work
>>with the normal browser interface.
> 
> 
> Yes it does work with the normal web interface. Looks great actually.
> 

The Web Folders client is kind of a separate beast from IE; IE will 
typically request non-ASCII resources using UTF-8 encoding (or at least, 
you can tell it to via Internet Options, and I think it will by 
default), whereas WebFolders will use the local character set encoding. 
  You can look at the "request-uri.charset" setting in web.xml to tell 
it how to interpret; but last time I tried Resin had some issues with 
non-UTF-8 requests.

> One other mildly annoying thing is that the web folder view is not
> persistent. If I select Details or List as soon as I visit another folder
> the view is reset to large icons. Is this specific to NT 4 maybe?
> 

I think my client does the same thing (although I never really tried to 
change it and test persistence); it would be however the WebDAV client 
decides to render it.

On a complete tangent, you're on NT4?  If you get a chance, could you 
send a packet trace of a session setup with the LMCompatibilityLevel 
registry setting set to 3?  The reason I ask is that all my boxes are 
2000+, and do extended security for NTLMv2 connections.  I was wanting 
to see how a non-extended client builds the NTLMv2 response without the 
blob from the NTLM type 2 message.  Might be able to get full NTLMv2 
support in.


Eric