I do not share this reasoning at all. Of course a new UI would need to be developed, solr/itas is just an example. But that precisely is the interest of solr/itas, a view system that is easy to tune.
I do not feel, at all, that it means that it is not production ready. There are a zillion ways to kill someone's server, some of them you sketched, which normal developers just have to accept as dangers. I barely see a difference between a solr/itas abuse such as see all params or a zillion requests or crawl. I also do not think that this answers the question of production readiness. I would more understand this question about the performance and potential leaks. paul Le 7 mai 2012 à 11:51, Jan Høydahl a écrit : > Hi, > > Like wunder said, restricting URLs still requires physical access to the > app-server, and there are a handful of ways to cause harm which you may not > be aware of. The argument "he would not need to develop a PHP > site/application" is not true. Solritas is far from ready for production, and > not intended to either. Even if you moved the Solritas code to another Tomcat > instance to avoid direct Solr access, you would still need to put extensive > development effort into the Solritas templates before you could call it a > finished search front end. What is so bad with PHP after all? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > Solr Training - www.solrtraining.com > > On 7. mai 2012, at 02:50, Marcelo Carvalho Fernandes wrote: > >> Hi Jan, >> >> I would answer András exactly the oposite :-) I would like to understand >> and ask you something. >> >> Would you see any problem if he had a Apache Httpd configured as reverse >> proxy (no PHP in it) in front of Solr just to restrict user access to only >> the Solritas's URL? This way Solr would not be directly exposed and he >> would not need to develop a PHP site/application. >> >> Maybe a Varnish layer would be even better as he has 1.000.000+ pageviews a >> day. Again, no PHP in this scenario. >> >> What's your opinion about both solutions? >> >> Thanks in advance, >> >> ---- >> Marcelo Carvalho Fernandes >> +55 21 8272-7970 >> +55 21 2205-2786 >> >> >> On Sun, May 6, 2012 at 7:42 PM, Jan Høydahl <jan....@cominvent.com> wrote: >> >>> Hi, >>> >>> Solritas (Velocity Response Writer) is NOT intended for production use. >>> The simple reason, apart from that it is not production grade quality, is >>> that it requires direct access to the Solr instance, as it is simply a >>> response writer. You MUST use a separate front end layer above Solr and >>> never expose Solr directly to the world. So you should feel totally >>> comfortable continuing to use Solr over HTTP from PHP! >>> >>> -- >>> Jan Høydahl, search solution architect >>> Cominvent AS - www.cominvent.com >>> Solr Training - www.solrtraining.com >>> >>> On 6. mai 2012, at 14:02, András Bártházi wrote: >>> >>>> Hi, >>>> >>>> We're currently evaluating Solr as a Sphinx replacement. Our site has >>>> 1.000.000+ pageviews a day, it's a real estate search engine. The >>>> development is almost done, and it seems to be working fine, however some >>>> of my colleagues come with the idea that we're using it wrong. We're >>> using >>>> it as a service from PHP/Symfony. >>>> >>>> They think we should use Solritas as a frontend, so site visitors will >>>> directly use it, so no PHP will be involved, so it will be use much less >>>> infrastructure. One of them said that even mobile.de using it that way >>> (I >>>> have found no clue about it at all). >>>> >>>> Do you think is it a good idea? >>>> >>>> Do you know services using Solritas as a frontend on a public site? >>>> >>>> My personal opinion is that using Solritas in production is a very bad >>> idea >>>> for us, but have not so much experience with Solr yet, and Solritas >>>> documentation is far from a detailed, up-to-date one, so don't really >>> know >>>> what is it really usable for. >>>> >>>> Thanks, >>>> Andras >>> >>> >
