-
Notifications
You must be signed in to change notification settings - Fork 34
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
feat: Implement public API that will open SpaceBindings to end users through proxy part 2 #350
Conversation
Co-authored-by: Alexey Kazakov <alkazako@redhat.com>
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
…ebining for get, add more tests
# Conflicts: # go.mod # go.sum # pkg/proxy/handlers/spacelister.go
# Conflicts: # go.sum # pkg/proxy/handlers/spacelister.go
/retest |
pkg/proxy/handlers/spacelister.go
Outdated
// let's only log the issue and consider this as not found | ||
ctx.Logger().Error(fmt.Sprintf("expected only 1 spacebinding, got 0 for user %s and workspace %s", userSignup.CompliantUsername, workspaceName)) | ||
return nil, nil | ||
} else if len(userBindings) > 1 { |
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.
Couldn't a user have multiple SpaceBindings in a hierarchy of the spaces? Even if we don't really support it now we could support it in the future, right? Do we really need to make sure there is no than one here?
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.
BTW, aren't we already checking that user has access to the workspace? Do we need to do this additional SpaceBinding check?
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.
Couldn't a user have multiple SpaceBindings in a hierarchy of the spaces? Even if we don't really support it now we could support it in the future, right? Do we really need to make sure there is no than one here?
We could avoid the check, but right now:
allSpaceBindings, err := spaceBindingLister.ListForSpace(space, []toolchainv1alpha1.SpaceBinding{})
at line 117
should return only 1 spacebinding for the given Space and MUR (since it merges them based on the MUR name). So that's why I'm checking that there is no more than one returned from there.
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.
BTW, aren't we already checking that user has access to the workspace? Do we need to do this additional SpaceBinding check?
before those changes there was this function here checking for the binding: https://github.com/codeready-toolchain/registration-service/pull/350/files#diff-cffbabd2ac8378a758970ae247dbee7b644f1d94e702181d836d5d5d19a048c5L88
I've replaced that with filterUserSpaceBindings
which searches for the user binding from the list of all bindings that has already fetched above using the new spaceBindingLister.ListForSpace
.
I don't see any other place where we check if user has access to the workspace 🤷♂️ , but maybe I'm missing something.
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.
before those changes there was this function here checking for the binding:
Ah.. OK. I missed that. So you are replacing the current check with the new one.
/retest |
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.
Looks good. Thanks.
/retest |
Codecov ReportAttention:
📢 Thoughts on this report? Let us know!. |
pkg/proxy/handlers/spacelister.go
Outdated
func filterUserSpaceBindings(username string, allSpaceBindings []toolchainv1alpha1.SpaceBinding) (outputBindings []toolchainv1alpha1.SpaceBinding) { | ||
for _, binding := range allSpaceBindings { | ||
if binding.Spec.MasterUserRecord == username { | ||
outputBindings = append(outputBindings, binding) | ||
} | ||
} | ||
return outputBindings | ||
} |
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 could change it so we wouldn't care about if the user has more than one SpaceBinding. What we care is if the user has access to the Space at all, not about the actual content
func filterUserSpaceBindings(username string, allSpaceBindings []toolchainv1alpha1.SpaceBinding) (outputBindings []toolchainv1alpha1.SpaceBinding) { | |
for _, binding := range allSpaceBindings { | |
if binding.Spec.MasterUserRecord == username { | |
outputBindings = append(outputBindings, binding) | |
} | |
} | |
return outputBindings | |
} | |
func filterUserSpaceBindings(username string, allSpaceBindings []toolchainv1alpha1.SpaceBinding) *toolchainv1alpha1.SpaceBinding { | |
for _, binding := range allSpaceBindings { | |
if binding.Spec.MasterUserRecord == username { | |
return &binding | |
} | |
} | |
return nil | |
} |
I think that it would simplify the code a bit and it wouldn't have any negative impact on the functional aspects.
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.
yes this makes it easier!
I think we would just not be able to report in case there are issues with the system , generating more spacebindings for the same MUR (let's say for whatever reason, a bug in Space controller or SBR controller or other parts of the system like the sandbox-cli ... ). If this is acceptable then yes, the code can be simplified.
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.
as decided earlier today, let's not return this error to the user. I'm not checking only for the user binding as you suggested. Plz check e8eee83
pkg/proxy/handlers/spacelister.go
Outdated
Role: spaceBinding.Spec.SpaceRole, | ||
AvailableActions: []string{}, | ||
} | ||
if name, exists := spaceBinding.GetLabels()[toolchainv1alpha1.SpaceBindingSpaceLabelKey]; exists && name == space.GetName() { |
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 should check the SBR labels instead - if the SpaceBinding was created by the UserSignup controller (as the default SpaceBinding) then the users cannot do anything with it. They can only update/delete those that have corresponding SBR CR in the namespace.
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.
Good point, I think the logic was incorrect here 🤦♂️
I'm now checking for SBR label on the SB resource. Plz take a look mainly at: 64ba7ba
Thanks!
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.
There were actually a few cases missing:
- the case in which there should be no available action, since the spacebinding was generated by the system or system admin
- spacebinding was generated from SBR but on the parentSpace, so in this case it can only be overridden , and not updated/deleted as SBRs generated on the current space.
Please check also 485a52e
pkg/proxy/handlers/spacelister.go
Outdated
// this is a binding that was created on the current space, it can be updated or deleted | ||
binding.AvailableActions = []string{UpdateBindingAction, DeleteBindingAction} |
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.
how does the client (UI) know which SBR it should either update or delete?
I think that the API is missing the bindingRequest
field, right?
https://docs.google.com/document/d/1hWaFvCfsEXrbqs8ndDR0JPjKROXYJkvj1ZCnio4P1WU/edit#bookmark=id.tttpu2pbe4a6
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.
Ohh jeez 🤦♂️ , I missed that field in the original API pr and totally forgot about it! Great catch!
I've raised codeready-toolchain/api#378 for this. And I'm updating this PR and e2e tests to use it!
Thanks!
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'm now populating the bindingRequest
field as well. PTAL at 64ba7ba
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
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.
Looks great, thanks a lot for addressing my comments 👍 🥇 🚀
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alexeykazakov, MatousJobanek, mfrancisc The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
SonarCloud Quality Gate failed. 0 Bugs No Coverage information Catch issues before they fail your Quality Gate with our IDE extension SonarLint |
/retest |
Populate
workspace.Status.Bindings
with the list of usernames, roles and available actions on those usernames.This set of PRs will cover all the remaining work for jira: https://issues.redhat.com/browse/ASC-410
Some followup refactor work will remain only.
Related PRs:
toolchain-common: codeready-toolchain/toolchain-common#329
Paired with:
toolchain-e2e: codeready-toolchain/toolchain-e2e#805