Re: [Bigdata-developers] Read-only access to NanoSparqlServer

[Bryan T. <br...@sy...>]

We are currently looking at how to refactor the REST API layout in order to
make such decisions easier.  This also includes separating out admin
aspects of the interface (such as the ability to invoke dumpJournal, force
HA server failover, list and cancel active queries and mutation tasks, etc.
 (Michael and I will be talking about this later today.)

Bryan

----
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@sy...
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  MapGraph™ <http://www.systap.com/mapgraph> is our disruptive new
technology to use GPUs to accelerate data-parallel graph analytics.

<http://smartdata2015.dataversity.net/>

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Thu, Jul 23, 2015 at 5:02 AM, Antoni Myłka <ant...@qu...>
wrote:

> Hello,
>
> How to grant someone read-only access to NanoSparqlServer?
>
> The readOnly context-param won't work AFAIU, because I still want to
> write, I just want to limit certain requests to be read-only.
>
> We have a bigdata instance running behing a firewall and a public
> front-end. We want to expose an API for other apps to post SPARQL queries.
> I didn't want to reinvent the wheel, so I just wrote a trivial proxy
> servlet, based on https://github.com/mitre/HTTP-Proxy-Servlet. With it I
> was able to expose the entire NanoSparqlServer functionality in our
> frontend.
>
> Then I started extending my servlet to detect mutating requests and reject
> them. This turned out to be tricky.
>
> I wanted to allow all kinds of queries:
>  - GET and POST with 'query' parameter, CONSTRUCT, SELECT, ASK, DESCRIBE
>  - ESTCARD and HASSTMT
>  - with all allowed parameters (s=, p=, o=, exact=true, etc.)
>  - with all supported output formats
>
> But I wanted to refuse all kinds of mutations
>  - everything with 'update' parameter, including those with both 'query'
> and 'update', GET and POST
>  - POST with body
>  - POST with uri
>  - POST with multipart form data
>  - DELETE all
>  - DELETE with a triple pattern
>  - PUT with a query and a body
>
> After a while I got my proxy servlet to cover all those cases, but now I
> ask myself: is there a better way? The code I wrote seems brittle. I don't
> know if it really covers everything and it will have to be adapted if the
> API changes in future versions of Blazegraph.
>
> So, is there a better way?
>
> Best regards
>
> --
> Antoni Myłka
> Software Engineer
>
> Quantinum AG, Birkenweg 61, CH-3013 Bern - Fon +41 31 388 20 40
> http://www.quantinum.com - Experience the Power of Data
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bigdata-developers mailing list
> Big...@li...
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
>