> So, usually, the middleware is the answer, just like with a database. With applications backed by database systems, there is usually an application server tier, and then a database tier. There may be a web server tier in front of the application server tier. The search engine and database belong in the same tier. Suppose your search needs the title and some other information to be displayed with search results - store these in the search engine. Suppose your detailed pages need lots of additional fields - maybe you can keep those in your database and retrieve them only as needed for click-through.
-----Original Message----- From: Alexandre Rafalovitch [mailto:arafa...@gmail.com] Sent: Tuesday, August 25, 2015 9:40 AM To: solr-user <solr-user@lucene.apache.org> Subject: Re: Bot protection (CAPTCHA) The standard answer is that exposing the API is a REALLY bad idea. To start from, you can issue the delete commands through the API. And they can be escaped in multiple different ways. Plus, you have admin UI there as well to manipulate the cores as well as to see the configuration files for them. So, usually, the middleware is the answer, just like with a database. Most recent (5.3!) version of Solr added some authentication, but that's still not something you could use from a public web page, as that would imply hard-coding password. You could possibly make index read-only, lock down filesystem, etc. But that's a lot of effort and logistics. Regards, Alex. ---- Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter: http://www.solr-start.com/ On 25 August 2015 at 09:29, Dmitry Savenko <d...@dsavenko.com> wrote: > Hello, > > I plan to expose Solr search REST API to the world, so it can be > called from my web page directly, without additional server layer. I'm > concerned about bots, so I plan to add CAPTCHA to my page. Surely, I'd > like to do it with as little effort as possible. Does Solr provide > CAPTCHA support out of the box or via some plugins? I've searched the > docs and haven't found any mentions of it. > > Or, maybe, exposing the API is an extremely bad idea, and I should > have a middle layer on the server side? > > Any help would be much appreciated! > > Best regards, Dmitry.
