Re: [jira] Commented: (SOLR-620) Velocity Response Writer
It is not a recommended practice to expose Solr to the end-users because it is so easy to bring down the server if the user knows that it is a Solr server. We must devise a good mechanism to filter the kind of commands that can be served . On Fri, Jul 11, 2008 at 8:14 PM, Erik Hatcher (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612894#action_12612894 ] Erik Hatcher commented on SOLR-620: --- Sure, contrib is fine. Where it ends up isn't a big deal to me. As for how Solr is deployed - having the web tier and Solr be one and the same (in a read-only configuration of course) is a pretty compelling way to deploy, I'd think. Why separate Solr and the UI when using load balanced replicated servers? Of course it depends on the needs of the application, but keeping a separate web app to regurgitate what Solr returns can be an unnecessary deployment hassle. Velocity Response Writer Key: SOLR-620 URL: https://issues.apache.org/jira/browse/SOLR-620 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch Add a Velocity - http://velocity.apache.org - response writer, making it possible to generate a decent search UI straight from Solr itself. Designed to work standalone or in conjunction with the JSON response writer (or SolrJS) for Ajaxy things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- --Noble Paul
Re: [jira] Commented: (SOLR-620) Velocity Response Writer
On Jul 11, 2008, at 11:08 AM, Noble Paul നോബിള് नोब्ळ् wrote: It is not a recommended practice to expose Solr to the end-users because it is so easy to bring down the server if the user knows that it is a Solr server. We must devise a good mechanism to filter the kind of commands that can be served . If all the request handlers were turned off but a /select constrained to dismax, what vulnerabilities exist? Erik
Re: [jira] Commented: (SOLR-620) Velocity Response Writer
* /update has to be enabled because that is used by the commit script to reload any new snapshots * user firing queries like *:* can cause heavy load on the server (if dismax is the not the only one) --Noble On Fri, Jul 11, 2008 at 10:15 PM, Erik Hatcher [EMAIL PROTECTED] wrote: On Jul 11, 2008, at 11:08 AM, Noble Paul നോബിള് नोब्ळ् wrote: It is not a recommended practice to expose Solr to the end-users because it is so easy to bring down the server if the user knows that it is a Solr server. We must devise a good mechanism to filter the kind of commands that can be served . If all the request handlers were turned off but a /select constrained to dismax, what vulnerabilities exist? Erik -- --Noble Paul
Re: [jira] Commented: (SOLR-620) Velocity Response Writer
On Jul 11, 2008, at 12:56 PM, Noble Paul നോബിള് नोब्ळ् wrote: * /update has to be enabled because that is used by the commit script to reload any new snapshots Even a servlet filter (or fronting web-server*) could turn off /update requests straightforwardely. Filter to allow only internal servers would do the trick, no? * I'm not necessarily proposing jetty be actually talking directly to browsers, but no reason why solr.war need be hidden from them either, providing we iron out whatever /update issues there are. Surely there are other alternative ways a Solr instance can be commanded to pull a new index besides an HTTP request, but I do freely admit that deployment is not my forte. * user firing queries like *:* can cause heavy load on the server (if dismax is the not the only one) That's why I specifically constrained to a reasonable query parser. The runaway query problem is, though, a problem regardless of whether Solr is fronted by another web UI tier or not. One could argue that is the problem of the front-end system to manage, but in reality users are passing queries straight through without massaging, through any number of layers of architecture. So /update is the only concern with Solr itself being a UI server? Erik --Noble On Fri, Jul 11, 2008 at 10:15 PM, Erik Hatcher [EMAIL PROTECTED] wrote: On Jul 11, 2008, at 11:08 AM, Noble Paul നോബിള് नोब्ळ् wrote: It is not a recommended practice to expose Solr to the end-users because it is so easy to bring down the server if the user knows that it is a Solr server. We must devise a good mechanism to filter the kind of commands that can be served . If all the request handlers were turned off but a /select constrained to dismax, what vulnerabilities exist? Erik -- --Noble Paul
Re: [jira] Commented: (SOLR-620) Velocity Response Writer
The front-ends can do some quick and dirty scanning before they fire a query. (Most don't do) still possible. We need a mechanism to filter out queries with some criteria. the /update vulnerability can to be addressed w/ an Apache front ending the server w/ ip based Access control. On Fri, Jul 11, 2008 at 10:38 PM, Erik Hatcher [EMAIL PROTECTED] wrote: On Jul 11, 2008, at 12:56 PM, Noble Paul നോബിള് नोब्ळ् wrote: * /update has to be enabled because that is used by the commit script to reload any new snapshots Even a servlet filter (or fronting web-server*) could turn off /update requests straightforwardely. Filter to allow only internal servers would do the trick, no? * I'm not necessarily proposing jetty be actually talking directly to browsers, but no reason why solr.war need be hidden from them either, providing we iron out whatever /update issues there are. Surely there are other alternative ways a Solr instance can be commanded to pull a new index besides an HTTP request, but I do freely admit that deployment is not my forte. * user firing queries like *:* can cause heavy load on the server (if dismax is the not the only one) That's why I specifically constrained to a reasonable query parser. The runaway query problem is, though, a problem regardless of whether Solr is fronted by another web UI tier or not. One could argue that is the problem of the front-end system to manage, but in reality users are passing queries straight through without massaging, through any number of layers of architecture. So /update is the only concern with Solr itself being a UI server? Erik --Noble On Fri, Jul 11, 2008 at 10:15 PM, Erik Hatcher [EMAIL PROTECTED] wrote: On Jul 11, 2008, at 11:08 AM, Noble Paul നോബിള് नोब्ळ् wrote: It is not a recommended practice to expose Solr to the end-users because it is so easy to bring down the server if the user knows that it is a Solr server. We must devise a good mechanism to filter the kind of commands that can be served . If all the request handlers were turned off but a /select constrained to dismax, what vulnerabilities exist? Erik -- --Noble Paul -- --Noble Paul
