Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: Implement public API that will open SpaceBindings to end users through proxy part 2 #350
Changes from 19 commits
49aa7e79e08eceb6a4d8f44eee9dc3639a3f333b613eeb8fd9278a66cc77790e83efa41305bcfdb915bf0175925a1507b301124e847042690b72c665e393f37130609e3d2fec9160b2e418ef6a64ba7ba31c54dd485a52ee8eee83075917a3e1a9d0819cd5f6ae41cce433e7f7da2560105c90aFile filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 110 in pkg/proxy/handlers/spacelister.go
pkg/proxy/handlers/spacelister.go#L109-L110
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.
We could avoid the check, but right now:
allSpaceBindings, err := spaceBindingLister.ListForSpace(space, []toolchainv1alpha1.SpaceBinding{})at line 117should 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.
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
filterUserSpaceBindingswhich searches for the user binding from the list of all bindings that has already fetched above using the newspaceBindingLister.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.
Ah.. OK. I missed that. So you are replacing the current check with the new one.
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
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
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:
Please check also 485a52e
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
bindingRequestfield, 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
bindingRequestfield as well. PTAL at 64ba7ba