On 10/3/2013 12:16 PM, Bruce Pennypacker wrote:
We're running solr 4.1.0 in a production environment along with a number of mirrored staging environments. We provide full access to the admin console to our developers & qa on the staging environments. We'd like to be able to provide them with limited access to the production admin pages so that they can do things like view the dashboard & properties, view the schemas of each core, run queries, etc. but not be able to do things like add/remove cores, rename them, disable replication, etc. We'd actually be happy with a fully read-only version of the admin console for them as long as our production folks would have full access when needed.
The basic answer boils down to "don't expose Solr directly to anyone if you don't trust them." If someone has direct access to Solr and has any clue about Solr, they can do things you probably did not intend for them to do. Firewall Solr so only trusted people and applications can get to it.
Security is not something that is part of Solr's design goals. If you want to add security, your servlet container should provide mechanisms for doing so. Note that if you do so, some Solr features may not work right, particularly if you are running SolrCloud or old-school distributed search.
Even if you locked down the admin interface, which largely runs as javascript in the browser, the actual work gets done by API calls through request handler URLs, not the admin interface itself.
You'll run into strong resistance for putting any security features into Solr itself. We'd rather work on search, not spend all our time making and fixing security mechanisms, plus taking heat anytime they don't work as advertised and somebody loses millions of ${CURRENCY} because of it.
I know this is not what you want to hear. It is however the current reality.
Thanks, Shawn
