when fetching groups, capture error 403 as rbac failure and cache result

[christianvogt]

Closes: #1317

Description

As part of a normal flow, /api/k8s/apis/user.openshift.io/v1/groups is queried from the project details page. There was however a check in place where this call was skipped if useUser().isAdmin === true. Instead of using this check, we ought to be checking rbac. If the user has permissions to get a resource, we should let them. By simply removing this check we now have to handle error 403. Or we could perform a self subject access review prior to making the call. I've opted to handle the 403 request as it provides the same feed back as first performing a self subject access review check. useAccessReview is a utility that can be used know if a user has permissions to perform an action. This utility would cache the result such that no further network calls are performed to get the same result. This means if a user is visiting a page and their permissions change in the process, they would require a refresh of the page / component to retrieve the new permissions. As such I have implemented a cache in useGroups when an error 403 occurs to mimic the same functionality.

No visible UI changes.

How Has This Been Tested?

1. Be an admin, not a cluster-admin
2. Create a DS Project (or be shared one, as admin)
3. Navigate to the permissions tab inside the Project details
4. If you have access to groups -- you should see a dropdown for the group section, if you don't you will just have a text input
5. Using web inspector, check the network tab for calls to the /api/k8s/apis/user.openshift.io/v1/groups endpoint.
6. If the call is successful 200, subsequent calls will be made every time POLL_INTERVAL ticks (30s).
7. If the call is error 403, subsequent calls will not be made.

Test Impact

A followup PR with unit tests will be contributed.

Request review criteria:

Self checklist (all need to be checked):

• The developer has manually tested the changes and verified that the changes work
• Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

• Included any necessary screenshots or gifs if it was a UI change.
• Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

• The developer has tested their solution on a cluster by using the image produced by the PR to main

[openshift-ci]

Hi @christianvogt. Thanks for your PR.

I'm waiting for a opendatahub-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[andrewballantyne]

/ok-to-test

[andrewballantyne]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewballantyne

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:

• OWNERS [andrewballantyne]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Gkrumbach07]

/lgtm