Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 12:27 PM, Stephan Beal sgb...@googlemail.com wrote: 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). Are you proposing supporting non-HTTP transport of JSON client-server interaction? If not, why would the auth token be put in the JSON payloead rather than in the HTTP headers? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 7:15 PM, Ron Wilson ronw.m...@gmail.com wrote: Are you proposing supporting non-HTTP transport of JSON client-server interaction? No, but for supporting clients which don't have cookies support. e.g. i've written Java HTTP client apps (using a similar API to this one, actually) but the client code doesn't support cookies, so it has to pass around its authentication in the JSON request. Cookies are, for purposes of the JSON API, the fallback and not the default. -- - 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
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 7:24 PM, Stephan Beal sgb...@googlemail.com wrote: No, but for supporting clients which don't have cookies support. e.g. i've written Java HTTP client apps (using a similar API to this one, actually) but the client code doesn't support cookies, so it has to pass around its authentication in the JSON request. Cookies are, for purposes of the JSON API, the fallback and not the default. BTW: many SOAP interfaces do this as well. When logging in you get a token (which fossil stores as a cookie), and that token has to be included in requests which require non-guest access. -- - 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
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 12:27 PM, Stephan Beal sgb...@googlemail.comwrote: 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-X 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 7:36 PM, Richard Hipp d...@sqlite.org wrote: I'm thinking you don't need to change or enhance any of this for JSON. Thank you for the very detailed response. It sounds like i'll have to touch less code than i was expecting, but i think the one place i need to change would be a way to tell fossil to use my own string as the auth cookie, as opposed to (or overriding) the HTTP cookie. Is there already an internal function to which i could pass, e.g. fossil-ABCDEF=xx, and have it interpret that as the cookie? i think that's basically the functionality i need. -- - 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
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 1:42 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Sep 14, 2011 at 7:36 PM, Richard Hipp d...@sqlite.org wrote: I'm thinking you don't need to change or enhance any of this for JSON. Thank you for the very detailed response. It sounds like i'll have to touch less code than i was expecting, but i think the one place i need to change would be a way to tell fossil to use my own string as the auth cookie, as opposed to (or overriding) the HTTP cookie. Is there already an internal function to which i could pass, e.g. fossil-ABCDEF=xx, and have it interpret that as the cookie? i think that's basically the functionality i need. cgi_set_parameter(fossil-ABCDEF, xx); -- - 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 -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 8:05 PM, Richard Hipp d...@sqlite.org wrote: cgi_set_parameter(fossil-ABCDEF, xx); Great :). i now see cgi_replace_parameter(), which is what i really want (because the JSON auth info will be processed after fossil has done its cookie cutting). Thanks! -- - 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
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 2:20 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Sep 14, 2011 at 8:05 PM, Richard Hipp d...@sqlite.org wrote: cgi_set_parameter(fossil-ABCDEF, xx); Great :). i now see cgi_replace_parameter(), which is what i really want (because the JSON auth info will be processed after fossil has done its cookie cutting). To clarify, Fossil uses a single namespace to hold all environment variables, cookies, query parameters, and POST parameters. All of things are name/value pairs, and they all go into a common look-up table. So there is no way in Fossil to ask for the value of a cookie, for example. You have to ask for the value associated with a name, where that name/value might be any of a an environment variable, cookie, query parameter or POST parameter. They all work the same. Note however, that query parameters, POST parameters, and cookies always use lower-case names and environment variables use upper-case names. So there is no way to generate a rogue request that overrides an environment variable using a query parameter, for example. In other words, you cannot do: http://www.fossil-scm.org/fossil/xfer?REMOTE_USER=drh ... hoping to subvert the login mechanism and push content under my name. But you can interchange cookies, query parameters, and POST parameters, and Fossil won't notice. Thanks! -- - 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 -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 8:30 PM, Richard Hipp d...@sqlite.org wrote: To clarify, Fossil uses a single namespace to hold all environment variables, ...parameter. They all work the same. That's a bonus for me, actually. i'm currently digging around in login_check_credentials() and friends to figure out where this belongs. login_check_credentials() is rather complex due to the handling of various login sources and the anonymous user (i foresee a problem on my side in handling the captcha seed - i will probably need an extra request which fetches this seed). Note however, that query parameters, POST parameters, and cookies always use lower-case names and environment variables use upper-case names. So That's good to know. there is no way to generate a rogue request that overrides an environment variable using a query parameter, for example. In other words, you cannot do: http://www.fossil-scm.org/fossil/xfer?REMOTE_USER=drh ... hoping to subvert the login mechanism and push content under my name. Oh, you know i wouldn't think of trying that! ;) But you can interchange cookies, query parameters, and POST parameters, and Fossil won't notice. Great - that's part of what i need to do, e.g. to allow certain request options to either be set via GET params or POST request properties. Anyway... i think i've been pointed in the right direction, now i just need to go get it working. Thanks again for the help, -- - 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
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On 14 Sep 2011, at 18:26, Stephan Beal wrote: On Wed, Sep 14, 2011 at 7:24 PM, Stephan Beal sgb...@googlemail.com wrote: No, but for supporting clients which don't have cookies support. e.g. i've written Java HTTP client apps (using a similar API to this one, actually) but the client code doesn't support cookies, so it has to pass around its authentication in the JSON request. Cookies are, for purposes of the JSON API, the fallback and not the default. BTW: many SOAP interfaces do this as well. When logging in you get a token (which fossil stores as a cookie), and that token has to be included in requests which require non-guest access. HTTP basic authentication is widely supported in HTTP client libraries, and much less hassle to use than passing tokens around. Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On 9/14/2011 4:22 PM, Ben Summers wrote: HTTP basic authentication is widely supported in HTTP client libraries, and much less hassle to use than passing tokens around. The three major downsides with HTTP Basic Auth are: 1) No pretty login page 2) No reliable way to logout in most browsers 3) Requires sending the username and password over the wire 1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends the username and password in the clear over the wire unless you're using HTTPS, so this is no greater risk, and it inherits the protection that an HTTPS setup provides. I vote for HTTP Basic Auth, provided that someone can confirm the major browser AJAX functions support it. (Curl and other libs certainly support it.) -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 10:22 PM, Ben Summers b...@fluffy.co.uk wrote:
HTTP basic authentication is widely supported in HTTP client libraries, and
much less hassle to use than passing tokens around.
Supporting that is certainly on the list of things to do.
i'm currently still ironing out how to internally manage the login/auth
data. i _think_ i have it set up more or less correctly now (as of about 3
minutes ago), but i still need to write a another function or two before i
can actually test a login made over json. The good news is that a
/json/login request at least does _something_:
{
fossil: 74273decba0a4db0b86d4769d4f5f2c923c35773,
timestamp: 1316028489,
resultCode: FOSSIL-1008,
resultText: Not yet implemented.
}
;)
--
- 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
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 4:30 PM, Joshua Paine jos...@letterblock.comwrote: On 9/14/2011 4:22 PM, Ben Summers wrote: HTTP basic authentication is widely supported in HTTP client libraries, and much less hassle to use than passing tokens around. The three major downsides with HTTP Basic Auth are: 1) No pretty login page 2) No reliable way to logout in most browsers 3) Requires sending the username and password over the wire 1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends the username and password in the clear over the wire unless you're using HTTPS, so this is no greater risk, and it inherits the protection that an HTTPS setup provides. I vote for HTTP Basic Auth, provided that someone can confirm the major browser AJAX functions support it. Note that Basic Auth is normally handled by the web server, not the client application. The web server checks the credentials and then sets the REMOTE_USER environment variable. Fossil honors the REMOTE_USER environment variable in CGI mode, so you can use Fossil with Basic Auth. But, it comes with all the downsides listed above, plus it means that the Admin/User page will no longer work for setting and changing passwords since the passwords are now stored in the web server, not in Fossil. One other thing: I don't think Basic Auth allows anything equivalent to the current nobody user or the anonymous user. If you don't have a valid login and password you cannot see anything at all. That would be downside #5, if I'm counting right (Curl and other libs certainly support it.) -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On 14 Sep 2011, at 21:36, Richard Hipp wrote: On Wed, Sep 14, 2011 at 4:30 PM, Joshua Paine jos...@letterblock.com wrote: On 9/14/2011 4:22 PM, Ben Summers wrote: HTTP basic authentication is widely supported in HTTP client libraries, and much less hassle to use than passing tokens around. The three major downsides with HTTP Basic Auth are: 1) No pretty login page 2) No reliable way to logout in most browsers 3) Requires sending the username and password over the wire 1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends the username and password in the clear over the wire unless you're using HTTPS, so this is no greater risk, and it inherits the protection that an HTTPS setup provides. I vote for HTTP Basic Auth, provided that someone can confirm the major browser AJAX functions support it. Note that Basic Auth is normally handled by the web server, not the client application. The web server checks the credentials and then sets the REMOTE_USER environment variable. Fossil honors the REMOTE_USER environment variable in CGI mode, so you can use Fossil with Basic Auth. But, it comes with all the downsides listed above, plus it means that the Admin/User page will no longer work for setting and changing passwords since the passwords are now stored in the web server, not in Fossil. I believe that if you don't ask the web server to handle it, it'll just pass on the raw headers to the CGI script. Apache certainly works that way with proxying. One other thing: I don't think Basic Auth allows anything equivalent to the current nobody user or the anonymous user. If you don't have a valid login and password you cannot see anything at all. That would be downside #5, if I'm counting right It's probably best implemented without enforcing the use of basic auth. So if the headers aren't present, don't return a 401, just do everything as now. You then get the best of both worlds, tokens or cookies and the option to use basic auth when it's the easiest mechanism available. Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 10:51 PM, Joshua Paine jos...@letterblock.comwrote: 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON authentication: meshing with the cookie mechanism
On Wed, Sep 14, 2011 at 10:51 PM, Joshua Paine jos...@letterblock.comwrote: FTR, I'm not suggesting changing fossil's web ui, just suggesting the A related point: once the JSON login is working we could actually run the login from the UI in AJAX mode, as opposed to a separate request. We should be able to incrementally convert features from static mode to client-side JavaScript. Assuming that would even be desired. (But i'm getting ahead of myself... we need to crawl before we can walk, and all that.) -- - 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
