On Sat, Aug 30, 2014 at 5:59 AM, Timothy Beyer <bey...@fastmail.net> wrote:
> foo LIKE '%BAR%' > > I believe that there is some sort of issue with the way the % symbol is > handled. > When passing anything via URLs, '%' needs to be encoded as %25 - it's a special HTTP character. If you pass the query string via POST, that won't happen. Whereas the following works correctly: > > foo GLOB '*[Bb][Aa][Rr]*' > Because those aren't special HTTP characters (need no encoding). > I've been meaning to submit patches, but I haven't even looked at that > part of > the code yet, and you probably know it much better than I do. > A report is fine - i don't mind doing the patching. i think this is a case of not encoding, though. > Thanks for the JSON API, it's been invaluable. > :) > That sounds very promising. My issues with TH1 were namely that I didn't > know > how to use it in dynamic AJAX type applications, (to start with, I think > the > TH1 argv API was deprecated, am I correct in this assumption?) You can't use th1 in ajax apps because fossil has no mechanism for doing so (e.g. for specifying a custom Content-Type and replacing all output of the page). In fact, that's how this all started... Two summers ago i tried to extend fossil with the ability to add "custom pages," which were just scripts which could do whatever you like (e.g. create JSON responses instead of a web page). It turned out th1 wasn't up for the job, which became the catalyst for two things: (A) finally sitting down and working on the garbage collector i'd been thinking through for several years, with the intention being working towards a scripting engine, and (B) libfossil, because any client-extensible scriptability needs a library-style API (something we had discussed at the project level before, but discounted because of the effort required). It took a year to get the initial scripting engine and language (two separate beasts) in place, at which point libfossil was started (Summer, 2013), and the second script engine was started this past June to replace the first one (which had grown kind of crufty in its brief life). and that I > couldn't access parts of the database that were crucial to my needs. You do now :). The first script-available feature was the DB layer. It seems i didn't bind the pseudo-recursive transactions bits, but everything else one needs for DB access seems to be there, and the require.s2 module makes it really easy to write mini-apps/modules to import data: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/artifact/09965598835e943b617e84fab83d3b2f49bbc9a7 (One might notice that i adopted tcl's proc keyword, as it's just so much simpler to type than function!) require.s2 is here: https://docs.google.com/document/d/14gRP4f-WWgWNS64KM_BI7YjQqBLl4WT3jIrmNmFefYU/view I'll look > into libfossil at some point, as I find fossil the ideal basis for > applications > based on a versioned datastore. > One of libfossil's goals is to allow one to plug those same features into arbitrary applications. It can currently do quite a bit (most of the read-only features and many of the writing ones), but some of the critical features are still missing, namely merge/update and anything network related. I like TCL and especially TK, so I see a lot of potential in TH1, but it > seems > to me that JavaScript is already an ideal extension language for most > fossil-based web applications. > TCL isn't much my cup of tea, but i'm in the minority on that point around here ;). s2's JS-like syntax is just what i happen to find most comfortable to use. It can, however, be more syntactically verbose than command-based languages like TCL, and TCL's style is arguably a closer fit to fossil(1), though whether that's true for fossil(3) remains to be seen. Maybe we'll have a TCL binding on libfossil at some point (the s2 bindings are not built-in to libfossil - they're essentially a 3rd-party application). > Those permssions are for a reason - imagine what happens if a user sends > "DROP TABLE blob" via the > > JSON API. Even if we use authenticators which prohibit that (sqlite > supports it), being able to query > > allows them to reach _any_ blob, regardless of access restrictions. > > I figured that was the reason, and it's perfectly legitimate, but I just > wish > that there was some way to block all JSON API URLs from outside of the > fossil > repository, only allowing it to be used in the application itself. > Once a query has arrived, there's no way to know where it came from. The JSON API, for example, can be used from the CLI as well as via HTTP (because it's much easier to test that way). It can figure out whether it's running from the CLI, but it seems too limiting to me to restrict queries to that mode. Two potential solutions, used in conjunction, come to mind: a) maybe a repo-level config option which says whether to allow SELECT queries from anyone with (say) checkin access. b) install sqlite authenticators via the JSON API which reject anything which changes the DB. But with a huge caveat attached: if everyone (including guest/anonymous) has SELECT access, then _anyone_ can fish _anything_ out of your repo, or potentially even DoS you with a simple (select * from blob), which would create a massive list of JSON objects/arrays in memory (the JSON API is DOM-like, not streaming). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
