On Nov 17, 2008, at 9:07 AM, Yonik Seeley wrote:
On Mon, Nov 17, 2008 at 8:54 AM, Erik Hatcher
<[EMAIL PROTECTED]> wrote:
Sounds like the perfect case for a query parser plugin... or use
dismax as
Ryan mentioned. Shouldn't Solr be hardened for these cases
anyway? Or at
least hardenable.
Say you do filtering by user - how would you enforce that the client
(if it's a browser) only send in the proper filter?
Ryan already mentioned his technique... and here's how I'd do it
similarly...
Write a custom servlet Filter that grokked roles/authentication
(this piece you'd need in any Java application tier anyway) [or plugin
in an existing implementation through Spring or something like that]
And then massaging of the request to Solr could happen in that
pipeline, or adding a query parameter to the Solr request (ignoring
anything sent by the client request for say, &user=...). Perhaps plug
in a custom SearchComponent that massaged a request parameter into a
Solr filter query or whatever.
Doesn't seem like
you can unless you put all the user authentication stuff and
application logic right in Solr.
;)
Exactly. Sort of.
Now I guess you *could* stick everything in Solr that you would
normally stick in the middle tier, but it doesn't seem like a great
idea to me.
Let's be clear about where we are drawing the boundaries of the
definition of "Solr".
One could say that Solr is solr.war and the HTTP conventions. Or is
it solr.jar? Or is it the SolrJ API?
Erik
