Re: Limited HTTP API

2017-03-27 Thread Andy Seaborne
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" <aj...@virginia.edu>
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

2017-03-26 Thread Lorenz B.
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" <aj...@virginia.edu>
> 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

2017-03-26 Thread Rurik Thomas Greenall
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 <laure...@mail.com> 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" <aj...@virginia.edu>
> 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

2017-03-26 Thread Laura Morales
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" <aj...@virginia.edu>
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

2017-03-26 Thread A. Soroka
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

2017-03-26 Thread A. Soroka
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.