On 6/24/2015 4:16 AM, Alessandro Benedetti wrote:
> related that I noticed that a lot of times, a developer would need an
> intermediate API that will proxy the Search UI requests to Solr.
> 
> Of course there are scenarios where is necessary to build this intermediate
> API ( for example if you customise how the results must be processed after
> Solr returns them) .
> But sometimes it can happen a straightforward communication from the UI to
> Solr using the REST endpoints provided .
> 
> In your opinion, does make any sense to provide the intermediate Search API
> in simple use cases as well ?
> Doing that, aren't we introducing  scalability issues/ delay in query time ?
> 
> I always thought the intermediate Rest API to be necessary, but day by day,
> Solr REST API are becoming more and more complete.
> 
> To refer to the the user mail, maybe he can simply use Solr REST endpoints.
> But what about production environments ?

Solr's REST-like interface is indeed becoming more and more complete ...
which is part of the problem.  It's a bad idea to expose Solr directly
to end users, because as Erick said, users with direct access to Solr
can wipe out your index, change it in subtle ways, and access things you
may not have wanted them to access.  When we add another feature to Solr
that allows administrators to modify the Solr config or index, it makes
end-user access that much more dangerous.

Even if you implement a proxy for Solr that blocks access to the admin
UI and the update handler, a user can still craft queries with enough
complexity to keep the Solr server busy and cause denial of service.
Configuring a proxy for that role requires time, which might be better
spent on an intermediate UI.

Chances are that if you're building a website, you're going to invest
heavily in writing a user interface, part of which will run on the
server side.  It might be in a language like PHP, Ruby, or Java.  Adding
Solr support to such an interface is normally pretty easy, because Solr
clients are available for several languages that are commonly used for
website design.

https://wiki.apache.org/solr/IntegratingSolr

A modern interface will include plenty of Javascript, which runs in the
user's browser, but I expect that the sensitive parts will run
server-side.  As an example, there are Solr plugins available for
applications like Wordpress and Drupal.  Those plugins are server-side
code, and do not require end-user access to Solr.

Thanks,
Shawn

Reply via email to