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 interface, it will eventually become one for the JSON > interface. e.g. i might have one applet for polling a timeline and another > for polling tickets. That wouldn't work right now unless i force a re-login > from each client (and can avoid the inevitable login/poll race condition > between the two apps). > > In a recent project of mine i have the same limitation of one login per user > (because i don't want the db filling up with stale login state data) but i > allow multiple logins for one user by recycling the login auth token values > (analog to fossil's cookie value) if a user performs a login while a login is > already active. The login op then always returns the same auth token for the > given user/password until an explicit logout is performed (which clears the > user.cookie value) or fossil cleans up the cookie because it expired (i don't > know if it currently does any cookie cleaning but it does store the expiry > time in user.cexpire).
To solve this, you could use a different way of creating tokens with simple cryptographic signatures. You could concatenate the username and first 3 octets of the IP address, then sign it with a single secret key using an algorithm like HMAC-SHA1. [1] 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 To limit the validity of the tokens, include the time in the string being signed, and check it's in an acceptable range. 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. 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. Ben [1] https://secure.wikimedia.org/wikipedia/en/wiki/HMAC [2] Although there are some subtle things you have to be careful of, mainly timing attacks. Safe approach: when checking the signature, don't use strcmp(), hash both strings then strcmp() the hashes. -- http://bens.me.uk/ _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
