ui: Ensure we check intention service prefix permissions for per service #11409
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ice (#11270) * ui: Ensure we check intention service prefix permissions for per service Previously, when showing some action buttons for 'per service intentions' we used a global 'can I do something with any intention' permission to decide whether to show a certain button or not. If a user has a token that does not have 'global' intention permissions, but does have intention permissions on one or more specific services (for example via service / service_prefix), this meant that we did not show them certain buttons required to create/edit the intentions for this specific service. This PR adds that extra permissions check so we now check the intentions permissions per service instead of using the 'global' "can I edit intentions" question/request. **Notes:** - If a HTML button is `disabled` this means tippy.js doesn't adopt the popover properly and subsequently hide it from the user, so aswell as just disabling the button so you can't active the popover, we also don't even put the popover on the page - If `ability.item` or `ability.item.Resources` are empty then assume no access **We don't try to disable service > right hand side intention actions here** Whether you can create intentions for a service depends on the _destination_ of the intention you would like to create. For the topology view going from the LHS to the center, this is straightforwards as we only need to know the permissions for the central service, as when you are going from the LHS to the center, the center is the _destination_. When going from the center to the RHS the _destination[s]_ are on the RHS. This means we need to know the permissions for potentially 1000s of services all in one go in order to know when to show a button or not. We can't realistically discover the permissions for service > RHS services as we'd have either make a HTTP request per right hand service, or potentially make an incredibly large POST request for all the potentially 1000s of services on the right hand side (more preferable to 1000s of HTTP requests). Therefore for the moment at least we keep the old functionality (thin client) for the middle to RHS here. If you do go to click on the button and you don't have permissions to update the intention you will still not be able to update it, only you won't know this until you click the button (at which point you'll get a UI visible 403 error)
So this make 100% sense that the port is different here to 1.11
|
🍒 If backport labels were added before merging, cherry-picking will start automatically. To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/493592. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Port of #11270