On Thu, Sep 15, 2011 at 8:50 AM, Ben Summers <[email protected]> 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 uses the first 2 octets of the IP, though. The whole mechanism is quite clever, IMO (but i didn't write it!). As a cookie KEY he uses fossil-XXXX where XXXX is the project's code (or a "group code" for group logins), which means the key itself is tied to a specific repo (or group). The value's has uses the project code as part of the data, so the key/value are intimately tied together. To limit the validity of the tokens, include the time in the string being > signed, and check it's in an acceptable range. > For anonymous logins, the time is part of the cookie, but AFAICS the non-anonymous logins don't currently use a time element (except for the expiry time, but that's not actually part of the hash). > 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 it? (My proposal also has that limitation, but has the simpler 1-user=1-login entry record keeping.) > If you wanted to support logins from multiple locations in a browser which > is run in multiple networks, include the partial IP address in the cookie > name. > That's a nice idea. Currently the partial IP is used in generating/checking the hash, but it's not used in the cookie name itself. -- ----- 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
