[jcifs] Re: Davenport and Resin
eglass1 at comcast.net
Thu Jul 1 00:32:34 GMT 2004
> 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
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
> 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
More information about the jcifs