Ryan McKinley wrote:
On Nov 17, 2008, at 4:20 PM, Erik Hatcher wrote:
trouble is, you can also GET /solr/update, even all on the URL, no
request body...
<http://localhost:8983/solr/update?stream.body=%3Cadd%3E%3Cdoc%3E%3Cfield%20name=%22id%22%3ESTREAMED%3C/field%3E%3C/doc%3E%3C/add%3E&commit=true>
Solr is a bad RESTafarian.
but with Ian's options in the apache config, this would not work...
rather it would only work if stream.body was a POST
<location /solr/update>
order deny,allow
deny from all
allow from 192.168.0.1
</location>
?
or perhaps locationmatch.. but you get the picture.
Getting warmer!
Erik
On Nov 17, 2008, at 4:11 PM, Ian Holsman wrote:
if thats the case putting apache in front of it would be handy.
something like
<limit POST>
order deny,allow
deny from all
allow from 192.168.0.1
</limit>
might be helpful.
Sean Timm wrote:
I believe the Solr replication scripts require POSTing a commit to
read in the new index--so at least limited POST capability is
required in most scenarios.
-Sean
Lance Norskog wrote:
About that "read-only" switch for Solr: one of the basic HTTP design
guidelines is that GET should only return values, and should never
change
the state of the data. All changes to the data should be made with
POST. (In
REST style guidelines, PUT, POST, and DELETE.) This prevents you from
passing around URLs in email that can destroy the index. The
first role of
security is to prevent accidents.
I would suggest two layers of "read-only" switch. 1) Open the
Lucene index
in read-only mode. 2) Allow only search servers to accept GET
requests.
Lance
