[jcifs] jcifs.smb.SmbException: No description available[ERRS RV/90] - 15 Minutes per day

eglass1 at comcast.net eglass1 at comcast.net
Tue Aug 26 18:39:51 EST 2003


> > we are using GET. to mimimize the number of smb-logons, we made 
> > a subclass of the filter which checks if if the user's session
> > has already been authenticated. if not, the authentication takes place 
> > (call the filter-method of the superclass), else nothing happens. 
> > 
> 	This is strange. If you're really caching NPAs you would have to have
> 	hundreds of thousands of distinct users. The NtlmHttpFilter already
> 	checks the HttpSession for the NPA. Perhaps what you're doing is
> 	interferign with that behavior.
> 

This could also happen if the HttpSession timeout is low; if, for example,
people use the application all day long but the session times out after 5
minutes, a new NPA will be created for the next request (and stored in the new
session).  Also, if the user closes their browser completely and reopens the
application a new HttpSession will be spawned (with a new NPA).  There is also
the possibility that the client has cookies disabled (or is otherwise unable
to support HTTP sessions).  The existing SMB session for the user won't be
picked up in these cases, because the "equals" method for NPA doesn't match if
the NPA represents the same user with different password hashes.

Or, he could just have a lot of users. ;)

I think the configurable limit is probably appropriate.  Another alternative
could be to make the SmbSession.logoff method public, and have a filter option
to drop the SMB session completely after authenticating (obviously only useful
if you're just using the filter for authentication).

Now that I'm thinking about it, either or both of these would be useful for
Davenport.  It doesn't store NPAs in the HTTP session (since each request could
potentially go to a different server); since each authenticated request gets
a new NPA (with different password hashes) I expect it is creating a new
smb session each time.  Limiting this would probably be a good thing (either
implicitly via the configurable limit, or doing an explicit SmbSession.logoff
at the completion of each request).

Eric



More information about the jcifs mailing list