SOLR-14136: ip whitelist/blacklist via env vars
This makes it easy to restrict access to Solr by IP. For example SOLR_IP_WHITELIST="127.0.0.1, 192.168.0.0/24, [::1], [2000:123:4:5::]/64" would restrict access to v4/v6 localhost, the 192.168.0 ipv4 network, and 2000:123:4:5 ipv6 network. Any other IP will receive a 403 response.
Blacklisting functionality can deny access to problematic addresses or networks that would otherwise be allowed. For example SOLR_IP_BLACKLIST="192.168.0.3, 192.168.0.4" would explicitly prevent those two specific addresses from accessing solr.
The Overseer used java serialization to store command responses in ZooKeeper. This commit changes the code to use Javabin instead, while allowing Java serialization with a System property in case it's needed for compatibility
Jetty 9.4.16.v20190411 and up introduced separate
client and server SslContextFactory implementations.
This split requires the proper use of of
SslContextFactory in clients and server configs.
This fixes the following
* SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
* Http2SolrClient SSL not working in branch_8x
Signed-off-by: Kevin Risden <krisden@apache.org>
The default configset no longer has the following:
- Library inclusions (<lib ../>) for extraction, solr-cell libs, clustering, velocity and language identifier
- /browse, /tvrh and /update/extract handlers
- TermVector component (if someone wants it, can be added using config APIs)
- XSLT response writer
- Velocity response writer
If you want to use them in your collections, please add them to your configset manually or through the Config APIs.
* Using collapse with grouping would cause inconsistent behavior.
This is because grouping calls the same postfilter twice without
resetting the internal state of the DocValues cache
* Using expand with grouping would cause NPE
There are applications of ExpandComponent that intentionally do not
involve prior collapsing of results on the expand field, which can lead
to an NPE in expand component when expand.field (for matched docs) has
fewer unique values than the number of matched docs.
This commit refines the approach taken in SOLR-13877, which addressed
the same underlying issue.
whoami displays a warning if the effective-uid is not in /etc/password.
This can happen in certain situations when running in a docker
container. This replaces the 'whoami' usage with a safer check.
Unfortunately, as a first start this is very weak protection against
e.g. XSS. This is because some 'unsafe-xxx' rules must be present due
to the insecurity of angular JS: Until SOLR-13987 is fixed, XSS & co are
still easy.
