-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[improve][broker] Support revoking permission for AuthorizationProvider #20456
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the help. overall lgtm. Added some minor comments.
* @param role | ||
* @return | ||
*/ | ||
default CompletableFuture<Void> revokePermissionAsync(NamespaceName namespace, String role) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a default implementation here? How about removing it so that we can keep aligned with other APIs in this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s better to have default
implementations here, otherwise it will cause compile issue when upgrade.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, also the "revoke" is already broken today when using a custom authz plugin. Even if today it succeeds, the revoke does nothing because it would just try to remove the ACL from zookeeper, where there are not any.
...roker-common/src/main/java/org/apache/pulsar/broker/authorization/AuthorizationProvider.java
Outdated
Show resolved
Hide resolved
...common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java
Outdated
Show resolved
Hide resolved
* @return CompletableFuture<Void> | ||
*/ | ||
default CompletableFuture<Void> revokePermissionAsync(NamespaceName namespace, String role) { | ||
return FutureUtil.failedFuture(new IllegalStateException( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe java.lang.UnsupportedOperationException
is more suitable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd better keep the same exception as with other default implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree.
I have the same question as jiazhai if the default method is return CompletableFuture with Exception. |
I may not get what you mean. Earlier version won't fail |
* @param role | ||
* @return | ||
*/ | ||
default CompletableFuture<Void> revokePermissionAsync(NamespaceName namespace, String role) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, also the "revoke" is already broken today when using a custom authz plugin. Even if today it succeeds, the revoke does nothing because it would just try to remove the ACL from zookeeper, where there are not any.
Sorry for my misunderstanding comments. I mean that if previous version user-define AuthorizationProvider didn't override the default method. when user call the admin api and execute the default method. will it be failed ? like |
Ah, yes, it will fail in this case |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #20456 +/- ##
============================================
- Coverage 72.95% 72.91% -0.04%
- Complexity 31914 31916 +2
============================================
Files 1867 1867
Lines 138485 138522 +37
Branches 15202 15204 +2
============================================
- Hits 101037 101009 -28
- Misses 29438 29503 +65
Partials 8010 8010
Flags with carried forward coverage won't be shown. Click here to find out more.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@Technoboy- It looks like you will create another PR to make sure all the revoking calls point to the newly added method, right?
yes, right. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I support this API expansion. It would have been nice to send a notice to the private or dev list, though. Thanks.
@Technoboy- - one important detail that we should also cover is the fact that all of the "get permission" endpoints make the assumption that the permissions are stored in zk. We should probably expand the |
I think these might be trickier to support. Many backends would not be able to answer that question directly (or at least the broker might not have access to it). |
That's fair, but I think it might make sense to let the interface's implementation decide how to handle that instead of reading potentially irrelevant information from the metadata store. I don't think it has to be fixed along with this PR, but in my opinion, that is the right direction. |
Sure, it makes sense. Right now it's anyway broken when it returns an empty list |
Motivation
Current AuthorizationProvider does not actually fully support the revocation of ACLs :
Documentation
doc
doc-required
doc-not-needed
doc-complete