-
Notifications
You must be signed in to change notification settings - Fork 182
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
frontend: KubeObject: Refactor getAuthorization logic #2654
base: main
Are you sure you want to change the base?
Conversation
e7d7491
to
e7e9a0c
Compare
2150ef0
to
f86d8b4
Compare
f86d8b4
to
b2cf3ce
Compare
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.
@skoeva Do we always need to set the group + version + resource when checking for permissions? I think the original logic was "check if we are checking permissions with e.g. the resource, if so, use this API version's one instead", in these changes it does: "even if we were not testing permissions using the resource, will just set it".
Are we sure this is the right approach? We ought to test variants of these calls.
@joaquimrocha I think it would be fitting to have a complete resource to evaluate permissions for, no? The issue before was that the object was incomplete and therefore we were unable to check for its permissions. In what case would we prefer an incomplete object? |
I just saying the nature of how we were checking things was more of |
@joaquimrocha The code comments suggest that the changes made in this PR are more in line with the intended logic here: Not sure if the original logic makes much sense in this case |
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 think you may have a point, now that look at this with fresher eyes. I think if that's the case, then the previous logic is indeed wrong, but seems like we're possibly mixing things (mixing the group
from an API version with version
from another), so maybe what we need to do is to use the full apiName + apiVersion here instead.
In either case, I'd kindly ask you to test this function and understand what happens when e.g. you add newer+fictitious apiVersion to a resource, and test this function (and the instances' getAuthorization), to simulate falling back to a working version.
b2cf3ce
to
5ccb37c
Compare
5ccb37c
to
6a2e664
Compare
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. Only a comment that should be deleted as it no longer makes sense.
f785705
to
8a31aeb
Compare
This change assigns the apiName (rather than the less descriptive pluralName) when the resource name is missing. Signed-off-by: Evangelos Skopelitis <[email protected]>
This change updates the logic of the getAuthorization function in KubeObject, which previously intended to test auth by separating the group from its respective version when one of these was missing. Now, these two fields are linked and grabbed together from apiInfo when one is missing. Fixes: #2633 Signed-off-by: Evangelos Skopelitis <[email protected]>
8a31aeb
to
cf5b206
Compare
This change updates the logic of the
getAuthorization
function in KubeObject, which previously intended to test auth by separating the group from its respective version when one of these was missing. Now, these two fields are linked and grabbed together from apiInfo when one is missing. A change for assigning theapiName
(rather than the less descriptivepluralName
) when the resource name is missing was also included.Fixes: #2633
Testing