Rurik's suggestion in timeouts is good to protect the endpoint against
excessive work.
There could be a front end that analyse queries to see if there were
acceptable. This isn't easy in the general case ( SELECT * { ?s ?p ?o .
?x ?y ?z } is very expensive - square of the size of the database!) and
the structure of the data and needs of the application also play a part.
What is accept for some data is not for other data.
This is a "reverse proxy" - the SPARQ endpoint is only accessible by
this front-end filter. Nothing like this is in the Jena release.
Permissions isn't sensitive to the query - it also requires not
executing the query as directly as possible - all low level access has
to be checked.
Andy
On 27/03/17 06:55, Lorenz B. wrote:
I'm not aware of any option/flag in Jena that restricts the
expressiveness of the SPARQL language such that a query will be rejected
if it's beyond the configured SPARQL features.
Probably Andy Seaborne knows more
This seems to be about securing data, or part of a graph. My data is actually
all public, and I just want to add some limitations to make sure that people
can use my SPARQL endpoint without overloading it at the same time with complex
queries that suck up all the resources.
Sent: Sunday, March 26, 2017 at 4:13 PM
From: "A. Soroka" <[email protected]>
To: [email protected]
Subject: Re: Limited HTTP API
There is some documentation about combining Shiro with jena-permissions
available here:
https://jena.apache.org/documentation/permissions/example.html
The extent to which that will be useful to you may be limited to the extent to
which you can fit the patterns of usage you want to control into the
dataset/graph/triple framework over which jena-permissions works.
---
A. Soroka
The University of Virginia Library
