Please stay on the list. Anyway, it's a matter of not exposing certain request handlers to the public. If you have a master/slave set up, you can remove the update handlers from your public facing slave (or hide it behind HTTP auth in your proxy). The same goes for other defined request handlers.
Essentially, you must know all about your defined request handlers in order to know whether they are secure or not. Cheers, On Friday 19 November 2010 09:15:42 lee carroll wrote: > Hi thanks for the response > So if I follow what you are saying for a public facing index the standard > pattern is to run behind a reverse proxy providing security (and caching?) > Are their any docs on this? Or example deployment diagrams / config. Thanks > lee c > > On 18 Nov 2010 23:14, "Markus Jelsma" <markus.jel...@openindex.io> wrote: > > Hi, > > > > It's a common practice not to use Solr as a frontend. Almost all deployed > > instances live in the backend near the database servers. And if Solr is > > being > > > put to the front, it's still being secured by a proxy. > > > > Setting up staging and production instances depend on your need. If the > > load > > > is small, you can run two Solr cores [1] on the same instance and if the > > load > > > is high you'd just separate them, the same goes for development and test > > instances. > > > > [1]: http://wiki.apache.org/solr/CoreAdmin > > > > Cheers, > > > >> Hi I'm pretty new to SOLR and interested in getting an idea about a > > simple > > >> standard way of setting up a production SOLR service. I have read the > > FAQs > > >> and the wiki around SOLR security and performance but have not found > >> much on a best practice architecture. I'm particularly interested in > >> best practices around DOS prevention, securing the SOLR web app and > >> setting up dev, test, production indexes. > >> > >> Any pointers, links to resources would be great. Thanks in advance > >> > >> Lee C -- Markus Jelsma - CTO - Openindex http://www.linkedin.com/in/markus17 050-8536600 / 06-50258350
