2021-03-11 22:51:58 +01:00
|
|
|
import rbacMiddleware from './rbac-middleware';
|
2021-04-22 23:40:52 +02:00
|
|
|
import User from '../types/user';
|
2021-05-02 20:58:02 +02:00
|
|
|
import * as perms from '../types/permissions';
|
2024-03-18 13:58:05 +01:00
|
|
|
import type { IUnleashConfig } from '../types/option';
|
2021-04-22 15:04:08 +02:00
|
|
|
import { createTestConfig } from '../../test/config/test-config';
|
2021-04-22 23:40:52 +02:00
|
|
|
import ApiUser from '../types/api-user';
|
2024-03-18 13:58:05 +01:00
|
|
|
import type { IFeatureToggleStore } from '../features/feature-toggle/types/feature-toggle-store-type';
|
2023-10-11 09:38:57 +02:00
|
|
|
import FakeFeatureToggleStore from '../features/feature-toggle/fakes/fake-feature-toggle-store';
|
2021-09-15 20:28:10 +02:00
|
|
|
import { ApiTokenType } from '../types/models/api-token';
|
2024-03-18 13:58:05 +01:00
|
|
|
import { type ISegmentStore, SYSTEM_USER_ID } from '../types';
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
import FakeSegmentStore from '../../test/fixtures/fake-segment-store';
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-04-22 10:07:10 +02:00
|
|
|
let config: IUnleashConfig;
|
2021-08-12 15:04:37 +02:00
|
|
|
let featureToggleStore: IFeatureToggleStore;
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
let segmentStore: ISegmentStore;
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
beforeEach(() => {
|
2021-08-12 15:04:37 +02:00
|
|
|
featureToggleStore = new FakeFeatureToggleStore();
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
segmentStore = new FakeSegmentStore();
|
2021-04-22 15:04:08 +02:00
|
|
|
config = createTestConfig();
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should add checkRbac to request', () => {
|
2021-04-22 10:07:10 +02:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-04-22 10:07:10 +02:00
|
|
|
};
|
2021-03-11 22:51:58 +01:00
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const req = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
// @ts-ignore
|
|
|
|
expect(req.checkRbac).toBeTruthy();
|
|
|
|
// @ts-ignore
|
|
|
|
expect(typeof req.checkRbac).toBe('function');
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should give api-user ADMIN permission', async () => {
|
2021-04-22 10:07:10 +02:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-04-22 10:07:10 +02:00
|
|
|
};
|
2021-03-11 22:51:58 +01:00
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {
|
2021-04-22 23:40:52 +02:00
|
|
|
user: new ApiUser({
|
2023-05-04 09:56:00 +02:00
|
|
|
tokenName: 'api',
|
2021-03-11 22:51:58 +01:00
|
|
|
permissions: [perms.ADMIN],
|
2021-09-15 20:28:10 +02:00
|
|
|
project: '*',
|
|
|
|
environment: '*',
|
|
|
|
type: ApiTokenType.ADMIN,
|
2022-08-16 15:33:33 +02:00
|
|
|
secret: 'a',
|
2021-03-11 22:51:58 +01:00
|
|
|
}),
|
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
const hasAccess = await req.checkRbac(perms.ADMIN);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(hasAccess).toBe(true);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2024-03-12 10:39:37 +01:00
|
|
|
describe('ADMIN tokens should have user id -1337 when only passed through rbac-middleware', () => {
|
|
|
|
/// Will be -42 (ADMIN_USER.id) when we have the api-token-middleware run first
|
|
|
|
test('Should give ADMIN api-user userid -1337 (SYSTEM_USER_ID)', async () => {
|
|
|
|
const accessService = {
|
|
|
|
hasPermission: jest.fn(),
|
|
|
|
};
|
|
|
|
|
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
|
|
|
|
|
|
|
const cb = jest.fn();
|
|
|
|
const req: any = {
|
|
|
|
user: new ApiUser({
|
|
|
|
tokenName: 'api',
|
|
|
|
permissions: [perms.ADMIN],
|
|
|
|
project: '*',
|
|
|
|
environment: '*',
|
|
|
|
type: ApiTokenType.ADMIN,
|
|
|
|
secret: 'a',
|
|
|
|
}),
|
|
|
|
};
|
|
|
|
func(req, undefined, cb);
|
|
|
|
const hasAccess = await req.checkRbac(perms.ADMIN);
|
|
|
|
expect(req.user.id).toBe(SYSTEM_USER_ID);
|
|
|
|
expect(hasAccess).toBe(true);
|
|
|
|
});
|
|
|
|
/// Will be -42 (ADMIN_USER.id) when we have the api-token-middleware run first
|
|
|
|
test('Also when checking against permission NONE, userid should still be -1337', async () => {
|
|
|
|
const accessService = {
|
|
|
|
hasPermission: jest.fn(),
|
|
|
|
};
|
|
|
|
|
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
|
|
|
|
|
|
|
const cb = jest.fn();
|
|
|
|
const req: any = {
|
|
|
|
user: new ApiUser({
|
|
|
|
tokenName: 'api',
|
|
|
|
permissions: [perms.ADMIN],
|
|
|
|
project: '*',
|
|
|
|
environment: '*',
|
|
|
|
type: ApiTokenType.ADMIN,
|
|
|
|
secret: 'a',
|
|
|
|
}),
|
|
|
|
};
|
|
|
|
func(req, undefined, cb);
|
|
|
|
const hasAccess = await req.checkRbac(perms.NONE);
|
|
|
|
expect(req.user.id).toBe(SYSTEM_USER_ID);
|
|
|
|
expect(hasAccess).toBe(true);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should not give api-user ADMIN permission', async () => {
|
2021-04-22 10:07:10 +02:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-04-22 10:07:10 +02:00
|
|
|
};
|
2021-03-11 22:51:58 +01:00
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {
|
2021-04-22 23:40:52 +02:00
|
|
|
user: new ApiUser({
|
2023-05-04 09:56:00 +02:00
|
|
|
tokenName: 'api',
|
2021-03-11 22:51:58 +01:00
|
|
|
permissions: [perms.CLIENT],
|
2021-09-15 20:28:10 +02:00
|
|
|
project: '*',
|
|
|
|
environment: '*',
|
|
|
|
type: ApiTokenType.CLIENT,
|
2022-08-16 15:33:33 +02:00
|
|
|
secret: 'a',
|
2021-03-11 22:51:58 +01:00
|
|
|
}),
|
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
const hasAccess = await req.checkRbac(perms.ADMIN);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(hasAccess).toBe(false);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledTimes(0);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should not allow user to miss userId', async () => {
|
2021-10-29 09:25:47 +02:00
|
|
|
jest.spyOn(global.console, 'error').mockImplementation(() => jest.fn());
|
2021-04-22 10:07:10 +02:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-04-22 10:07:10 +02:00
|
|
|
};
|
2021-03-11 22:51:58 +01:00
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {
|
2021-04-22 23:40:52 +02:00
|
|
|
user: {
|
2021-03-11 22:51:58 +01:00
|
|
|
username: 'user',
|
2021-04-22 23:40:52 +02:00
|
|
|
},
|
2021-03-11 22:51:58 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
const hasAccess = await req.checkRbac(perms.ADMIN);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(hasAccess).toBe(false);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should return false for missing user', async () => {
|
2021-10-29 09:25:47 +02:00
|
|
|
jest.spyOn(global.console, 'error').mockImplementation(() => jest.fn());
|
2021-04-22 10:07:10 +02:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-04-22 10:07:10 +02:00
|
|
|
};
|
2021-03-11 22:51:58 +01:00
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
const hasAccess = await req.checkRbac(perms.ADMIN);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(hasAccess).toBe(false);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledTimes(0);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should verify permission for root resource', async () => {
|
2021-03-11 22:51:58 +01:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-03-11 22:51:58 +01:00
|
|
|
};
|
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {
|
|
|
|
user: new User({
|
|
|
|
username: 'user',
|
|
|
|
id: 1,
|
|
|
|
}),
|
|
|
|
params: {},
|
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.ADMIN);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledTimes(1);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.ADMIN],
|
2021-05-28 11:10:24 +02:00
|
|
|
undefined,
|
2022-01-13 11:14:17 +01:00
|
|
|
undefined,
|
2021-05-28 11:10:24 +02:00
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should lookup projectId from params', async () => {
|
2021-03-11 22:51:58 +01:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-03-11 22:51:58 +01:00
|
|
|
};
|
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {
|
|
|
|
user: new User({
|
|
|
|
username: 'user',
|
|
|
|
id: 1,
|
|
|
|
}),
|
|
|
|
params: {
|
|
|
|
projectId: 'some-proj',
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.UPDATE_PROJECT);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.UPDATE_PROJECT],
|
2021-05-28 11:10:24 +02:00
|
|
|
req.params.projectId,
|
2022-01-13 11:14:17 +01:00
|
|
|
undefined,
|
2021-05-28 11:10:24 +02:00
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2024-05-23 10:32:11 +02:00
|
|
|
test('should lookup projectId from feature flag', async () => {
|
2021-03-11 22:51:58 +01:00
|
|
|
const projectId = 'some-project-33';
|
2024-05-23 10:32:11 +02:00
|
|
|
const featureName = 'some-feature-flag';
|
2021-03-11 22:51:58 +01:00
|
|
|
|
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-03-11 22:51:58 +01:00
|
|
|
};
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
featureToggleStore.getProjectId = jest.fn().mockReturnValue(projectId);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {
|
|
|
|
user: new User({
|
|
|
|
username: 'user',
|
|
|
|
id: 1,
|
|
|
|
}),
|
|
|
|
params: {
|
|
|
|
featureName,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.UPDATE_FEATURE);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.UPDATE_FEATURE],
|
2021-05-28 11:10:24 +02:00
|
|
|
projectId,
|
2022-01-13 11:14:17 +01:00
|
|
|
undefined,
|
2021-05-28 11:10:24 +02:00
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
test('should lookup projectId from data', async () => {
|
2021-03-11 22:51:58 +01:00
|
|
|
const projectId = 'some-project-33';
|
2024-05-23 10:32:11 +02:00
|
|
|
const featureName = 'some-feature-flag';
|
2021-03-11 22:51:58 +01:00
|
|
|
|
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn(),
|
2021-03-11 22:51:58 +01:00
|
|
|
};
|
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-03-11 22:51:58 +01:00
|
|
|
const req: any = {
|
|
|
|
user: new User({
|
|
|
|
username: 'user',
|
|
|
|
id: 1,
|
|
|
|
}),
|
|
|
|
params: {},
|
|
|
|
body: {
|
|
|
|
featureName,
|
|
|
|
project: projectId,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.CREATE_FEATURE);
|
|
|
|
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.CREATE_FEATURE],
|
2021-05-28 11:10:24 +02:00
|
|
|
projectId,
|
2022-01-13 11:14:17 +01:00
|
|
|
undefined,
|
2021-05-28 11:10:24 +02:00
|
|
|
);
|
2021-03-11 22:51:58 +01:00
|
|
|
});
|
2021-05-05 22:32:25 +02:00
|
|
|
|
2024-05-23 10:32:11 +02:00
|
|
|
test('Does not double check permission if not changing project when updating flag', async () => {
|
2021-05-05 22:32:25 +02:00
|
|
|
const oldProjectId = 'some-project-34';
|
2024-05-23 10:32:11 +02:00
|
|
|
const featureName = 'some-feature-flag';
|
2021-05-05 22:32:25 +02:00
|
|
|
const accessService = {
|
2021-05-28 11:10:24 +02:00
|
|
|
hasPermission: jest.fn().mockReturnValue(true),
|
2021-05-05 22:32:25 +02:00
|
|
|
};
|
2021-05-28 11:10:24 +02:00
|
|
|
featureToggleStore.getProjectId = jest.fn().mockReturnValue(oldProjectId);
|
2021-05-05 22:32:25 +02:00
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-05-28 11:10:24 +02:00
|
|
|
const cb = jest.fn();
|
2021-05-05 22:32:25 +02:00
|
|
|
const req: any = {
|
|
|
|
user: new User({ username: 'user', id: 1 }),
|
|
|
|
params: { featureName },
|
|
|
|
body: { featureName, project: oldProjectId },
|
|
|
|
};
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.UPDATE_FEATURE);
|
2021-05-28 11:10:24 +02:00
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledTimes(1);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.UPDATE_FEATURE],
|
2021-05-28 11:10:24 +02:00
|
|
|
oldProjectId,
|
2022-01-13 11:14:17 +01:00
|
|
|
undefined,
|
2021-05-28 11:10:24 +02:00
|
|
|
);
|
2021-05-05 22:32:25 +02:00
|
|
|
});
|
2021-09-24 09:01:15 +02:00
|
|
|
|
2023-11-22 11:20:19 +01:00
|
|
|
test('CREATE_TAG_TYPE does not need projectId', async () => {
|
|
|
|
const accessService = {
|
|
|
|
hasPermission: jest.fn().mockReturnValue(true),
|
|
|
|
};
|
|
|
|
|
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
|
|
|
const cb = jest.fn();
|
|
|
|
const req: any = {
|
|
|
|
user: new User({ username: 'user', id: 1 }),
|
|
|
|
params: {},
|
|
|
|
body: { name: 'new-tag-type', description: 'New tag type for testing' },
|
|
|
|
};
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.CREATE_TAG_TYPE);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledTimes(1);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
|
|
|
[perms.CREATE_TAG_TYPE],
|
|
|
|
undefined,
|
|
|
|
undefined,
|
|
|
|
);
|
|
|
|
});
|
|
|
|
|
2021-09-24 09:01:15 +02:00
|
|
|
test('UPDATE_TAG_TYPE does not need projectId', async () => {
|
|
|
|
const accessService = {
|
|
|
|
hasPermission: jest.fn().mockReturnValue(true),
|
|
|
|
};
|
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-09-24 09:01:15 +02:00
|
|
|
const cb = jest.fn();
|
|
|
|
const req: any = {
|
|
|
|
user: new User({ username: 'user', id: 1 }),
|
|
|
|
params: {},
|
|
|
|
body: { name: 'new-tag-type', description: 'New tag type for testing' },
|
|
|
|
};
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.UPDATE_TAG_TYPE);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledTimes(1);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.UPDATE_TAG_TYPE],
|
2021-09-24 09:01:15 +02:00
|
|
|
undefined,
|
2022-01-13 11:14:17 +01:00
|
|
|
undefined,
|
2021-09-24 09:01:15 +02:00
|
|
|
);
|
|
|
|
});
|
|
|
|
|
|
|
|
test('DELETE_TAG_TYPE does not need projectId', async () => {
|
|
|
|
const accessService = {
|
|
|
|
hasPermission: jest.fn().mockReturnValue(true),
|
|
|
|
};
|
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2021-09-24 09:01:15 +02:00
|
|
|
const cb = jest.fn();
|
|
|
|
const req: any = {
|
|
|
|
user: new User({ username: 'user', id: 1 }),
|
|
|
|
params: {},
|
|
|
|
body: { name: 'new-tag-type', description: 'New tag type for testing' },
|
|
|
|
};
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.DELETE_TAG_TYPE);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledTimes(1);
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.DELETE_TAG_TYPE],
|
2021-09-24 09:01:15 +02:00
|
|
|
undefined,
|
2022-01-13 11:14:17 +01:00
|
|
|
undefined,
|
2021-09-24 09:01:15 +02:00
|
|
|
);
|
|
|
|
});
|
2023-03-23 09:12:38 +01:00
|
|
|
|
|
|
|
test('should not expect featureName for UPDATE_FEATURE when projectId specified', async () => {
|
|
|
|
const projectId = 'some-project-33';
|
|
|
|
|
|
|
|
const accessService = {
|
|
|
|
hasPermission: jest.fn(),
|
|
|
|
};
|
|
|
|
|
fix: take into account project segments permission (#5304)
https://linear.app/unleash/issue/SR-164/ticket-1106-user-with-createedit-project-segment-is-not-able-to-edit-a
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](https://github.com/Unleash/unleash/pull/3346#discussion_r1140434517).
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 our
`DELETE` 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.
2023-11-09 10:37:47 +01:00
|
|
|
const func = rbacMiddleware(
|
|
|
|
config,
|
|
|
|
{ featureToggleStore, segmentStore },
|
|
|
|
accessService,
|
|
|
|
);
|
2023-03-23 09:12:38 +01:00
|
|
|
|
|
|
|
const cb = jest.fn();
|
|
|
|
const req: any = {
|
|
|
|
user: new User({
|
|
|
|
username: 'user',
|
|
|
|
id: 1,
|
|
|
|
}),
|
|
|
|
params: {},
|
|
|
|
body: {
|
|
|
|
project: projectId,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
func(req, undefined, cb);
|
|
|
|
|
|
|
|
await req.checkRbac(perms.UPDATE_FEATURE);
|
|
|
|
|
|
|
|
expect(accessService.hasPermission).toHaveBeenCalledWith(
|
|
|
|
req.user,
|
2023-06-22 09:35:54 +02:00
|
|
|
[perms.UPDATE_FEATURE],
|
2023-03-23 09:12:38 +01:00
|
|
|
projectId,
|
|
|
|
undefined,
|
|
|
|
);
|
|
|
|
});
|