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
