[fossil-users] JSON API and WSDL
Hi, all, It would be cool if the JSON API had a way to serve a WSDL of its API. i'm looking to pick someone's brain about WSDL, namely regarding: a) Is WSDL intended only for SOAP (in which case it is not interesting here)? b) Does anyone know of a JSON-format WSDL-like language? What i'd like to eventually have is: http://my.fossil-server.org/json/ which would fetch the WSDL[-like] description of the API, which the client could then use to automatically generate an object-oriented implementation class. e.g. PHP can use a WSDL to generate (at runtime) classes which reflect arbitrary SOAP interfaces. :-? -- - 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 API and WSDL
On 09/14/11 11:21, Stephan Beal wrote: Hi, all, It would be cool if the JSON API had a way to serve a WSDL of its API. i'm looking to pick someone's brain about WSDL, namely regarding: a) Is WSDL intended only for SOAP (in which case it is not interesting here)? See section 4 [1] of the WSDL spec [2]. Short: there do exist http get/post bindings for WSDL; there is support for mimetypes, and thus application/json application/x-javascript text/javascript text/x-javascript (take your pick or use something completely different ;)) [1] http://www.w3.org/TR/wsdl#_http [2] http://www.w3.org/TR/wsdl -Martin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil tutorial - Oct 25 in Manassas VA
I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk conference. See http://www.tcl.tk/community/tcl2011/schedule.html for schedule and registration information. In addition to usual high-level information about the history and usage of DVCSes in general and Fossil in particular, I plan to go into detail about the internal data structures, code organization, and file format for Fossil, with the idea of equipping users with behind-the-scenes information that will help them to make more effective use of Fossil, and to better understand why Fossil behaves the way it does. -- 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 API and WSDL
On Wed, Sep 14, 2011 at 5:40 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Sep 14, 2011 at 5:31 PM, Martin S. Weber martin.we...@nist.govwrote: [1] http://www.w3.org/TR/wsdl#_**http http://www.w3.org/TR/wsdl#_http [2] http://www.w3.org/TR/wsdl Thank you very much :). i'll go get myself more informed on the topic... If i'm understanding correctly, WSDL requires that parameters passed to the server be form-urlencoded. That's not fundamentally a problem, but there is a current conflict of interest regarding who (fossil's core or the JSON bits) gets to parse the POST data (which we can only do once unless we buffer it into a Blob first). The current heuristics are: a) If the Content-Type of the request is application/json or text/plain then the json/cgi bits try to parse it as JSON. This makes it unavailable to fossil, as the json/cgi init bits must be run before fossil initializes its side of the CGI environment (because parts of the fossil internals - namely error reporting - now account for JSON mode and output a JSON error object). b) if the Content-Type is form-urlencoded or one of the fossil-specific types then fossil gets to process it. c) If we don't know the Content-Type then we ignore (neither consume nor parse) the POST data. This works so far, but will fail once we allow the JSON API to read form-urlencoded data (which it has code to do but it currently does do so not because that would interfere with (=completely break) ALL of fossil's POSTed form handling). In order to resolve this conflict of interests i need to add some code to the json/cgi bits (an external/independent library) to allow delayed reading of the POST data (it is currently done automatically at lib-init time, which ends up preempting fossil), so that the fossil code can properly decide who to feed the POST data to. Anyway... that's certainly more than anyone really wanted to know. -- - 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] Fossil tutorial - Oct 25 in Manassas VA
On Wed, Sep 14, 2011 at 5:42 PM, Richard Hipp d...@sqlite.org wrote: I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk conference. Will there be a video of it online afterwards? :) -- - 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] Fossil tutorial - Oct 25 in Manassas VA
Any discount codes for fossil user group members? Manassas is convenient for me, so I would consider going just for your talk. Thanks, Wes ___ 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 API and WSDL
On Wed, Sep 14, 2011 at 5:31 PM, Martin S. Weber martin.we...@nist.govwrote: [1] http://www.w3.org/TR/wsdl#_**http http://www.w3.org/TR/wsdl#_http [2] http://www.w3.org/TR/wsdl To follow up: http://tools.ietf.org/html/draft-zyp-json-schema-03 looks interesting (but i need to finish reading it). And WSDL 2.0 apparently accounts for non-XML representations: http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/ They mention JSON as an alternative, but it's not yet clear to me whether there actually is an example of a JSON variant out there and whether or not it could be used for this purpose. -- - 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] Fossil tutorial - Oct 25 in Manassas VA
On Wed, Sep 14, 2011 at 11:57 AM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Sep 14, 2011 at 5:42 PM, Richard Hipp d...@sqlite.org wrote: I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk conference. Will there be a video of it online afterwards? :) I checked with the conference organizers and they tell me no. The tutorials are how they defray the fixed costs of putting on the conference in the first place. And that makes sense. I also asked about Wes's question of a discount. They pointed out to me that you can register for just this one tutorial and not the technical sessions. But, again, the tutorial fees are how they pay for the room, so no discounts. -- - 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] Fossil tutorial - Oct 25 in Manassas VA
On Wed, Sep 14, 2011 at 6:19 PM, Richard Hipp d...@sqlite.org wrote: I checked with the conference organizers and they tell me no. The tutorials are how they defray the fixed costs of putting on the conference in the first place. And that makes sense. Fair enough. Could we convince you to accidentally leave your webcam turned on during the presentation (and conveniently point it as the screen)? ;) -- - 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] Fossil tutorial - Oct 25 in Manassas VA
On Wed, Sep 14, 2011 at 6:28 PM, Stephan Beal sgb...@googlemail.com wrote: Fair enough. Could we convince you to accidentally leave your webcam turned on during the presentation (and conveniently point it as the screen)? ;) Or do they have an option to buy a copy online? That'd be win-win for them, i'd think. -- - 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] Fossil tutorial - Oct 25 in Manassas VA
On Sep 14, 2011, at 6:28 PM, Stephan Beal wrote: Fair enough. Could we convince you to accidentally leave your webcam turned on during the presentation (and conveniently point it as the screen)? ;) Isn't it easier and more responsible to just record a rehearsal? Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] proposed cleanup to g.okXXX code?
Hi, all,
i'm wondering if anyone would be against me making the following change to
the 'g' object:
Extend its structure to include:
struct FossilPermissions {
char setup;
char admin;
... repeat for all current g.okXXX bits ...
} perm;
Remove all of the g.okXXX members, replacing their uses with g.perm.XXX.
One advantage (though very minor) would be future-proofing code
like login_as_user() against the addition of future permissions (which must
currently be explicitly set there, whereas the above replaces all that with
a simple memset()).
???
--
- 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] proposed cleanup to g.okXXX code?
On Wed, Sep 14, 2011 at 12:52 PM, Stephan Beal sgb...@googlemail.comwrote:
Hi, all,
i'm wondering if anyone would be against me making the following change to
the 'g' object:
Extend its structure to include:
struct FossilPermissions {
char setup;
char admin;
... repeat for all current g.okXXX bits ...
} perm;
I think this is a great idea.
Remove all of the g.okXXX members, replacing their uses with g.perm.XXX.
One advantage (though very minor) would be future-proofing code
like login_as_user() against the addition of future permissions (which must
currently be explicitly set there, whereas the above replaces all that with
a simple memset()).
???
--
- 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 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] proposed cleanup to g.okXXX code?
On Wed, Sep 14, 2011 at 1:22 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Sep 14, 2011 at 6:57 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Sep 14, 2011 at 12:52 PM, Stephan Beal sgb...@googlemail.comwrote:
...struct FossilPermissions {
char setup;
char admin;
... repeat for all current g.okXXX bits ...
} perm;
I think this is a great idea.
i've got this ready to commit. Would you prefer a branch for review or
directly to the trunk? The impl was a global search/replace with one
exception made for g.okCsrf (which i left where it is because i have no clue
what it is). Seems to work, e.g. anonymous user can't edit a checkin but
my account can.
Branch, please
--
- 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] proposed cleanup to g.okXXX code?
On Wed, Sep 14, 2011 at 7:36 PM, Richard Hipp d...@sqlite.org wrote: Branch, please http://fossil-scm.org/index.html/timeline?r=stephan-hack It touches a lot of files but the changes are minimal. Note that g.okRead translates to g.perm.Read as opposed to g.perm.read because... it was easiest to automate that way. If you'd prefer lower-cased first letters i can do 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
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] fossil update FAIL
Ok, Didn't realize there was a disconnected Leaf in the remote repo. c:\myrepo fossil merge 88d803c051 worked. We still are unsure what created the disconnect? Though we seem to have hiccups when upgrading the fossil.exe and doing rebuilds on both local and remote repos. On Tue, Aug 30, 2011 at 7:10 PM, sky5w...@gmail.com wrote: Hi, I ran into a snag today after a week away on vacation. This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC I performed a pull. c:\myrepo fossil pull t:\myrepo\myrepo1.fossil ...lots of changes came down the network... Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Received: 2056 45 0 0 Sent: 1023 20 0 0 Received: 11346 64 0 19 Total network traffic: 957 bytes sent, 6805 bytes received I then ran an update. c:\myrepo fossil update ...nothing happened. no report? ...But I assumed my checkout contained the latest changes. ...So I began to edit my code and noticed none of the changes were there. Question: What should I do in this case? I eventually got things aligned with 2 cycles of close/open. Not sure why? I ran a close. c:\myrepo fossil close I ran an open. c:\myrepo fossil open myrepo.fossil ...Still no update of my folder contents! Repeat worked. Maybe if I automated this via a script, I would have stopped immediately after receiving no report on the update? Thanks for your help. ___ 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
[fossil-users] JSON login demo: is this interface acceptable?
Hi, all!
Just implemented...
Request:
GET: /json/login?n=namep=pass
Param names n and p are for compatibility with the current usage, and
may optionally be written out as name and password.
or POST: /json/login
POST request body: { payload:{name:..., password:...} }
(POSTed login data doesn't land in the apache logs, so it's highly
preferred!)
Response:
{
fossil:ff6485c5c8a81716dc9d8a70e4eff3db623f5d54,
timestamp:1316035948,
payload:BCB43F00AF73F290571512747DDFC8B3358C47836B4CFA56D9/CE59BB9F186226D8/stephan
}
The response payload is the value of the fossil cookie, which also gets set:
Set-Cookie:fossil-CE59BB9F186226D8=BCB43F00AF73F290571512747DDFC8B3358C47836B4CFA56D9%2FCE59BB9F186226D8%2Fstephan;
Path=/cgi-bin/fossil.cgi; expires=Fri, 14 Sep 2012 04:32:28 GMT; HttpOnly;
Version=1
i might change the payload to also include the cookie name (fossil-CE5... in
the example above), but i don't yet know if i need it at this level.
i haven't yet done anonymous user support (that requires special handling
because of the random password). Nor have i yet thoroughly tested THIS
support (it's literally under 10 minutes old). Seems to work.
--
- 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
[fossil-users] RFC: new config option name
Hiya! The JSON API returns errors in the form of 4-digit error codes, as described here: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?hl=en_US The codes are grouped such that we can dumb down error codes to be less specific (w/ 3 levels of specificity), for the sake of not revealing potentially security-relevant codes to clients. The dumbing-down support is implemented but currently uses a hard-coded dumb-down level (called g.json.errorDetailParanoia) which i would like to switch to a configuration option. But what to call it? json-paranoia-level? json-error-dumbdown-level? something complete different? -- - 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
[fossil-users] same user, multiple logins: the problem and a potential solution
Hi again, As Richard mentioned earlier, the current fossil login mechanism does not tolerate a given user being logged in multiple times (each new login invalidates the previous one). While this almost certainly isn't a real limitation for the HTML interface, it will eventually become one for the JSON interface. e.g. i might have one applet for polling a timeline and another for polling tickets. That wouldn't work right now unless i force a re-login from each client (and can avoid the inevitable login/poll race condition between the two apps). In a recent project of mine i have the same limitation of one login per user (because i don't want the db filling up with stale login state data) but i allow multiple logins for one user by recycling the login auth token values (analog to fossil's cookie value) if a user performs a login while a login is already active. The login op then always returns the same auth token for the given user/password until an explicit logout is performed (which clears the user.cookie value) or fossil cleans up the cookie because it expired (i don't know if it currently does any cookie cleaning but it does store the expiry time in user.cexpire). Would this modification be acceptable in fossil? i know it's a bit unconventional, but should be a fairly simple change to make with no backwards compatibility concerns (because fossil doesn't support multiple logins for one user right now). :-? -- - 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] same user, multiple logins: the problem and a potential solution
At 04:17 PM 9/14/2011, Stephan Beal wrote: Would this modification be acceptable in fossil? i know it's a bit unconventional, but should be a fairly simple change to make with no backwards compatibility concerns (because fossil doesn't support multiple logins for one user right now). Chiming in from an end user perspective, I personally find it annoying that fossil does not allow multiple logins for a single user. I work from both home and office, and having a logged in session at the office go poof just because I wanted to update a ticket from home is a minor annoyance that I accept, but would love to see eliminated. I've toyed with the obvious work-around of creating a second user to log in from home, but that just feels wrong. None of the major user web applications I use regularly (GMail and the Google family, FB, StackOverflow, Flickr) log me out from one computer just because I touched them from my Android phone or from another computer. Again, I'm writing this as a user, paying no attention to how difficult this would be to address under the hood. Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ 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] same user, multiple logins: the problem and a potential solution
On Thu, Sep 15, 2011 at 1:30 AM, Ross Berteig r...@cheshireeng.com wrote: At 04:17 PM 9/14/2011, Stephan Beal wrote: Would this modification be acceptable in fossil? i know it's a bit unconventional, but should be a fairly simple change to make with no backwards compatibility concerns (because fossil doesn't support multiple logins for one user right now). i just this moment realized this change can't work as-is with fossil because fossil uses the first part of the IP address in calculating the auth token (and stores that IP prefix in the db). So my proposal would break the moment you have a login from your mobile phone and your PC simultaneously. Chiming in from an end user perspective, I personally find it annoying that fossil does not allow multiple logins for a single ...love to see eliminated. I've toyed with the obvious work-around of creating a second user to log in from home, but that just feels wrong. i agree. None of the major user web applications I use regularly (GMail and the Google family, FB, StackOverflow, Flickr) log me out from one computer just because I touched them from my Android phone or from another computer. i believe (theorize) the reason for this limitation is to avoid cluttering the db with an arbitrary number of stale login sessions. At least that's the reason i implemented that way in my own app. But my app's approach doesn't use the IP checking which fossil does, so i didn't have the problem described above. Again, I'm writing this as a user, paying no attention to how difficult this would be to address under the hood. i think if we got rid of (gasp!) the IP check we could easily implement this, but i can't just take that part out without a blessing from the higher powers. -- - 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] same user, multiple logins: the problem and a potential solution
At 04:33 PM 9/14/2011, Stephan Beal wrote: i think if we got rid of (gasp!) the IP check we could easily implement this, but i can't just take that part out without a blessing from the higher powers. I found a thread that I started back in March of 2010 about this from a user experience point of view. The thread stalled out after a patch was offered by Kyle McKay[1] that would have dropped the use of the IP adderss in the session cookie hash, allowing the same session cookie to be used from any IP address until the session was explicitly logged out. [1]: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01621.html It appears that DRH was ahead of the curve in making sessions unique to a specific IP, the issue with all the major sites that is exploited by session sniffing apps such as the infamous firesheep plugin. I should be possible to support more than one session cookie per user, but then you would need a process to occasionally purge stale sessions from the server. You could do that check on any session validation, if its been long enough since the last check. Or at least check a few sessions on each validation if that is expensive to do en masse. Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ 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] same user, multiple logins: the problem and a potential solution
On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig r...@cheshireeng.com wrote: ... from a user experience point of view. The thread stalled out after a patch was offered by Kyle McKay[1] that would have dropped the use of the IP adderss in the session cookie hash, allowing the same session cookie to be used from any IP address until the session was explicitly logged out. That would be my proposal as well. Under that model, to prevent _others_ from logging you out, the logout requires that you give it the auth token you were given by login. Since the tokens would be recycled, if you lose your cookie/hash you can re-fetch it by performing a login, which you can then use to logout and invalidate the hash. The overall model is described here: http://whiki.wanderinghorse.net/?page=WhikiAuthentication (mentally substitute auth token for fossil cookie and the idea is the same) It appears that DRH was ahead of the curve in making sessions unique to a specific IP, the issue with all the major sites that is exploited by session sniffing apps such as the infamous firesheep plugin. Computer security is one area i know absolutely nothing about, so i'll defer to anyone's judgement on such topics. I should be possible to support more than one session cookie per user, but then you would need a process to occasionally purge stale sessions from the server. You could do that check on any session validation, if its been long enough since the last check. Or at least check a few sessions on each validation if that is expensive to do en masse. Given the scope of even the largest fossil repos (by far under 100 users?), cleanup would be fast, and could probably be performed before every login request... doh... one could argue that cleaning up the logins should require admin 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] same user, multiple logins: the problem and a potential solution
Ross Berteig: I should be possible to support more than one session cookie per user, but then you would need a process to occasionally purge stale sessions from the server. You could do that check on any session validation, if its been long enough since the last check. Or at least check a few sessions on each validation if that is expensive to do en masse. Yeah I was thinking the same thing. If you don't want it to become unbounded, add a configuration parameter to determine how many parallel sessions any given user can have with a sane default (possibly even 1, thus not changing the current behavior). I doubt (without measurements, which, of course, always is dangerous) that it would become expensive to do this (at least in comparison to all the other operations fossil is doing on the DB!), and I also, speaking as a user now, would enjoy having multiple log-ins available. That being said, I think the part where the IP is being woven into the hash should stay. Regards, -Martin ___ 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] same user, multiple logins: the problem and a potential solution
With the method suggested at below link, I see a problem that if I logout from one machine my auth token for other machine will also be invalidated. It would be simple to have one auth token for each login and purge stale auth tokens regularly. Purging stale tokens should be a matter of few SQLs for the current backend of fossil, sqlite. Then, we can enable multiple logins and also keep the current IP check as it is. - Altu - Original Message - From: Stephan Beal Sent: 09/15/11 06:33 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] same user, multiple logins: the problem and a potential solution On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig r...@cheshireeng.com wrote: ... from a user experience point of view. The thread stalled out after a patch was offered by Kyle McKay[1] that would have dropped the use of the IP adderss in the session cookie hash, allowing the same session cookie to be used from any IP address until the session was explicitly logged out. That would be my proposal as well. Under that model, to prevent _others_ from logging you out, the logout requires that you give it the auth token you were given by login. Since the tokens would be recycled, if you lose your cookie/hash you can re-fetch it by performing a login, which you can then use to logout and invalidate the hash. The overall model is described here: http://whiki.wanderinghorse.net/?page=WhikiAuthentication (mentally substitute auth token for fossil cookie and the idea is the same) It appears that DRH was ahead of the curve in making sessions unique to a specific IP, the issue with all the major sites that is exploited by session sniffing apps such as the infamous firesheep plugin. Computer security is one area i know absolutely nothing about, so i'll defer to anyone's judgement on such topics. I should be possible to support more than one session cookie per user, but then you would need a process to occasionally purge stale sessions from the server. You could do that check on any session validation, if its been long enough since the last check. Or at least check a few sessions on each validation if that is expensive to do en masse. Given the scope of even the largest fossil repos (by far under 100 users?), cleanup would be fast, and could probably be performed before every login request... doh... one could argue that cleaning up the logins should require admin 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
