Re: [jira] Commented: (SOLR-620) Velocity Response Writer

2008-07-11 Thread Noble Paul നോബിള്‍ नोब्ळ्
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 1

Re: [jira] Commented: (SOLR-620) Velocity Response Writer

2008-07-11 Thread Erik Hatcher
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 interna

Re: [jira] Commented: (SOLR-620) Velocity Response Writer

2008-07-11 Thread Noble Paul നോബിള്‍ नोब्ळ्
* /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, 2

Re: [jira] Commented: (SOLR-620) Velocity Response Writer

2008-07-11 Thread Erik Hatcher
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

Re: [jira] Commented: (SOLR-620) Velocity Response Writer

2008-07-11 Thread Noble Paul നോബിള്‍ नोब्ळ्
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) <[EM