With the method suggested at below link, I see a problem that if I logout from one machine my auth token for other machine will also be invalidated.
It would be simple to have one auth token for each login and purge stale auth tokens regularly. Purging stale tokens should be a matter of few SQLs for the current backend of fossil, sqlite. Then, we can enable multiple logins and also keep the current IP check as it is. - Altu ----- Original Message ----- From: Stephan Beal Sent: 09/15/11 06:33 AM To: [email protected] Subject: Re: [fossil-users] same user, multiple logins: the problem and a potential solution On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig < [email protected] > wrote: ... from a user experience point of view. The thread stalled out after a patch was offered by Kyle McKay[1] that would have dropped the use of the IP adderss in the session cookie hash, allowing the same session cookie to be used from any IP address until the session was explicitly logged out. That would be my proposal as well. Under that model, to prevent _others_ from logging you out, the logout requires that you give it the auth token you were given by login. Since the tokens would be recycled, if you lose your cookie/hash you can re-fetch it by performing a login, which you can then use to logout and invalidate the hash. The overall model is described here: http://whiki.wanderinghorse.net/?page=WhikiAuthentication (mentally substitute "auth token" for "fossil cookie" and the idea is the same) It appears that DRH was ahead of the curve in making sessions unique to a specific IP, the issue with all the major sites that is exploited by session sniffing apps such as the infamous firesheep plugin. Computer security is one area i know absolutely nothing about, so i'll defer to anyone's judgement on such topics. I should be possible to support more than one session cookie per user, but then you would need a process to occasionally purge stale sessions from the server. You could do that check on any session validation, if its been long enough since the last check. Or at least check a few sessions on each validation if that is expensive to do en masse. Given the scope of even the largest fossil repos (by far under 100 users?), cleanup would be fast, and could probably be performed before every login request... doh... one could argue that cleaning up the logins should require admin access... -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
