[jcifs] understanding server challenge change

[leostone]

Alright, alright,

i'll try to be more clear. First, I never assumed that a bug or change in 1.1.10 
is causing the problem. I am still using 1.1.9 since I wasn't thinking that
the problem is caused by jcifs. Also the changes in 1.1.10 didn't really suggest
that they would have any impact on my problem.
Basically I wrote a filter that stores a SmbFile object in the users http session
wich is used as the root to some files during the request. On each request the filter
checks if this SmbFile is still "valid". Valid meaning that accessing this file won't
throw "InvalidMemoryAccess" exception, wich would mean that the "transport?" had been closed,
the server challenge had changed and new password hashes have to be requested from the
http client. 
This had worked here accessing winXP, win2K and Linux Samba shares without problem.
It has also worked accessing resources on a win2K share at the company for which I am developing.
Only now, when they want to access files on another win2K share there is
following problem. 

Lets assume a first http request.
The filter sees that there is no SmbFile yet in the http session.
It gets a challenge from the win2K server by calling SmbSession.getChallenge(ipOfWin2KServer).
It passes the challenge to NtlmSsp.authenticate() which does all the http header modifications.
If this method returns null, I don't continue the filterChain and just return so the http headers get send to
the client. When NtlmSsp.authenticate() returns an NtlmAuthentication object I use it straight
to create a SmbFile, do a connect() and bang!!! get an "InvalidMemoryAccess"  Exception.
To me that means, during the time it takes to negotiate the password hashes with the http client the
SmbTransport shuts down already. Or I am handling something wrongly, but why then does it work in all cases except
one? So what I am looking for is some hint what could cause that the challenge is different between the call to
getChallenge() and the connect() when there is "only" the password hash negotiation in between?
I try hard to reproduce the problem here, so far without success. 

thanks for your patience

-----Original Message-----

>
>Leo,
>
>You have to be 100x more clear. You started out saying some change in
>1.1.10 caused a problem. Then it was the challenge was "changing". Now it
>works in staging but not in production.
>
>I suggest that you backup and start over. Determine precisely at which
>point the application does not do what you expected. Provide a stack trace
>and narrate the possible causes. Provide information about your
>environment. What type of server, container, versions, etc. Do not assume
>anything.
>
>Mike
>


Качай бесплатные программы на все случаи жизни http://r.mail.ru/cln2670/soft.mail.ru