[ previous ] [ next ] [ threads ]
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  Jonathan De Graeve <Jonathan dot De dot Graeve at imelda dot be>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: The effect of kick concurrent logins, radius_mac and multiple http sessions
 Date:  Fri, 21 Apr 2006 21:07:05 +0200
On 20.04.06 11:53 +0200, Jonathan De Graeve wrote:

> Before commiting the current fixes to svn, ALL login sessions where
> locked for 10 seconds due to the way the locking mechanism worked
> so the browser seemed to 'hang'. The changes to SVN fixes the

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. :)

> 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.

- Manuel