> That was clearly a bug then - that 10 second timer is just for
> considering the lockfile to be stale in case it didn't get unlocked
> for some reason. But you've found the missing unlock call. :)

I would say, it was much more than 1 unlock call.

I rewrote the login procedure to keep track of 1single locking during a
full authentication session.

The rewrote also speed up things for the normal login, should be
noticeably even on slower machines.

> 
> > A) we have concurrent login based on ip.
> > B) we have kick concurrent login based on username
> >
> > 2 things which I think should be handled differently.
> >
> > *) if situation A) occurs, a situation which actually should never
> > happen but it does in this specific case it is safe to reuse the old
> > session instead of starting a new one right?
> 
> Yeah, I'd say so. The problem doesn't occur with user/pass
> authentication because there, the portal page may be requested
> multiple times but the user will only log in once. Safe to say that
> if a user that is already logged in tries to log in again *from the
> same IP address*, then we can ignore that attempt.
> 
> > *) if situation B) occurs, a situation which is possibly allowed
> > depending on the configuration we only should disconnect the old
> > session in the following case:
> > 	1) username is the same AND clientip isn't!
> > 	If username and clientip is the same, this should already been
> > caught by A)
> 
> Yes, sounds good.

Implemented it in current SVN and cleaned another part of the code.

I already can see where I'm going through with the current code :)

J.