You rock Shawn, thanks! Some follow up questions.
Using our existing Apache, or AWS setup, could we prevent those complex/slow
denial of service queries?
Could we use the same setup to only allow our JavaScript ajax calls direct
access or is a light API layer required, and we then lock down Solr to only
allow access from that light API layer?
Do you have examples of common architecture setups (a picture or blog post for
example)?
On 5/24/17, 5:39 PM, "Shawn Heisey" <apa...@elyograg.org> wrote:
On 5/24/2017 2:08 PM, Warden, Jesse wrote:
> We don’t want people modifying Solr on our website. We found this plugin:
https://home.apache.org/~ctargett/RefGuidePOC/jekyll-full/basic-authentication-plugin.html#BasicAuthenticationPlugin-EnableBasicAuthentication
>
> However, if someone goes to search on our website, they’re presented with
an authentication dialogue. We want our normal users to be able to perform
searches, just none of the admin actions.
The admin UI is just static html, css, images, and javascript. It does
not contain any information about your Solr server. The admin UI itself
runs in the browser, and its components do not require authentication
when you enable authentication.
It is the Solr request API, which includes searches, information
requests, and indexing, that actually gets authenticated. This API is
accessed by the admin UI running in the browser in order to display
information about the server and enable admin actions.
Your end users should *NOT* have direct access to your Solr server. It
sounds like what you have done is put your calls to Solr into javascript
which executes in the end user's browser, and exposed your Solr server
to your users (which may be the entire Internet). This is a problem.
The searches should be executed by back-end code running on your
webserver, not by javascript code running in the user's browser.
If you put a proxy server in front of Solr, you may be able to block
certain URL path combinations and prevent the end users from changing
your indexes, but you will not be able to prevent those users from
sending complex/slow denial of service queries.
Thanks,
Shawn
________________________________________________________
The information contained in this e-mail is confidential and/or proprietary to
Capital One and/or its affiliates and may only be used solely in performance of
work or services for Capital One. The information transmitted herewith is
intended only for use by the individual or entity to which it is addressed. If
the reader of this message is not the intended recipient, you are hereby
notified that any review, retransmission, dissemination, distribution, copying
or other use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error, please
contact the sender and delete the material from your computer.
