On Wed, Sep 14, 2011 at 10:51 PM, Joshua Paine <[email protected]>wrote:
> FTR, I'm not suggesting changing fossil's web ui, just suggesting the > HTTP Basic Auth would be the easiest thing for clients of a JSON API. > i'm working on all that right this moment, as a matter of fact. > Seems like this unfortunately means that the JSON API can't be designed so > that a single auth method works for most fossil installs. > i'm piggybacking on fossil's method insofar as possible, and the goal is for them to transparently work together. i won't be (intentionally) breaking any of fossil's current login-related conventions, in any case. > Though if the JSON parts also trust the REMOTE_USER (when it's set), then > one could pretty easily have the client follow whatever login procedure and > *also* send the HTTP AUTH info with all requests, and that should at least > make it possible to write a fossil JSON client without knowing which way a > given repo swings. > That's the goal, but i'm still a ways away from adding the REMOTE_USER handling. That said... if i'm understanding the code correctly, i won't have to do anything for that - it should "just work" after i call login_check_credentials() (which happens as part of the JSON init phase when running in CGI mode). Interestingly, if i try to handle auth in CLI mode i run into a chicken/egg scenario where i need to call login_cookie_name() but the repo hasn't been opened yet (so login_cookie_name() can't work). However - auth is not used in CLI mode, so i've got no problem there (i just skip JSON auth setup if we're not in CGI mode). -- ----- 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
