[
https://issues.apache.org/jira/browse/SOLR-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-14285.
------------------------------
Resolution: Not A Problem
We have eliminated the trusted/untrusted concept in solr 10:
[https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-10.html#security]
so I believe this can be close.
> 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.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
