Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.3, 1.4, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6
Description
The "shards" parameter does not have a corresponding white list mechanism, so it can request any URL, and the content of the HTTP response will be returned.
For legacy master/slave clusters, there is no Zookeeper to keep track of all the nodes and shards in the cluster. So users manage the 'shards' parameter manually for distributed search. This issue will add the option of configuring a list of what shards can be requested.
Users will then get an explicit error response if the request includes a shard which is not in the preconfigured whitelist, e.g. due to a typo. I think all shards logic is handled by HttpShardHandler already so the logic should fit nicely in that one class, configured in solr.xml.
With SolrCloud this whitelist is auto managed to match nodes in the cluster. It is possible to disable the whitelist feature for backward compatibility. Please see Reference Guide chapter Distributed Requests.