[jira] [Updated] (SOLR-14285) Trusted configset limitations should be relaxed in some circumstances

["Andras Salamon (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andras Salamon updated SOLR-14285:
----------------------------------
    Attachment: SOLR-14285-wip.patch

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org