Hi Lance, Thanks for your message. I'm guessing you mean modify the Solrj auth mechanism on the server side.
In order to use the standard 'shards' parameter in client requests, the problem occurs before CommonHttpSolrServer, because the SearchHandler indeed passes an HttpClient object to CommonHttpSolrServer to use for shards, but it doesn't populate it with any credentials (it doesn't have any to provide). The idea behind the proposed solution is to provide a way to propogate credentials to the underlying CommonsHttpSolrServer, as well as define a way of getting those credentials to the (proxy) server. Perhaps, it would be better if the credentials come from Solr-side configuration (an xml file), relieving remote clients from sending credentials (or have both options available, and let config decide). This is perhaps a more secure way of holding/providing credentials, but the client is then reliant on that configuration being present on any and all servers it connects to. This would also mean that *any* client could access all shards with a single login (or no login if the container doesn't use authentication). Hmm...could be thought of as a security hole or indeed SSO, depending on your persepective :-). Thanks, Peter On Thu, Apr 8, 2010 at 3:38 AM, Lance Norskog <goks...@gmail.com> wrote: > 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 >
