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). 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
