What about SolrJS? Isn't it designed to hit a Solr directly? (Sure,
as long as the response looked like Solr response, it could have come
through some magic 'security' tier).
Erik
On Nov 16, 2008, at 5:54 PM, Ryan McKinley wrote:
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