feat: client side access control (WIP) #27174
Conversation
| @@ -46,6 +61,13 @@ export const apiStatusLogic = kea<apiStatusLogicType>([ | |||
| const data = await response?.json() | |||
| if (data.detail === 'This action requires you to be recently authenticated.') { | |||
| actions.setTimeSensitiveAuthenticationRequired(true) | |||
| } else if (data.code === 'permission_denied') { | |||
| // TODO - only do if the RBAC feature flag is enabled | |||
There was a problem hiding this comment.
importing feature flag logic here is breaking this logic so haven't figured out this check yet
| if (featureFlags[FEATURE_FLAGS.ROLE_BASED_ACCESS_CONTROL]) { | ||
| return true | ||
| // TODO: figure out how to access this method | ||
| // return hasResourceAccess({ userAccessLevel: dashboard.user_access_level, requiredLevels: ['admin', 'editor'] }) |
There was a problem hiding this comment.
Need to figure out how to access access control logic hasResourceAccess
| if (featureFlags[FEATURE_FLAGS.ROLE_BASED_ACCESS_CONTROL]) { | ||
| return true | ||
| // TODO: figure out how to access this method | ||
| // return hasResourceAccess({ userAccessLevel: insight.user_access_level, requiredLevels: ['admin', 'editor'] }) |
There was a problem hiding this comment.
Need to figure out how to access access control logic hasResourceAccess
zlwaterfield
requested review from
aspicer,
Twixes,
dmarticus,
daibhin,
neilkakkar,
EDsCODE,
benHPostHog and
benjackwhite
and removed request for
benHPostHog
|
Size Change: +1.27 kB (+0.01%) Total Size: 9.44 MB
|
zlwaterfield
changed the title
|
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
| @@ -39,7 +39,7 @@ export function AccessControlObject(props: AccessControlLogicProps): JSX.Element | |||
| return ( | |||
| <BindLogic logic={accessControlLogic} props={props}> | |||
| <div className="space-y-6"> | |||
| {canEditAccessControls === true ? ( | |||
| {canEditAccessControls === false ? ( | |||
There was a problem hiding this comment.
This was a bug I shipped on another PR.
| @@ -46,6 +61,13 @@ export const apiStatusLogic = kea<apiStatusLogicType>([ | |||
| const data = await response?.json() | |||
| if (data.detail === 'This action requires you to be recently authenticated.') { | |||
| actions.setTimeSensitiveAuthenticationRequired(true) | |||
| } else if (data.code === 'permission_denied') { | |||
There was a problem hiding this comment.
This is not fool proof because it looks at all requests and I only really want to look at specific ones.
zlwaterfield
removed request for
aspicer,
Twixes,
dmarticus,
daibhin,
neilkakkar,
EDsCODE,
benjackwhite and
a team
|
Going to close this and split into multiple PRs because it got bigger than expected. |
Changes
(this is still a WIP but wanted feedback on the implementation so far)
Follow along with all RBAC changes here: #24512
This PR is starting to layer on the client side access control changes. This PR is trying to layer on these changes without affecting this current experience. The main goal is to block access to actions where the user does not have access (editing, renaming, deleting, etc.). The API handles all this but we want the client to properly render what actions the user has access to.
It includes
AccessControlActionwrapper component to make the experience consistent for showing the user doesn't have access - takes in required levels and current levels and returns a message if they don't have access and whyhasResourceAccessmethod in the access control logic that theAccessControlActionuses to determine accessTODO:
canEditInsightandcanEditDashboardworkingcan_editand make sure this doesn't break anything + works as expected going forwardNote: this has not been implemented for projects, teams, or environments - it's focused on resources.
Feedback
Asking all leads for reviews as this will affect all teams once implemented. Please provide thoughts/feedback on the way this implemented. This is attempting to make a reuseable pattern to it's easy to add access level checks.
An alternative approach could be to return an object from
hasResourceAccesswhich has the disabled reason and the wrapper is not needed.👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Does this work well for both Cloud and self-hosted?
Yes
How did you test this code?
Manually testing + will add some snapshots