Alex, On 6 Feb 2013, at 13:26, Alex Wilson wrote: > I've been trying to do parametrised SPARQL queries (using the > QuerySolutionMap class) against d2rq, and have found that the bindings > are completely ignored. I feel this is a very important issue, as > otherwise there is no safe way to use user input in a query without > complex escaping and quoting logic on the application side.
Agreed. > I came up with a bit of a hack to solve this, modifying QueryEngineD2RQ > -- does this look horrible or problematic? Was the inputBinding here > dropped and replaced with an empty one for a reason that I've missed? It's not a hack; this in fact looks like exactly the right solution to the bug. > see https://gist.github.com/anonymous/f3f8c0b1a48af18cc67e I've committed your fix to the old master branch, and will include it also in the new develop branch with a bigger set of changes I'm working on at the moment. > P.S. There's also (just as an aside, it needs more work) a patch to > Joseki on that gist, that enables basic use of query parameters on the > /sparql endpoint in d2r-server. It means you can do GET > /sparql?query=...&foo=123&foo_type=integer and ?foo within the query > will be bound safely as "123"^^xsd:integer, without having to worry > about quoting or escaping anything in foo (aside from making it > URL-safe, of course) That seems extremely useful indeed. Note that development of Joseki has ceased. Going forward, we will need to ditch Joseki and use its successor, Apache Fuseki. We haven't done that switch yet, as Joseki is working mostly fine for the moment, and the switch offers fairly limited user benefit. I don't know how difficult the switch will be. Some comments on the Joseki part of the patch: 1. It should only put variables into the initial binding if they are actually used in the query, to avoid problems resulting from other URL parameters. See ARQ's PatternVarsVisitor for helpful code; it doesn't collect variables that don't bind, for example in FILTER, so would need a bit of extension. 2. The patch seems to only allow passing of literals. Would be good to be able to pass URIs as values as well. 3. Consider more compact syntax: &foo_int=123&bar_date=2013-02-06 4. OTOH, maybe it's better to keep it simple and allow passing of *only* plain literals. You can always convert them inside the query: xsd:integer(?foo) All the best, Richard > > Thanks, > Alex W. > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > d2rq-map-devel mailing list > d2rq-map-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/d2rq-map-devel ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ d2rq-map-devel mailing list d2rq-map-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/d2rq-map-devel
