On Wed, Sep 14, 2011 at 12:27 PM, Stephan Beal <[email protected]>wrote:
> Hello, anyone who's intimate with fossil's authentication code... > > i've decided not to punt the authentication problem (now moving it to the > start of the TODO list) because authentication levels end up changing the > output generated by some requests (e.g. whether or not links are generated > from commit message contents) and i need to account for that early on. > > What i need to be able to do is (in no particular order): > > a) If a login request comes from JSON, ignore the authentication cookie (if > any) and funnel the login data sent in the JSON request through to the > current login mechanism. When it's done, i need to pass the generated cookie > (i call it "the auth token") back to the requester (in the JSON response > payload) so that he can include it in future requests which require > non-guest access. It is up to the client to remember his auth token and > include it with each request (this is easy to encapsulate in client-side > APIs). > Three are multiple authentication modes. When running as CGI, if the REMOTE_USER environment variable is set, then the interaction is deemed to be from the named user. The idea is that the web server should have handled the authentication for us and set the REMOTE_USER environment variable correctly, and Fossil trusts the web server. Otherwise, most requests look for a cookie of the form "fossil-XXXXXXXXXXXXX" where XXX is replaced by either the group-code or the project-code. The value of the cookie needs to be of a particular form which is different depending on whether the login is as "anonymous" or as a normal named user. For anonymous users, the cookie contains (among other things) a hash of the remote IP address as a defense against cookie stealing. For named users, the IP address and a random code is stored in the USER table and the random code is contained in the cookie. Hence, the same user cannot be logged in from two or more machines at the same time. The push/pull/sync protocol has its own separate authentication mechanism. I'm thinking you don't need to change or enhance any of this for JSON. Rather, just have the JSON client receive and interpret SET-COOKIE headers in the HTTP reply, and reply with corresponding COOKIE headers in subsequent requests. You might want the equivalent of a /login screen that returns JSON rather than HTML, but other than that, I don't think you need to add anything on the server side. > > b) For non-login JSON requests, first check the request info (GET/POST) for > an authorization token. If found, i need to be able to tell fossil, "here's > your cookie - use this one." i.e. i need to be able to make fossil think it > got a cookie from the HTTP header, though i'm really feeding it the cookie > from JSON. > > d) If no auth token is set in the request, check for it in the HTTP cookies > (i.e. do what fossil does currently). > > e) the various auth functions like login_check_credentials() need to work > as before (with the exception that they will produce JSON output on errors). > Though i might need to touch their internals in order to connect the > JSON/cookie world views, i would prefer to be able to hook in to it at a > deeper level (i.e. when the cookie is initially processed and where it is > ultimately evaluated). > > Can someone suggest where i should hook into fossil's cookie mechanism? The > main goal here is to touch as little existing code as possible. > > PS: i have NO idea if what i'm doing here will work as proposed with > fossil's "group login" functionality, and i haven't ever personally used > those features so i don't know off hand what would be required to support > them. > > -- > ----- 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 > > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
