[
https://issues.apache.org/jira/browse/SOLR-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905705#comment-16905705
]
Shawn Heisey commented on SOLR-13464:
-------------------------------------
I'm thinking maybe if the security.json had a place for a serial number,
similar to DNS, then the auth API could indicate the serial number of config
that has been fully initialized. When the config is changed via the API,
advance the serial number, and recommend in the docs that users do the same
when making changes themselves.
Or is that just ugly?
> no way for external clients to detect when changes to security config have
> taken effect
> ---------------------------------------------------------------------------------------
>
> Key: SOLR-13464
> URL: https://issues.apache.org/jira/browse/SOLR-13464
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Priority: Major
>
> The basic functionality of the authorization/authentication REST APIs works
> by persisting changes to a {{security.json}} file in ZooKeeper which is
> monitored by every node via a Watcher. When the watchers fire, the affected
> plugin types are (re)-initialized ith the new settings.
> Since this information is "pulled" from ZK by the nodes, there is a (small)
> inherent delay between when the REST API is hit by external clients, and when
> each node learns of the changes. An additional delay exists as the config is
> "reloaded" to (re)initialize the plugins.
> Practically speaking these delays have very little impact on a "real" solr
> cloud cluster, but they can be problematic in test cases -- while the
> SecurityConfHandler on each node could be used to query the "current"
> security.json file, it doesn't indicate if/when the plugins identified in the
> "current" configuration are fully in use.
> For now, we have a "white box" work around available for MiniSolrCloudCluster
> based tests by comparing the Plugins of each CoreContainer in use before and
> after making known changes via the API (see commits identified below).
> This issue exists as a placeholder for future consideration of UX/API
> improvements making it easier for external clients (w/o "white box" access to
> solr internals) to know definitively if/when modified security settings take
> effect.
> {panel:title=original jira description}
> I've been investigating some sporadic and hard to reproduce test failures
> related to authentication in cloud mode, and i *think* (but have not directly
> verified) that the common cause is that after uses one of the
> {{/admin/auth...}} handlers to update some setting, there is an inherient and
> unpredictible delay (due to ZK watches) until every node in the cluster has
> had a chance to (re)load the new configuration and initialize the various
> security plugins with the new settings.
> Which means, if a test client does a POST to some node to add/change/remove
> some authn/authz settings, and then immediately hits the exact same node (or
> any other node) to test that the effects of those settings exist, there is no
> garuntee that they will have taken affect yet.
> {panel}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
