[
https://issues.apache.org/jira/browse/SOLR-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159394#comment-17159394
]
Cassandra Targett commented on SOLR-14285:
------------------------------------------
bq. There is a workaround, just upload a configset that contains lib directive
and edit the data for the znode from trusted=false to true. Is this not
sufficient for dev purposes?
It would be, but where is this workaround documented?
> Trusted configset limitations should be relaxed in some circumstances
> ---------------------------------------------------------------------
>
> Key: SOLR-14285
> URL: https://issues.apache.org/jira/browse/SOLR-14285
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
> Affects Versions: 8.4, 8.4.1
> Reporter: Cassandra Targett
> Priority: Major
> Attachments: SOLR-14285-wip.patch
>
>
> The changes in SOLR-6736 mean that as of 8.4, a configset that includes <lib>
> directives will only work if Solr has authentication configured.
> I think we should be able to disable this (on by default) - in dev
> environments, setting up authentication may be overly onerous and an obstacle
> to getting started. These environments can already be well-protected by
> internal firewalls if Solr does not yet need to be accessed.
> Another way that change complicates things is on upgrades. Having your entire
> Solr break only because you have not enabled authc (and maybe you don't
> intend to) and used the default configset is a really poor user experience.
> Similarly, the REINDEXCOLLECTION command copies an existing configset for the
> new collection that it creates while reindexing the documents from a source
> collection. When {{async=false}}, any errors are swallowed making it
> difficult to know this restriction is the cause. I think it would be fair for
> a user to assume that because the configset was already in use that copying
> it to a new collection should be OK (more of an internal thing than a new
> upload).
> Maybe some of this is just a problem for users trying to go from 8.3 to 8.4,
> but it's creating a rather messy & painful upgrade experience. I still think
> it would be worth being able to disable the check with a startup param
> (something like {{-Ddisable.lib.restriction=true}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
