Re: Limited HTTP API
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" To: users@jena.apache.org 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
Re: Limited HTTP API
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" > To: users@jena.apache.org > 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 > > -- Lorenz Bühmann AKSW group, University of Leipzig Group: http://aksw.org - semantic web research center
Re: Limited HTTP API
Hi Laura, Perhaps worth configuring timeouts < https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html>, which should prevent the situations you aim to prevent. Regards, Rurik On Sun, Mar 26, 2017 at 5:49 PM, Laura Morales wrote: > 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" > To: users@jena.apache.org > 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 >
Re: Limited HTTP API
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" To: users@jena.apache.org 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
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 > On Mar 26, 2017, at 9:58 AM, A. Soroka wrote: > > You have Apache Shiro available for coarse authorization action on the > endpoint, but that will not do much for you if you need to act differently > according to the parsed query. > > Claude, could jena-permissions be used here for some cases? > > --- > A. Soroka > The University of Virginia Library > >> On Mar 26, 2017, at 8:04 AM, Laura Morales wrote: >> >> I'd like to make one of my SPARQL endpoints publicly accessible through a >> REST API. The problem however, is that SPARQL is a very expressive language, >> and it's too easy to abuse it with complex, unoptimized queries. >> I'm wondering if there's any "filter" that can be applied on the HTTP >> request in order to limit what the user can do; for example "allow nodes >> traversal only" or "return MAX results at most" etc. >
Re: Limited HTTP API
You have Apache Shiro available for coarse authorization action on the endpoint, but that will not do much for you if you need to act differently according to the parsed query. Claude, could jena-permissions be used here for some cases? --- A. Soroka The University of Virginia Library > On Mar 26, 2017, at 8:04 AM, Laura Morales wrote: > > I'd like to make one of my SPARQL endpoints publicly accessible through a > REST API. The problem however, is that SPARQL is a very expressive language, > and it's too easy to abuse it with complex, unoptimized queries. > I'm wondering if there's any "filter" that can be applied on the HTTP request > in order to limit what the user can do; for example "allow nodes traversal > only" or "return MAX results at most" etc.
Limited HTTP API
I'd like to make one of my SPARQL endpoints publicly accessible through a REST API. The problem however, is that SPARQL is a very expressive language, and it's too easy to abuse it with complex, unoptimized queries. I'm wondering if there's any "filter" that can be applied on the HTTP request in order to limit what the user can do; for example "allow nodes traversal only" or "return MAX results at most" etc.