-
-
Notifications
You must be signed in to change notification settings - Fork 740
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
fix: take into account project segments permission #5304
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
@@ -112,7 +115,8 @@ export const CreateSegment = ({ modal }: ICreateSegmentProps) => { | |||
> | |||
<CreateButton | |||
name='segment' | |||
permission={CREATE_SEGMENT} | |||
permission={[CREATE_SEGMENT, UPDATE_PROJECT_SEGMENT]} | |||
projectId={projectId} |
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.
These 2 lines fix the bug on the UI, where the "Create" button was shown as being disabled.
@@ -135,7 +138,8 @@ export const EditSegment = ({ modal }: IEditSegmentProps) => { | |||
mode='edit' | |||
> | |||
<UpdateButton | |||
permission={UPDATE_SEGMENT} | |||
permission={[UPDATE_SEGMENT, UPDATE_PROJECT_SEGMENT]} | |||
projectId={projectId} |
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.
These 2 lines fix the bug on the UI, where the "Save" button was shown as being disabled.
); | ||
|
||
const res = await requestFunction(apiCaller, requestId, loadingOn); | ||
|
||
timeApiCallEnd( | ||
start, | ||
requestId || `Uknown request happening on ${apiCaller}`, | ||
requestId || `Unknown request happening on ${apiCaller}`, |
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.
Boyscouting: Noticed the typo and fixed it.
@@ -225,7 +226,7 @@ export class SegmentsController extends Controller { | |||
method: 'post', | |||
path: '', | |||
handler: this.createSegment, | |||
permission: CREATE_SEGMENT, | |||
permission: [CREATE_SEGMENT, UPDATE_PROJECT_SEGMENT], |
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.
These changes add the missing permission on the API level.
@@ -15,7 +15,7 @@ class PermissionError extends UnleashError { | |||
const permissionsMessage = | |||
permissions.length === 1 | |||
? `the "${permissions[0]}" permission` | |||
: `all of the following permissions: ${permissions | |||
: `one of the following permissions: ${permissions |
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.
Boyscouting: I think "one" instead of "all" is more honest and reflective of the real behavior.
config, | ||
{ featureToggleStore, segmentStore }, | ||
accessService, | ||
); |
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.
Change requires injecting a segmentStore
in the rbacMiddleware.
const { project } = await segmentStore.get(id); | ||
projectId = project; | ||
} | ||
|
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.
This is what I mean by:
This means that, in the rbac middleware when we check the permissions, we need to figure out if we're in such a scenario and fetch the project information from the DB, which feels a bit hacky, but it's something we're seemingly already doing for features, so at least it's somewhat consistent.
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.
This is the cleanest hack PR I've ever seen in my life xD
But I do agree, I think this is a hack. I'm okay to approve this because I do think it solves the problem but the cleaner design would be to split this into separate APIs.
Shall we get more eyes than just the 3 of us on this 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.
This feels like it looks good, the frontend changes at least was a nice catch. The logic in the segment controller as well seems sane to me.
This fixes an edge case not caught originally in #5304 - When creating a new segment on the global level: - There is no `projectId`, either in the params or body - The `UPDATE_PROJECT_SEGMENT` is still a part of the permissions checked on the endpoint - There is no `id` on the params This made it so that we would run `segmentStore.get(id)` with an undefined `id`, causing issues. The fix was simply checking for the presence of `params.id` before proceeding.
This fixes an edge case not caught originally in #5304 - When creating a new segment on the global level: - There is no `projectId`, either in the params or body - The `UPDATE_PROJECT_SEGMENT` is still a part of the permissions checked on the endpoint - There is no `id` on the params This made it so that we would run `segmentStore.get(id)` with an undefined `id`, causing issues. The fix was simply checking for the presence of `params.id` before proceeding.
https://linear.app/unleash/issue/SR-184/ticket-1106-users-with-createedit-project-segment-dont-see-all-the #5304 did not take into account permissions further into the Segment form. This PR fixes the remaining permission checks to take into consideration the project-level permission: `UPDATE_PROJECT_SEGMENT`.
https://linear.app/unleash/issue/SR-184/ticket-1106-users-with-createedit-project-segment-dont-see-all-the #5304 did not take into account permissions further into the Segment form. This PR fixes the remaining permission checks to take into consideration the project-level permission: `UPDATE_PROJECT_SEGMENT`. (cherry picked from commit f8a9d7f)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
Fixes #5314
Fixes a bug where the
UPDATE_PROJECT_SEGMENT
permission is not respected, both on the UI and on the API. The original intention was stated here.This was easy to fix on the UI, since we were simply missing the extra permission on the button permission checks.
Unfortunately the API can be tricky. Our auth middleware tries to grab the
project
information from either the params or body object, but ourDELETE
method does not contain this information. There is no body and the endpoint looks like/admin/segments/:id
, only including the segment id.This means that, in the rbac middleware when we check the permissions, we need to figure out if we're in such a scenario and fetch the project information from the DB, which feels a bit hacky, but it's something we're seemingly already doing for features, so at least it's somewhat consistent.
Ideally what we could do is leave this API alone and create a separate one for project segments, with endpoints where we would have project as a param, like so:
http://localhost:4242/api/admin/projects/:projectId/segments/1
.This PR opts to go with the quick and hacky solution for now since this is an issue we want to fix quickly, but this is something that we should be aware of. I'm also unsure if we want to create a new API for project segments. If we decide that we want a different solution I don't mind either adapting this PR or creating a follow up.