You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Marcus Eagan (Jira)" <ji...@apache.org> on 2019/08/23 15:23:00 UTC
[jira] [Comment Edited] (SOLR-13649) BasicAuth's 'blockUnknown'
param should default to true
[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914342#comment-16914342 ]
Marcus Eagan edited comment on SOLR-13649 at 8/23/19 3:22 PM:
--------------------------------------------------------------
bq. What I was hoping for wrt smooth upgrade was a way to make the default depend on config version. We could have used luceneMatchVersion if this was a per-core config but it is a cluster-wide config so we cannot. I'm not aware of any cluster-wide config version parameter we could use instead. Perhaps a new clusterProperty solrMatchVersion could be of benefit for this and other cluster wide breaking changes. Then if solrMatchVersion is not set you'll assume Version.LATEST, but if it is set to e.g. 8.2 then blockUnknown could default to true as before. Or perhaps better is to introduce a "version" property in security.json that would work much like our schema version property, and we could start on version=2 from Solr9. This is how e.g. docker versions their docker-compose configs. This could be useful in the future if we need to change the very format of security.json to e.g. support multiple auth schemes and backends in the same cluster.
I think that would need to be addressed in another issue or PR that is linked to this one. I can write it, but would prefer the scope not creep on this change.
Great suggestion, though, although I feel like containers seem to address a lot of this version checking
was (Author: marcussorealheis):
bq. What I was hoping for wrt smooth upgrade was a way to make the default depend on config version. We could have used luceneMatchVersion if this was a per-core config but it is a cluster-wide config so we cannot. I'm not aware of any cluster-wide config version parameter we could use instead. Perhaps a new clusterProperty solrMatchVersion could be of benefit for this and other cluster wide breaking changes. Then if solrMatchVersion is not set you'll assume Version.LATEST, but if it is set to e.g. 8.2 then blockUnknown could default to true as before. Or perhaps better is to introduce a "version" property in security.json that would work much like our schema version property, and we could start on version=2 from Solr9. This is how e.g. docker versions their docker-compose configs. This could be useful in the future if we need to change the very format of security.json to e.g. support multiple auth schemes and backends in the same cluster.
I think that would need to be addressed in another issue or PR that is linked to this one. I can write it, but would prefer the scope not creep on this change.
> BasicAuth's 'blockUnknown' param should default to true
> -------------------------------------------------------
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI, Authentication, security
> Affects Versions: 7.7.2, 8.1.1
> Environment: All
> Reporter: Marcus Eagan
> Priority: Major
> Labels: Authentication
> Fix For: master (9.0)
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the {{blockUnknown}} parameter, the default value is {{false}}. That default behavior is a bit counterintuitive because if someone wishes to enable basic authentication, you would expect that they would want all unknown users to need to authenticate by default. I can imagine cases where you would not, but those cases would be less frequent.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org