[ 
https://issues.apache.org/jira/browse/SOLR-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246605#comment-17246605
 ] 

David Maicher edited comment on SOLR-14285 at 12/9/20, 3:29 PM:
----------------------------------------------------------------

This is also something that currently keeps me from moving to SOLR 8.4.

In my case for dev + test environments I don't want to use this "change the 
trusted flag in ZK" workaround since my app has no idea about Zookeeper but 
just talks to the solr cluster via the upload config API. Also enabling for 
example HTTP basic authentication seems not so straightforward in cloud mode. I 
would need to upload some security.json thing into ZK, or?

Also for production I don't want to enable any authentication because its 
pointless really. The SOLR cluster is not publicly reachable but rather only 
reachable within the internal network of the app server infrastructure.

So its a bit painful as of now and some way of disabling this new security 
mechanism would be much appreciated.


was (Author: dmaicher):
This is also something that currently keeps me from moving to SOLR 8.4.

In my case for dev + test environments I don't want to use this "change the 
trusted flag in ZK" workaround since my app has no idea about Zookeeper but 
just talks to the solr cluster via the upload config API.

Also for production I don't want to enable any authentication because its 
pointless really. The SOLR cluster is not publicly reachable but rather only 
reachable within the internal network of the app server infrastructure.

So its a bit painful as of now and some way of disabling this new security 
mechanism would be much appreciated.

> 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

Reply via email to