Skip to content
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.

Sign up for GitHub

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

Jump to bottom

ui: Ensure we check intention service prefix permissions for per service #11409

Merged
merged 4 commits into from
Nov 4, 2021
Merged

ui: Ensure we check intention service prefix permissions for per service #11409

merged 4 commits into from
Nov 4, 2021

Commits on Oct 25, 2021

  1. ui: Ensure we check intention service prefix permissions for per serv… 

    …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)
    @johncowen
    johncowen authored and John Cowen committed Oct 25, 2021
    Configuration menu
    Copy the full SHA
    f626042 View commit details
    Browse the repository at this point in the history

  2. Changelog

    John Cowen committed Oct 25, 2021
    Configuration menu
    Copy the full SHA
    57e0c63 View commit details
    Browse the repository at this point in the history

  3. Lint

    John Cowen committed Oct 25, 2021
    Configuration menu
    Copy the full SHA
    5659091 View commit details
    Browse the repository at this point in the history

  4. We reversed the conditional here between 1.10 and 1.11 

    So this make 100% sense that the port is different here to 1.11
    John Cowen committed Oct 25, 2021
    Configuration menu
    Copy the full SHA
    ee266c7 View commit details
    Browse the repository at this point in the history