my assumption with solrjs is that you are hitting "read-only" solr
servers that you don't mind if people query directly. It would not be
appropriate for something where you don't want people (who really
care) to know you are running solr and could execute arbitrary queries.
Since it is an example, I don't mind leaving the /admin interface open
on:
http://example.solrstuff.org/solrjs/admin/
but /update has a password:
http://example.solrstuff.org/solrjs/update
I have said in the past I like the idea of a "read-only" flag in solr
config that would throw an error if you try to do something with the
UpdateHandler. However there are other ways to do that also.
ryan
On Nov 16, 2008, at 6:03 PM, Erik Hatcher wrote:
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