You just needed a standard interface that abstracts out storing files
(ZK/File system)
On Thu, Aug 20, 2020 at 6:02 PM Matthias Krueger wrote:
>
>
> I don't use ManagedResourceStorage, just the StorageIO interface and its
> implementations. The benefit is ZK AND filesystem support for WRITING
> c
I don't use ManagedResourceStorage, just the StorageIO interface and its
implementations. The benefit is ZK AND filesystem support for WRITING
configuration file updates. Otherwise I would have to come up with
something like the common interface (StorageIO), its implementations for
ZK and FS and
ZkMaintenanceUtils has the basic file manipulations between Zk and “someplace
else”,
although it’s pretty much file based. Does that have any bearing on the problem?
> On Aug 19, 2020, at 2:49 AM, Noble Paul wrote:
>
> So, it's not very different from directly reading a file from ZK?
>
> what
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 wrote:
>
>
> In a custom SolrRequestHandler#handleRequest something like this:
>
> final ManagedResourceStorage.
In a custom SolrRequestHandler#handleRequest something like this:
final ManagedResourceStorage.StorageIO storageIO =
ManagedResourceStorage.newStorageIO(core.getCoreDescriptor().getCollectionName(),
resourceLoader, new NamedList<>());
And then using
storageIO.op
>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
>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 wrote:
>
>
> As authentication is plugged into the Solr
I imagine that some users have build custom UIs to manage stopwords or synonyms
over REST instead of having to copy files to Solr or Zookeeper.
Question is whether to try improve the security of the APIs, or disable them by
default and document the limitations related to using them, which could b
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 scena
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
wrote:
> Hey Noble,
>
> Can you explain what you mean when you say it's not secured? Just for
> those of u
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 abo
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
12 matches
Mail list logo
