lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: Multi-Tenant Setup in Single Core
Date Tue, 12 Nov 2013 12:51:34 GMT
When you mention velocity, you're talking about the stock Velocity Response
Writer that comes with the example? Because if you're exposing the Solr
http address to the world, accessing each others data is the least of your
worries. To whit:

http://machine:8983/solr/collection/update?commit=true&stream.body=
<delete><query>*:*</query></delete>

Often people put a dedicated app in front of their Solr and secure that,
then put a firewall between their Solr and the world that only lets
requests through from the known app machines.

Best,
Erick


On Tue, Nov 12, 2013 at 7:09 AM, Christian Ramseyer <rc@networkz.ch> wrote:

> Hi guys
>
> I'm prototyping a multi-tenant search. I have various document sources and
> a tenant can potentially access subsets of any source.
> Also tenants have overlapping access to the sources, why I'm trying to do
> it in a single core.
>
> I'm doing this by labeling the source (origin, single value) and tag the
> individual documents with a list of clients that can
> access it (required_access_token, array). A tenant then gets a Velocity
> search handler with invariant fq like this:
>
>         <requestHandler name="/searchui_client1"
> class="solr.SearchHandler">
>                 <lst name="invariants"> <str name="fq">
>                          (origin:(client1docs OR generaldocs) AND
> required_access_token:(client1))
>                 </str></lst>
>
>         <requestHandler name="/searchui_client2"
> class="solr.SearchHandler">
>                 <lst name="invariants"><str name="fq">
>                          (origin:(client2docs OR generaldocs) AND
> required_access_token:(client2))
>                 </str></lst>
>
>         <requestHandler name="/searchui_client3"
> class="solr.SearchHandler">
>                 <lst name="invariants"><str name="fq">
>                          (origin:(client3docs OR generaldocs) AND
> required_access_token:(client3))
>                 </str></lst>
>
> Access to the search handler by client is controlled via a reverse proxy,
> and all the other handlers like /browse or /select
> are not available.
>
> Do you guys see any obvious security problems with this? I'm especially
> worried about some kind of "SQL Injection" into the query field
> (edismax parser) in the velocity template handler which would allow to
> override or add stuff to the invariant fq, or the ability to
> select another query handler via URL parameters like
> /searchui_client1?qt=searchui_client2 or similar.
>
> Do you think this setup can be reasonably safe?
>
> Thanks
>
> Christian
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message