Erik Hatcher wrote:

On Nov 16, 2008, at 5:41 PM, Ian Holsman wrote:
First thing I would look at is disabling write access, or writing a servlet that sits on top of the write handler to filter your data.

We can turn off all the update handlers, but how does that affect replication? Can a Solr replicant be entirely read-only in the HTTP request sense?

Second thing I would be concerned about is people writing DoS queries that bypass the cache.


so you may need to write your own custom request handler to filter out that kind of thing.

Is this a concern that can be punted to what you'd naturally be putting in front of Solr anyway or a proxy tier that can have DoS blocking rules? I mean, if you're deploying a Struts that hits Solr under the covers, how do you prevent against DoS on that? A malicious user could keep sending queries indirectly to a Solr through a whole lot of public apps now. In other words, another tier in front of Solr doesn't add (much) to DoS protection to an underlying Solr, no?

famous last words and all, but you shouldn't be just passing what a user types directly into a application should you?

I'd be parsing out wildcards, boosts, and fuzzy searches (or at least thinking about the effects). I mean "jakarta apache"~1000 or roam~0.1 aren't as efficient as a regular query.

but they don't let me into design meetings any more ;(
    Erik



Reply via email to