Re: [Bigdata-developers] Lock Down a BigData server

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

Doug,

I've just committed a fix for this [1].  Please try it out.  I have verified the readOnly feature on a local WAR deployment.  I have not tested the queryTimeout limit feature.

Thanks,
Bryan

[1] https://sourceforge.net/apps/trac/bigdata/ticket/643#comment:1

From: Doug Whitehead <dou...@gm...<mailto:dou...@gm...>>
Date: Thursday, February 7, 2013 10:39 AM
To: Bryan Thompson <br...@sy...<mailto:br...@sy...>>
Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>>
Subject: Re: [Bigdata-developers] Lock Down a BigData server

How about a simple init-param for each?  If they are not there, then let it go unfettered (as it is now). Something like:

  <servlet>
        <servlet-name>REST API</servlet-name>
        <display-name>REST API</display-name>
        <description>The REST API, including a SPARQL end point, as described at
        https://sourceforge.net/apps/mediawiki/bigdata/index.php?title=NanoSparqlServer
        </description>
        <init-param>
             <param-name>readOnly</param-name>
             <param-value>true</param-value>
        </init-param>
        <init-param>
             <param-name>maxQueryMs</param-name>
             <param-value>20000</param-value>
        </init-param>
        <servlet-class>com.bigdata.rdf.sail.webapp.RESTServlet</servlet-class>
        <load-on-startup>0</load-on-startup>
  </servlet>

At least for my use case, I load the data as an admin. When I'm happy, I lock it down so that neither I nor anyone else can change it.

Further, if I wanted to have a public and a private (admin) interface, I could have a separate servlet-mapping and separate servlet up with different init-param tags

On Thu, Feb 7, 2013 at 10:20 AM, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote:
Using POST for Query is a hugely bad idea unless your goal is to defeat the HTTP caching layer.

It is easy enough to add a configuration option that disables mutation.  However, this would have to be selectively disabled|enabled for specific interfaces in order to let you use the REST API to update the database while denying that privilege to public facing interfaces.

Do you have a concrete suggestion on how to specify the set of interfaces for which update should be allowed or denied?  See the SparqlEndpointConfig class.  This is populated from web.xml in  BigdataRDFServletContextListener.  If you can suggest a mechanism for allowing update on only certain interfaces, then I am happy to integrate it.

We could use a similar mechanism to impose a timeout on queries according to the interface on which they arrive.

Thanks,
Bryan


From: Doug Whitehead <dou...@gm...<mailto:dou...@gm...>>
Date: Thursday, February 7, 2013 10:13 AM
To: Bryan Thompson <br...@sy...<mailto:br...@sy...>>
Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>>
Subject: Re: [Bigdata-developers] Lock Down a BigData server

Yes the intent is to expose an idempotent SPARQL 1.1 Query interface.

However, I don't think denying POST is an option, as:

Many clients use forms to POST
  *to avoid query strings from showing up on the URL
  *to avoid URL length potential issues
And many frameworks such as ELDA only use post

So there is no way to make BigData idempotent without parsing the query string for myself?


On Fri, Dec 14, 2012 at 7:58 AM, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote:
Doug,

Is your intention to expose the SPARQL 1.1 Query interface?  If so, you can just deny any HTTP method other than GET.  You can also restrict the URIs that are visible to only include the …//sparql path for the external interface of your host.  That will make things like the performance counters and the status pages unavailable.

Many times people narrow the interface further through an application layer rather than exposing the full SPARQL query language.  There is an open thread on the discussion forum [1] for imposing a timeout on all external interface requests.  That thread suggests how this can be done by modifying the code and some possible approaches to automating this policy.

Thanks,
Bryan

[1] https://sourceforge.net/projects/bigdata/forums/forum/676946/topic/6133565

From: Doug Whitehead <dou...@gm...<mailto:dou...@gm...>>
Date: Wednesday, December 12, 2012 10:20 PM
To: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>>
Subject: [Bigdata-developers] Lock Down a BigData server

I like and use the SPARQL 1.1 interface to load  and delete data.
However, when I take this puppy to production, I don't want others to be able to modify my endpoint.

Sorry for the n00b question, but...
After I have loaded data, how do I lock it down?

Thanks,
Doug