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:

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

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,

Reply via email to