Point taken, Shawn. Thanks for your input.
----- Mail original ----- De: "Shawn Heisey" <apa...@elyograg.org> À: solr-user@lucene.apache.org Envoyé: Vendredi 13 Mars 2015 16:12:46 Objet: Re: Word frequency On 3/13/2015 8:54 AM, phi...@free.fr wrote: > > If you are asking whether users have access to /browse, then the answer is > yes. > > Currently, they can type keywords in the q input field to do searches. > > I plan to turn q into a hidden field and add a 'keywords' input field whose > contents will be transferred to q when users press Search, using Javascript. > > I will also add date selects so that users don't have to type date queries. > > How do you secure the rest of SOLR (e.g., admin)? > > Would would recommend creating an alternative Search GUI with, say, Wicket, > which queries SOLR using AJAX? > > Sounds hard, but I will try. Velocity is so much simpler. Anything that requires an end user to have direct access to Solr (which includes both the /browse handler and AJAX) is a potential security issue. If that access is unfiltered, a user can completely erase your index, or cause other problems. Switching to a different input field other than "q" won't be any kind of protection ... they will just have to run their browser in debug mode and they'll be able to see the Solr queries sent, and then they can completely bypass any javascript protections you create. The intent with Solr is that it will be completely firewalled from user access and only queried by server-side programs (PHP, Java, Ruby, etc). Securing a Solr server exposed to the public requires an intelligent proxy server with a specific config tailored to only allowing certain requests to work. I had this discussion with someone else on a javascript client for Solr, and they said they're using this for a proxy, and that this code will protect the Solr server from malicious activity: https://github.com/adsabs/solr-service I haven't looked deeper, so I don't know if that claim is valid. Note that even with a proxy server, it is still usually possible to send denial-of-service queries designed to keep the server too busy to handle legitimate requests. If the code that accesses Solr is server-side, then you may be able to detect malicious queries created from user input and stop them from being sent to Solr. Thanks, Shawn
