[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315727#comment-17315727
]
Benjamin Lerer commented on CASSANDRA-16404:
--------------------------------------------
Sorry for missing your questions.
{quote} 1. NetworkAuthCache has slightly different naming compared to other
auth caches: a) it has Auth suffix b) it has a "singular name". The naming for
nodetool commands matches class naming exactly. I feel it is the best way to
prevent further confusion in the code. Are we good with that? {quote}
The other option is to rename the cache but I do not know if there is some side
reasons for not doing it.
{quote} 2. I can see that Roles cache has some hierarchical logic for getting
roles and role resources by primary role. Currently I do invalidate only a
single role. Please, let me know if we need to have hierarchical invalidation
logic as well.{quote}
I do not recall exactly how the hierachy work. I would have to double check
that. You can let it like that for now.
{quote} 3. I see that similar nodetool commands do not have tests since they
are pretty simple. Do I need to try to introduce tests here? {quote}
As discussed above: Yes, it would be great.
{quote} 4. Currently three MBean interfaces (NetworkAuth, Permissions and
Roles) were introduced as separate files. Do I need to inline then as per
https://cwiki.apache.org/confluence/display/CASSANDRA2/CodeStyle ?{quote}
No, it is fine if the MBean interfaces are in separate files.
> 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
> Components: Feature/Authorization
> Reporter: Sumanth Pasupuleti
> Assignee: Alexey Zotov
> Priority: Normal
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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]
