On Tue, Nov 22, 2011 at 10:42 PM, Jeremy Cowgar <jer...@cowgar.com> wrote:
> ...The “RSS Key”, if anyone greps the log for it, would grant them > access (until your password was changed) to view what has changed but not > any detail. Thus, it is much less of a security hazard. > Having a "read-only API key" of sorts sounds like an interesting idea. Since computer security is one of my weakest points, i'd be very interested in hearing some opinions on that idea from those more in-the-know on such matters. In regards to your JSON login problem, you may wish to implement something > similar. Give a remote api key. Let the user login with that key and their > password. This secures things a bit more and would make it easier to deal > with the SSO problem you are having. > The problem at the moment is that fossil's login model only supports one login record for each account, stored directly in the user table (except anonymous and other special internal accounts, which don't actually get a persistent login token). Fixing this for "normal" users would require either (A) recycling the auth token for each login (IMO not as bad as it initially sounds) or (B) storing one entry per login (which has the potential draw-back of unending growth in the login record table). Or perhaps (C), "something completely different." The JSON API doesn't actually implement its own login mechanism: instead it feeds the login info through fossil's normal authentication mechanism. When a JSON request includes an auth token (either in a cookie, a GET parameter, or part of the request envelope), it simply sends/verifies that through fossil's long-standing authentication internals. Because of that behaviour (and that behaviour is a hard requirement), it inherits the single-login-per-user limitation. -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
