[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310460#comment-17310460
]
Alexey Zotov commented on CASSANDRA-16404:
------------------------------------------
[~brandon.williams], [~blerer]
Could you please assist with triaging this issue. I went through the code and
in general this ticket seems to be clear from technical perspective, but there
are a few points to clarify:
# Despite the use case sounds reasonable to me, does the product ever need
this functionality?
# There are multiple caches (roles, permissions, network auth, credentials,
JMX permissions), but I feel it is enough to invalidate permissions cache only
to handle the use case. Could you please confirm?
# As far as I can see, the invalidation of permissions cache only does not
affect (need for re-login or similar side effects) logged in users. So it is
safe to invalidate the cache and does not bother all users of the system. Could
you please confirm?
# Even though permissions cache invalidation does not affect other users, we
need to provide an optional {{user}} parameter, so the administrator can
invalidate the cache for that particular user rather than for all users.
Thoughts?
# As far as I understand {{nodetool}} is executed on a single node, so the
auth cache invalidation needs to be triggered on all nodes manually. It seems
be slightly inconvenient for the administrator... However, it provides better
control and it is how it is done for all (? not sure) other commands. Is there
a way (concept) to execute such a command on all nodes?
> Provide a nodetool way of invalidating auth caches
> --------------------------------------------------
>
> Key: CASSANDRA-16404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16404
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sumanth Pasupuleti
> Assignee: Sumanth Pasupuleti
> Priority: Normal
> Fix For: 4.x
>
>
> We currently have nodetool commands to invalidate certain caches like
> KeyCache, RowCache and CounterCache.
> Being able to invalidate auth caches as well can come in handy in situations
> where, critical backend auth changes may need to be in effect right away for
> all the connections, especially in configurations where cache validity is
> chosen to be for a longer duration. An example can be that an authenticated
> user "User1" is no longer authorized to access a table resource "table1" and
> it is vital that this change is reflected right away, without having to wait
> for cache expiry/refresh to trigger.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]