[
https://issues.apache.org/jira/browse/SOLR-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159348#comment-17159348
]
Ishan Chattopadhyaya commented on SOLR-14285:
---------------------------------------------
The system info handler and the Solr admin ui can now inform the user if
authentication and authorisation is enabled or not.
> 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
