I'm not totally sure what you are suggesting. Is there a general way
people deal with security and search?
I'm assuming we already have good ways (better ways) to make sure
people are authorized/logged in etc. What do you imagine "solr
security" would add?
FYI, I used to have a custom RequstHandler that got the user principal
from the HttpServletRequest (I have a custom SolrDispatchFilter that
adds that to the context) and then augments the query with a filter
that limits to stuff that user can see. I replaced all that with a
something that adds the filter to the Solrj query.
Assuming it is "safe" and all that, what do you think we could add
that would be general enough?
ryan
On Nov 16, 2008, at 5:12 PM, Erik Hatcher wrote:
I'm pondering the viability of running Solr as effectively a UI
server... what I mean by that is having a public facing browser-
based application hitting a Solr backend directly for JSON, XML, etc
data.
I know folks are doing this (I won't name names, in case this thread
comes up with any vulnerabilities that would effect such existing
environments).
Let's just assume a typical deployment environment... replicated
Solr's behind a load balancer, maybe even a caching proxy.
What known vulnerabilities are there in Solr 1.3, for example?
What I think we can get out this is a Solr deployment configuration
suitable for direct browser access, but we're not safely there yet
are we? Is this an absurd goal? Must we always have a moving piece
between browser and data/search servers?
Thanks,
Erik
