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.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 goks...@gmail.com
