Distributed Search, down at the bottom, uses SolrJ. This problem
should be in SolrJ in the CommonsHttpSolrServer. The Apache Commons
HTTP stuff handles authentication:


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.stu...@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

Reply via email to