lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Norskog <goks...@gmail.com>
Subject Re: HTTP Authentication for shards
Date Thu, 08 Apr 2010 02:38:27 GMT
Distributed Search, down at the bottom, uses SolrJ. This problem
should be in SolrJ in the CommonsHttpSolrServer. The Apache Commons
HTTP stuff handles authentication:

http://hc.apache.org/httpclient-3.x/authentication.html

You can create the HttpClient and ConnectionManager yourself when
using SolrJ, and it's easy to prototype all of the authentication
stuff with a simple SolrJ program.

On Fri, Apr 2, 2010 at 4:15 AM, Peter Sturge
<peter.sturge@googlemail.com> wrote:
> Hi,
>
> I've come across an interesting problem with regards distributed searching,
> and thought I'd share it here and see if anyone else has come across it
> and/or comment on the proposed solution:
>
> *Requirement:*
> A requirement of my particular Solr environment is that queries are subject
> to http authentication (I currently use Jetty basic realm auth, but any http
> auth is affected).
> i.e. If you don't have a username/password, you can't look at anything.
> For most use cases, I'm guessing that queries aren't generally subject to
> authentication, hence this post...
>
> *Problem:*
> Querying a single server is easy, because my client app creates/manages its
> own HttpClient object.
> When it comes to querying across shards, the default SearchHandler uses a
> 'plain-vanilla' http client for its CommonsHttpSolrServer instance that
> makes the request to each shard (in HttpCommComponent.submit()).
> There is no provision to pass it any credentials.
>
> Perhaps document-level security might be a better way to handle access
> control for searching in general, but that's a different can of worms... :-)
>
> *Proposed Solution:*
> A proposed solution for overall Solr access for searching across
> http-authenticated shards is this:
>
> 1. Define parameter(s) syntax for shard credentials.
>
> 2. Modify (or subclass) SearchHandler, in particular the
> HttpCommComponent.submit() method, to optionally look for shard-specific
> credentials in its ModifiableSolrParams params.
> If it finds credentials, it creates/reuses an HttpClient object with these
> and passes this to the SolrServer instance for the search request.
> Because the credentials parameter would be totally optional, it should be
> fine to patch SearchHandler 'in-line' without subclassing, so that
> patches/updates will work without having to modify solrconfig.xml.
> (feel free to disagree with me on this!)
>
> 3. This also requires a modification to SearchHandler.handleRequestBody() to
> extract the credentials parameter(s) and pass these on to the submit()
> request (similar to what it does now for SHARDS_QT).
>
> 4. Clients would populate their sharded query request with the defined
> parameter(s) for each shard (I'm using SolrJ so there's app logic to do
> this, but should be ok for other client types).
>
> I admit I'm not an expert on SearchHandler inner workings, so if there are
> other code paths that would be affected by this, or any other potential
> issues, any advice/insight is greatly appreciated!
> If anyone thinks this is a barmy idea, or has come up with a better
> solution, please say!
>
> Many thanks,
> Peter
>



-- 
Lance Norskog
goksron@gmail.com

Mime
View raw message