Welp. Never mind I refer back to point #1 this is a bad idea
> On Oct 8, 2020, at 3:01 PM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > > The update handlers are now implicitly defined (3 or 4 of them). So, > it actually needs to be explicitly shadowed and overridden with other > Noop handler. And block Config API to avoid attackers creating new > handlers. > > Regards, > Alex. > >> On Thu, 8 Oct 2020 at 14:54, David Hastings <dhasti...@wshein.com> wrote: >> >> Well that’s why I suggested deleting the update handler :) >> >>>> On Oct 8, 2020, at 2:52 PM, Walter Underwood <wun...@wunderwood.org> wrote: >>> >>> Let me know where it is and I’ll delete all the documents in your >>> collection. >>> It is easy, just one HTTP request. >>> >>> https://gist.github.com/nz/673027/313f70681daa985ea13ba33a385753aef951a0f3 >>> >>> wunder >>> Walter Underwood >>> wun...@wunderwood.org >>> http://observer.wunderwood.org/ (my blog) >>> >>>> On Oct 8, 2020, at 11:49 AM, Alexandre Rafalovitch <arafa...@gmail.com> >>>> wrote: >>>> >>>> I think there were past discussions about people doing but they really >>>> really knew what they were doing from a security perspective, not just >>>> Solr one. >>>> >>>> You are increasing your risk factor a lot, so you need to think >>>> through this. What are you protecting and what are you exposing. Are >>>> you trying to protect the updates? You may be able to do it with - for >>>> example - read-only docker container, or with embedded Solr or/and >>>> with reverse proxy. >>>> >>>> Are you trying to protect some of the data from being read? Even harder. >>>> >>>> There are implicit handlers, admin handlers, 'qt' to select query >>>> parser, etc. Lots of things to think about. >>>> >>>> It just may not be worth it. >>>> >>>> Regards, >>>> Alex. >>>> >>>> >>>>> On Thu, 8 Oct 2020 at 14:27, Marco Aurélio <aurelio.marco...@gmail.com> >>>>> wrote: >>>>> >>>>> Hi! >>>>> >>>>> We're looking into the option of setting up search with Solr without an >>>>> intermediary application. This would mean our backend would index data >>>>> into >>>>> Solr and we would have a public Solr endpoint on the internet that would >>>>> receive search requests directly. >>>>> >>>>> Since I couldn't find an existing solution similar to ours, I would like >>>>> to >>>>> know whether it's possible to secure Solr in a way that allows anyone only >>>>> read-access only to collections and how to achieve that. Specifically >>>>> because of this part of the documentation >>>>> <https://lucene.apache.org/solr/guide/8_5/securing-solr.html>: >>>>> >>>>> *No Solr API, including the Admin UI, is designed to be exposed to >>>>> non-trusted parties. Tune your firewall so that only trusted computers and >>>>> people are allowed access. Because of this, the project will not regard >>>>> e.g., Admin UI XSS issues as security vulnerabilities. However, we still >>>>> ask you to report such issues in JIRA.* >>>>> Is there a way we can restrict read-only access to Solr collections so as >>>>> to allow users to make search requests directly to it or should we always >>>>> keep our Solr instances completely private? >>>>> >>>>> Thanks in advance! >>>>> >>>>> Best regards, >>>>> Marco Godinho >>>
