Advantages are that no state is stored in the database and multiple logins
are possible, with simpler code.[2] You can invalidate all logins by changing
the secret key, but can't invalidate individual sessions.
But that would mean a logout on one client would log out all others, doesn't
On Fri, Sep 30, 2011 at 1:45 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
1. Store some random bytes in database per user. This string will be a
secret_key for HMAC.
...
4. To logout all sessions, go to step 1 (replace secret_key in database with
a new randomly generated one, thus
On Fri, Sep 30, 2011 at 4:02 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
I have attached a patch to sha.c with HMAC implementation, and
double-signing.
:-D
Basically, if zKey is a random secret string stored in the database, and
zRest is a concatenation of the values you want to
On Sep 30, 2011, at 16:15 , Stephan Beal wrote:
On Fri, Sep 30, 2011 at 4:02 PM, Dmitry Chestnykh dmi...@codingrobots.com
wrote:
I have attached a patch to sha.c with HMAC implementation, and double-signing.
:-D
Basically, if zKey is a random secret string stored in the database, and
On Fri, Sep 30, 2011 at 4:55 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
No. Maybe we should create a new branch for overhaul of cookie code to
allow multiple sessions?
i think that's a good idea - i'm not comfortable enough with the voodoo of
the login mechanism to make this change in
On Sep 30, 2011, at 17:58 , Stephan Beal wrote:
Multiple login sessions will require that some fields be migrated out of the
user table and into a new table. The anon user does not store the cookie data
in the user table (because it would log out all other anonymous users), using
only the
On Fri, Sep 30, 2011 at 6:01 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
On Sep 30, 2011, at 17:58 , Stephan Beal wrote:
I'm thinking about reusing the current cookie column for the per-user
secret key. But this will require careful handling of migrations to avoid
introducing security
On 15 Sep 2011, at 00:17, Stephan Beal wrote:
As Richard mentioned earlier, the current fossil login mechanism does not
tolerate a given user being logged in multiple times (each new login
invalidates the previous one). While this almost certainly isn't a real
limitation for the HTML
On Thu, Sep 15, 2011 at 6:19 AM, Altu Faltu altufa...@mail.com wrote:
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.
In principal it's simple, yes,
On Thu, Sep 15, 2011 at 8:50 AM, Ben Summers b...@fluffy.co.uk wrote:
For example, you could form the string
stephan:192.168.0
then sign it with the secret key, and get
stephan:192.168.0:38fa112673be4946702a74d1d0d1c0b6bd9f0162
That is in essence what Richard has done already. He
On Thu, Sep 15, 2011 at 10:22 AM, Stephan Beal sgb...@googlemail.comwrote:
Advantages are that no state is stored in the database and multiple logins
are possible, with simpler code.[2] You can invalidate all logins by
changing the secret key, but can't invalidate individual sessions.
But
Hi again,
As Richard mentioned earlier, the current fossil login mechanism does not
tolerate a given user being logged in multiple times (each new login
invalidates the previous one). While this almost certainly isn't a real
limitation for the HTML interface, it will eventually become one for the
At 04:17 PM 9/14/2011, Stephan Beal wrote:
Would this modification be acceptable in fossil? i know it's a
bit unconventional, but should be a fairly simple change to make
with no backwards compatibility concerns (because fossil doesn't
support multiple logins for one user right now).
Chiming in
On Thu, Sep 15, 2011 at 1:30 AM, Ross Berteig r...@cheshireeng.com wrote:
At 04:17 PM 9/14/2011, Stephan Beal wrote:
Would this modification be acceptable in fossil? i know it's a
bit unconventional, but should be a fairly simple change to make
with no backwards compatibility concerns
At 04:33 PM 9/14/2011, Stephan Beal wrote:
i think if we got rid of (gasp!) the IP check we could easily
implement this, but i can't just take that part out without a
blessing from the higher powers.
I found a thread that I started back in March of 2010 about this
from a user experience
On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig r...@cheshireeng.com 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
Ross Berteig:
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
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: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] same user, multiple
18 matches
Mail list logo
