[jcifs] Method logonLogoff() in class SmbSession

[Michael B. Allen]

On Fri, 10 Jan 2003 17:08:54 +0100
marc.lehmann at infineon.com wrote:

> Dear All,
> wouldn't it be useful to include
> 
>     public static void logonLogoff( UniAddress dc,
> NtlmPasswordAuthentication auth ) throws SmbException
>     {
>         SmbSession session = SmbTransport.getSmbTransport( dc, 0
> ).getSmbSession( auth );
>         session.getSmbTree( "IPC$", null ).treeConnect( null, null );
>         session.logoff( false );
>         session = null;
>     }
> 
> in class SmbSession?
> 
> For security reasons I wouldn't want to keep a SMB session longer than
> neccesary. Using the method logon() consecutive logon attempts always
> evaluate to OK (no exception raised) even with wrong credentials. (I just
> use NtlmHttpFilter for authentication und don't need to access any SMB
> resources.)

Yes, sessions are cached for performance reasons. If you had many
users logging on and off with each request things would get slow. It's
noticeably slower to authenticate with each HTTP request with only 1
user. So SmbSession objects are cached for jcifs.smb.client.soTimeout keyed
by domain\user hashes. Using the same credentials with a different password
will not query the server if it is less than the soTimeout period. I
do not suggest logging out immediately after logging in but you might
reduce the soTimeout period to something small. Take care however, if it
is too small (e.g. < 1sec) it might break the client. I don't know. You
would have to experiment. Right now it's set to 300000 (5 minutes). You could
safely change it to 30 seconds.

Note: I do not actually use NtlmHttpFilter so what I'm saying may not be
100% accurate. Please verify on your own. Also there may be a genuine
problem that is closely related to this -- as long as the SmbTransport
doesn't timeout the SmbSessions will be cached. So the soTimeout period
applies to *all* users utilizing the same domain controller. Meaning, if
user A logs in and 3 seconds before the soTimeout runs out user B logs
in, user A will be cached for at least another soTimeout period. So if
you have a *really* busy site a users session might persist indefinately
(even if they close their browser and open it again). That's a bug but
I'm not sure how to deal with it just yet. I don't want to pollute the
transport layer with stuff specific to NTLM HTTP authentication.

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.