>As authentication is plugged into the SolrDispatchFilter I would assume that >you would need to be authenticated to read/write Managed Resources
I'm talking about the authorization plugins On Fri, Aug 14, 2020 at 10:20 PM Matthias Krueger <m...@mkr.io> wrote: > > > As authentication is plugged into the SolrDispatchFilter I would assume that > you would need to be authenticated to read/write Managed Resources but no > authorization is checked (i.e. any authenticated user can read/write them), > correct? > > Anyway, I came across Managed Resources in at least two scenarios: > > The LTR plugin is using them for updating model/features. > I use MangedResource#StorageIO and its implementations as a convenient way to > abstract away the underlying config storage when creating plugins that need > to support both, SolrCloud and Solr Standalone. > > IMO an abstraction that allows distributing configuration (ML models, > configuration snippets, external file fields...) that exceeds the typical ZK > size limits to SolrCloud while also supporting Solr Standalone would be nice > to have. > > Matt > > > On 12.08.20 02:08, Noble Paul wrote: > > The end point is served by restlet. So, your rules are not going to be > honored. The rules work only if it is served by a Solr request handler > > On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski <gerlowsk...@gmail.com> wrote: >> >> Hey Noble, >> >> Can you explain what you mean when you say it's not secured? Just for >> those of us who haven't been following the discussion so far? On the >> surface of things users taking advantage of our RuleBasedAuth plugin >> can secure this API like they can any other HTTP API. Or are you >> talking about some other security aspect here? >> >> Jason >> >> On Tue, Aug 11, 2020 at 9:55 AM Noble Paul <noble.p...@gmail.com> wrote: >> > >> > Hi all, >> > The end-point for Managed resources is not secured. So it needs to be >> > fixed/eliminated. >> > >> > I would like to know what is the level of adoption for that feature >> > and if it is a critical feature for users. >> > >> > Another possibility is to offer a replacement for the feature using a >> > different API >> > >> > Your feedback will help us decide on what a potential solution should be >> > >> > -- >> > ----------------------------------------------------- >> > Noble Paul -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
