So, it's not very different from directly reading a file from ZK?

what benefit do you get by using the ManagedResourceStorage?

On Sun, Aug 16, 2020 at 7:08 PM Matthias Krueger <m...@mkr.io> wrote:
>
>
> In a custom SolrRequestHandler#handleRequest something like this:
>
>         final ManagedResourceStorage.StorageIO storageIO =
> ManagedResourceStorage.newStorageIO(core.getCoreDescriptor().getCollectionName(),
>                 resourceLoader, new NamedList<>());
>
> And then using
>
>         storageIO.openOutputStream(resourceName)
>
> to store some (well-known) resources.
>
> Matt
>
>
> On 15.08.20 11:38, Noble Paul wrote:
> >> 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.
> > Can you give us some more details on how you use it?
> >
> > On Sat, Aug 15, 2020 at 7:32 PM Noble Paul <noble.p...@gmail.com> wrote:
> >>> 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
>


-- 
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to