Hi Shawn Maybe I should have qualified the parameters of scenarios this make me comfortable just proxying Solr directly w/o an API
These situations include: 1. I've got no qualms about giving the whole world access to every document in the index. There's nothing protected about anything. 2. The content can be easily rebuilt , it's not very large. (I can easily push a button and make a new one) Sure you can denial of service Solr, and I might lose my search index. But you can denial of service anything. This includes just about anything you put in front of Solr. Moreover, the added complexity of a Drupal/Wordpress/your API might only add to the security problems with their own security issues. I'd rather keep it simple and have fewer moving parts. Cases where I would want an API in front of Solr (these are just the security ones): - I want to protect the content (ie based on some notion of a "user" or other permissions) - Rebuilding the content would be very hard and time consuming I would also say to expose Solr directly to everyone you probably should know about Solr's bugaboos: - the lovely qt parameter and the request dispatcher (the nginx proxy below disallows qt) - deep paging (prevented by the nginx proxy) - how to lock down a request handler fairly robustly, how to use invariants - mitigating intentionally malicious queries (such as the lovely "sleep" function query). I'm also curious to hear what the websolr people do, or anyone else that hosts Solr for the JavaScript app development crowd. Cheers -Doug On Friday, December 25, 2015, Shawn Heisey <apa...@elyograg.org> wrote: > On 12/25/2015 12:17 PM, Eric Dain wrote: > > Does allowing javascript direct access to SolrCloud raise security > concern? > > should I build a REST service in between? > > > > I need to provide async search capability to web pages. the pages will be > > public with no authentication. > > End users should never have access to Solr. Access to Solr from the > end-user machine is required if you want to accept Solr responses directly. > > In one of the other replies that you received, Doug has given you an > nginx config for proxying access to Solr -- indirect access. This can > protect against *changes* to the index, and it has protection against > high start/rows values, but there are many other ways that an attacker > can construct denial of service queries, which this proxy config will > not prevent. > > I think that indirect access (through a proxy) should not be allowed > either, unless you can trust all the people that will have access. > > If Solr is open to a sufficiently wide audience (especially the > Internet), someone will find a way to abuse the service even with a > proxy, either to cause harm or to learn things they shouldn't know. > > The most secure option is to only allow the webservers and trusted > administrators to access Solr. All end user (Internet) access to Solr > should be handled through a custom web application. This might be > something that you find and install (such as wordpress, drupal, etc), or > one that you write yourself. > > You can still do AJAX while maintaining security. You'll need to write > something in a server-side web programming language like PHP, Java, etc. > This code will need to accept the AJAX requests from your client-side > javascript code, validate the request parameters to make sure they're > sane, get a response from Solr, and return relevant data. If the > parameters don't validate, return an error, and handle that error > appropriately in the javascript code. > > Thanks, > Shawn > > -- *Doug Turnbull **| *Search Relevance Consultant | OpenSource Connections <http://opensourceconnections.com>, LLC | 240.476.9983 Author: Relevant Search <http://manning.com/turnbull> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
