1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-01-31 00:16:47 +01:00
unleash.unleash/src/lib/middleware/rbac-middleware.test.ts

511 lines
13 KiB
TypeScript
Raw Normal View History

import rbacMiddleware from './rbac-middleware';
import User from '../types/user';
2021-05-02 20:58:02 +02:00
import * as perms from '../types/permissions';
import type { IUnleashConfig } from '../types/option';
import { createTestConfig } from '../../test/config/test-config';
import ApiUser from '../types/api-user';
import type { IFeatureToggleStore } from '../features/feature-toggle/types/feature-toggle-store-type';
import FakeFeatureToggleStore from '../features/feature-toggle/fakes/fake-feature-toggle-store';
import { ApiTokenType } from '../types/models/api-token';
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';
let config: IUnleashConfig;
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;
beforeEach(() => {
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();
config = createTestConfig();
});
test('should add checkRbac to request', () => {
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,
);
const cb = jest.fn();
const req = jest.fn();
func(req, undefined, cb);
// @ts-ignore
expect(req.checkRbac).toBeTruthy();
// @ts-ignore
expect(typeof req.checkRbac).toBe('function');
});
test('should give api-user ADMIN permission', async () => {
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,
);
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(hasAccess).toBe(true);
});
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);
});
});
test('should not give api-user ADMIN permission', async () => {
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,
);
const cb = jest.fn();
const req: any = {
user: new ApiUser({
tokenName: 'api',
permissions: [perms.CLIENT],
project: '*',
environment: '*',
type: ApiTokenType.CLIENT,
secret: 'a',
}),
};
func(req, undefined, cb);
const hasAccess = await req.checkRbac(perms.ADMIN);
expect(hasAccess).toBe(false);
expect(accessService.hasPermission).toHaveBeenCalledTimes(0);
});
test('should not allow user to miss userId', async () => {
jest.spyOn(global.console, 'error').mockImplementation(() => jest.fn());
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,
);
const cb = jest.fn();
const req: any = {
user: {
username: 'user',
},
};
func(req, undefined, cb);
const hasAccess = await req.checkRbac(perms.ADMIN);
expect(hasAccess).toBe(false);
});
test('should return false for missing user', async () => {
jest.spyOn(global.console, 'error').mockImplementation(() => jest.fn());
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,
);
const cb = jest.fn();
const req: any = {};
func(req, undefined, cb);
const hasAccess = await req.checkRbac(perms.ADMIN);
expect(hasAccess).toBe(false);
expect(accessService.hasPermission).toHaveBeenCalledTimes(0);
});
test('should verify permission for root resource', async () => {
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,
);
const cb = jest.fn();
const req: any = {
user: new User({
username: 'user',
id: 1,
}),
params: {},
};
func(req, undefined, cb);
await req.checkRbac(perms.ADMIN);
expect(accessService.hasPermission).toHaveBeenCalledTimes(1);
expect(accessService.hasPermission).toHaveBeenCalledWith(
req.user,
[perms.ADMIN],
undefined,
feat: custom project roles (#1220) * wip: environment for permissions * fix: add migration for roles * fix: connect environment with access service * feat: add tests * chore: Implement scaffolding for new rbac * fix: add fake store * feat: Add api endpoints for roles and permissions list * feat: Add ability to provide permissions when creating a role and rename environmentName to name in the list permissions datastructure * fix: Make project roles resolve correctly against new environments permissions structure * fix: Patch migration to also populate permission names * fix: Make permissions actually work with new environments * fix: Add back to get permissions working for editor role * fix: Removed ability to set role type through api during creation - it's now always custom * feat: Return permissions on get role endpoint * feat: Add in support for updating roles * fix: Get a bunch of tests working and delete a few that make no sense anymore * chore: A few small cleanups - remove logging and restore default on dev server config * chore: Refactor role/access stores into more logical domains * feat: Add in validation for roles * feat: Patch db migration to handle old stucture * fix: migration for project roles * fix: patch a few broken tests * fix: add permissions to editor * fix: update test name * fix: update user permission mapping * fix: create new user * fix: update root role test * fix: update tests * feat: Validation now works when updating a role * fix: Add in very barebones down migration for rbac so that tests work * fix: Improve responses from role resolution - getting a non existant role will throw a NotFound error * fix: remove unused permissions * fix: add test for connecting roles and deleting project * fix: add test for adding a project member with a custom role * fix: add test for changing user role * fix: add guard for deleting role if the role is in use * fix: alter migration * chore: Minor code cleanups * chore: Small code cleanups * chore: More minor cleanups of code * chore: Trim some dead code to make the linter happy * feat: Schema validation for roles * fix: setup permission for variant * fix: remove unused import * feat: Add cascading delete for role_permissions when deleting a role * feat: add configuration option for disabling legacy api * chore: update frontend to beta version * 4.6.0-beta.0 * fix: export default project constant * fix: update snapshot * fix: module pattern ../../lib * fix: move DEFAULT_PROJECT to types * fix: remove debug logging * fix: remove debug log state * fix: Change permission descriptions * fix: roles should have unique name * fix: root roles should be connected to the default project * fix: typo in role-schema.ts * fix: Role permission empty string for non environment type * feat: new permission for moving project * fix: add event for changeProject * fix: Removing a user from a project will now check to see if that project has an owner, rather than checking if any project has an owner * fix: add tests for move project * fix: Add in missing create/delete tag permissions * fix: Removed duplicate impl caused by multiple good samaritans putting it back in! * fix: Trim out add tag permissions, for now at least * chore: Trim out new add and delete tag permissions - we're going with update feature instead * chore: update frontend * 4.6.0-beta.1 * feat: Prevent editing of built in roles * fix: Patch an issue where permissions for variants/environments didn't match the front end * fix: lint Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
2022-01-13 11:14:17 +01:00
undefined,
);
});
test('should lookup projectId from params', async () => {
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,
);
const cb = jest.fn();
const req: any = {
user: new User({
username: 'user',
id: 1,
}),
params: {
projectId: 'some-proj',
},
};
func(req, undefined, cb);
await req.checkRbac(perms.UPDATE_PROJECT);
expect(accessService.hasPermission).toHaveBeenCalledWith(
req.user,
[perms.UPDATE_PROJECT],
req.params.projectId,
feat: custom project roles (#1220) * wip: environment for permissions * fix: add migration for roles * fix: connect environment with access service * feat: add tests * chore: Implement scaffolding for new rbac * fix: add fake store * feat: Add api endpoints for roles and permissions list * feat: Add ability to provide permissions when creating a role and rename environmentName to name in the list permissions datastructure * fix: Make project roles resolve correctly against new environments permissions structure * fix: Patch migration to also populate permission names * fix: Make permissions actually work with new environments * fix: Add back to get permissions working for editor role * fix: Removed ability to set role type through api during creation - it's now always custom * feat: Return permissions on get role endpoint * feat: Add in support for updating roles * fix: Get a bunch of tests working and delete a few that make no sense anymore * chore: A few small cleanups - remove logging and restore default on dev server config * chore: Refactor role/access stores into more logical domains * feat: Add in validation for roles * feat: Patch db migration to handle old stucture * fix: migration for project roles * fix: patch a few broken tests * fix: add permissions to editor * fix: update test name * fix: update user permission mapping * fix: create new user * fix: update root role test * fix: update tests * feat: Validation now works when updating a role * fix: Add in very barebones down migration for rbac so that tests work * fix: Improve responses from role resolution - getting a non existant role will throw a NotFound error * fix: remove unused permissions * fix: add test for connecting roles and deleting project * fix: add test for adding a project member with a custom role * fix: add test for changing user role * fix: add guard for deleting role if the role is in use * fix: alter migration * chore: Minor code cleanups * chore: Small code cleanups * chore: More minor cleanups of code * chore: Trim some dead code to make the linter happy * feat: Schema validation for roles * fix: setup permission for variant * fix: remove unused import * feat: Add cascading delete for role_permissions when deleting a role * feat: add configuration option for disabling legacy api * chore: update frontend to beta version * 4.6.0-beta.0 * fix: export default project constant * fix: update snapshot * fix: module pattern ../../lib * fix: move DEFAULT_PROJECT to types * fix: remove debug logging * fix: remove debug log state * fix: Change permission descriptions * fix: roles should have unique name * fix: root roles should be connected to the default project * fix: typo in role-schema.ts * fix: Role permission empty string for non environment type * feat: new permission for moving project * fix: add event for changeProject * fix: Removing a user from a project will now check to see if that project has an owner, rather than checking if any project has an owner * fix: add tests for move project * fix: Add in missing create/delete tag permissions * fix: Removed duplicate impl caused by multiple good samaritans putting it back in! * fix: Trim out add tag permissions, for now at least * chore: Trim out new add and delete tag permissions - we're going with update feature instead * chore: update frontend * 4.6.0-beta.1 * feat: Prevent editing of built in roles * fix: Patch an issue where permissions for variants/environments didn't match the front end * fix: lint Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
2022-01-13 11:14:17 +01:00
undefined,
);
});
test('should lookup projectId from feature flag', async () => {
const projectId = 'some-project-33';
const featureName = 'some-feature-flag';
const accessService = {
hasPermission: jest.fn(),
};
featureToggleStore.getProjectId = jest.fn().mockReturnValue(projectId);
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,
);
const cb = jest.fn();
const req: any = {
user: new User({
username: 'user',
id: 1,
}),
params: {
featureName,
},
};
func(req, undefined, cb);
await req.checkRbac(perms.UPDATE_FEATURE);
expect(accessService.hasPermission).toHaveBeenCalledWith(
req.user,
[perms.UPDATE_FEATURE],
projectId,
feat: custom project roles (#1220) * wip: environment for permissions * fix: add migration for roles * fix: connect environment with access service * feat: add tests * chore: Implement scaffolding for new rbac * fix: add fake store * feat: Add api endpoints for roles and permissions list * feat: Add ability to provide permissions when creating a role and rename environmentName to name in the list permissions datastructure * fix: Make project roles resolve correctly against new environments permissions structure * fix: Patch migration to also populate permission names * fix: Make permissions actually work with new environments * fix: Add back to get permissions working for editor role * fix: Removed ability to set role type through api during creation - it's now always custom * feat: Return permissions on get role endpoint * feat: Add in support for updating roles * fix: Get a bunch of tests working and delete a few that make no sense anymore * chore: A few small cleanups - remove logging and restore default on dev server config * chore: Refactor role/access stores into more logical domains * feat: Add in validation for roles * feat: Patch db migration to handle old stucture * fix: migration for project roles * fix: patch a few broken tests * fix: add permissions to editor * fix: update test name * fix: update user permission mapping * fix: create new user * fix: update root role test * fix: update tests * feat: Validation now works when updating a role * fix: Add in very barebones down migration for rbac so that tests work * fix: Improve responses from role resolution - getting a non existant role will throw a NotFound error * fix: remove unused permissions * fix: add test for connecting roles and deleting project * fix: add test for adding a project member with a custom role * fix: add test for changing user role * fix: add guard for deleting role if the role is in use * fix: alter migration * chore: Minor code cleanups * chore: Small code cleanups * chore: More minor cleanups of code * chore: Trim some dead code to make the linter happy * feat: Schema validation for roles * fix: setup permission for variant * fix: remove unused import * feat: Add cascading delete for role_permissions when deleting a role * feat: add configuration option for disabling legacy api * chore: update frontend to beta version * 4.6.0-beta.0 * fix: export default project constant * fix: update snapshot * fix: module pattern ../../lib * fix: move DEFAULT_PROJECT to types * fix: remove debug logging * fix: remove debug log state * fix: Change permission descriptions * fix: roles should have unique name * fix: root roles should be connected to the default project * fix: typo in role-schema.ts * fix: Role permission empty string for non environment type * feat: new permission for moving project * fix: add event for changeProject * fix: Removing a user from a project will now check to see if that project has an owner, rather than checking if any project has an owner * fix: add tests for move project * fix: Add in missing create/delete tag permissions * fix: Removed duplicate impl caused by multiple good samaritans putting it back in! * fix: Trim out add tag permissions, for now at least * chore: Trim out new add and delete tag permissions - we're going with update feature instead * chore: update frontend * 4.6.0-beta.1 * feat: Prevent editing of built in roles * fix: Patch an issue where permissions for variants/environments didn't match the front end * fix: lint Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
2022-01-13 11:14:17 +01:00
undefined,
);
});
test('should lookup projectId from data', async () => {
const projectId = 'some-project-33';
const featureName = 'some-feature-flag';
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,
);
const cb = jest.fn();
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);
expect(accessService.hasPermission).toHaveBeenCalledWith(
req.user,
[perms.CREATE_FEATURE],
projectId,
feat: custom project roles (#1220) * wip: environment for permissions * fix: add migration for roles * fix: connect environment with access service * feat: add tests * chore: Implement scaffolding for new rbac * fix: add fake store * feat: Add api endpoints for roles and permissions list * feat: Add ability to provide permissions when creating a role and rename environmentName to name in the list permissions datastructure * fix: Make project roles resolve correctly against new environments permissions structure * fix: Patch migration to also populate permission names * fix: Make permissions actually work with new environments * fix: Add back to get permissions working for editor role * fix: Removed ability to set role type through api during creation - it's now always custom * feat: Return permissions on get role endpoint * feat: Add in support for updating roles * fix: Get a bunch of tests working and delete a few that make no sense anymore * chore: A few small cleanups - remove logging and restore default on dev server config * chore: Refactor role/access stores into more logical domains * feat: Add in validation for roles * feat: Patch db migration to handle old stucture * fix: migration for project roles * fix: patch a few broken tests * fix: add permissions to editor * fix: update test name * fix: update user permission mapping * fix: create new user * fix: update root role test * fix: update tests * feat: Validation now works when updating a role * fix: Add in very barebones down migration for rbac so that tests work * fix: Improve responses from role resolution - getting a non existant role will throw a NotFound error * fix: remove unused permissions * fix: add test for connecting roles and deleting project * fix: add test for adding a project member with a custom role * fix: add test for changing user role * fix: add guard for deleting role if the role is in use * fix: alter migration * chore: Minor code cleanups * chore: Small code cleanups * chore: More minor cleanups of code * chore: Trim some dead code to make the linter happy * feat: Schema validation for roles * fix: setup permission for variant * fix: remove unused import * feat: Add cascading delete for role_permissions when deleting a role * feat: add configuration option for disabling legacy api * chore: update frontend to beta version * 4.6.0-beta.0 * fix: export default project constant * fix: update snapshot * fix: module pattern ../../lib * fix: move DEFAULT_PROJECT to types * fix: remove debug logging * fix: remove debug log state * fix: Change permission descriptions * fix: roles should have unique name * fix: root roles should be connected to the default project * fix: typo in role-schema.ts * fix: Role permission empty string for non environment type * feat: new permission for moving project * fix: add event for changeProject * fix: Removing a user from a project will now check to see if that project has an owner, rather than checking if any project has an owner * fix: add tests for move project * fix: Add in missing create/delete tag permissions * fix: Removed duplicate impl caused by multiple good samaritans putting it back in! * fix: Trim out add tag permissions, for now at least * chore: Trim out new add and delete tag permissions - we're going with update feature instead * chore: update frontend * 4.6.0-beta.1 * feat: Prevent editing of built in roles * fix: Patch an issue where permissions for variants/environments didn't match the front end * fix: lint Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
2022-01-13 11:14:17 +01:00
undefined,
);
});
test('Does not double check permission if not changing project when updating flag', async () => {
const oldProjectId = 'some-project-34';
const featureName = 'some-feature-flag';
const accessService = {
hasPermission: jest.fn().mockReturnValue(true),
};
featureToggleStore.getProjectId = jest.fn().mockReturnValue(oldProjectId);
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,
);
const cb = jest.fn();
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);
expect(accessService.hasPermission).toHaveBeenCalledTimes(1);
expect(accessService.hasPermission).toHaveBeenCalledWith(
req.user,
[perms.UPDATE_FEATURE],
oldProjectId,
feat: custom project roles (#1220) * wip: environment for permissions * fix: add migration for roles * fix: connect environment with access service * feat: add tests * chore: Implement scaffolding for new rbac * fix: add fake store * feat: Add api endpoints for roles and permissions list * feat: Add ability to provide permissions when creating a role and rename environmentName to name in the list permissions datastructure * fix: Make project roles resolve correctly against new environments permissions structure * fix: Patch migration to also populate permission names * fix: Make permissions actually work with new environments * fix: Add back to get permissions working for editor role * fix: Removed ability to set role type through api during creation - it's now always custom * feat: Return permissions on get role endpoint * feat: Add in support for updating roles * fix: Get a bunch of tests working and delete a few that make no sense anymore * chore: A few small cleanups - remove logging and restore default on dev server config * chore: Refactor role/access stores into more logical domains * feat: Add in validation for roles * feat: Patch db migration to handle old stucture * fix: migration for project roles * fix: patch a few broken tests * fix: add permissions to editor * fix: update test name * fix: update user permission mapping * fix: create new user * fix: update root role test * fix: update tests * feat: Validation now works when updating a role * fix: Add in very barebones down migration for rbac so that tests work * fix: Improve responses from role resolution - getting a non existant role will throw a NotFound error * fix: remove unused permissions * fix: add test for connecting roles and deleting project * fix: add test for adding a project member with a custom role * fix: add test for changing user role * fix: add guard for deleting role if the role is in use * fix: alter migration * chore: Minor code cleanups * chore: Small code cleanups * chore: More minor cleanups of code * chore: Trim some dead code to make the linter happy * feat: Schema validation for roles * fix: setup permission for variant * fix: remove unused import * feat: Add cascading delete for role_permissions when deleting a role * feat: add configuration option for disabling legacy api * chore: update frontend to beta version * 4.6.0-beta.0 * fix: export default project constant * fix: update snapshot * fix: module pattern ../../lib * fix: move DEFAULT_PROJECT to types * fix: remove debug logging * fix: remove debug log state * fix: Change permission descriptions * fix: roles should have unique name * fix: root roles should be connected to the default project * fix: typo in role-schema.ts * fix: Role permission empty string for non environment type * feat: new permission for moving project * fix: add event for changeProject * fix: Removing a user from a project will now check to see if that project has an owner, rather than checking if any project has an owner * fix: add tests for move project * fix: Add in missing create/delete tag permissions * fix: Removed duplicate impl caused by multiple good samaritans putting it back in! * fix: Trim out add tag permissions, for now at least * chore: Trim out new add and delete tag permissions - we're going with update feature instead * chore: update frontend * 4.6.0-beta.1 * feat: Prevent editing of built in roles * fix: Patch an issue where permissions for variants/environments didn't match the front end * fix: lint Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
2022-01-13 11:14:17 +01:00
undefined,
);
});
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,
);
});
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,
);
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,
[perms.UPDATE_TAG_TYPE],
undefined,
feat: custom project roles (#1220) * wip: environment for permissions * fix: add migration for roles * fix: connect environment with access service * feat: add tests * chore: Implement scaffolding for new rbac * fix: add fake store * feat: Add api endpoints for roles and permissions list * feat: Add ability to provide permissions when creating a role and rename environmentName to name in the list permissions datastructure * fix: Make project roles resolve correctly against new environments permissions structure * fix: Patch migration to also populate permission names * fix: Make permissions actually work with new environments * fix: Add back to get permissions working for editor role * fix: Removed ability to set role type through api during creation - it's now always custom * feat: Return permissions on get role endpoint * feat: Add in support for updating roles * fix: Get a bunch of tests working and delete a few that make no sense anymore * chore: A few small cleanups - remove logging and restore default on dev server config * chore: Refactor role/access stores into more logical domains * feat: Add in validation for roles * feat: Patch db migration to handle old stucture * fix: migration for project roles * fix: patch a few broken tests * fix: add permissions to editor * fix: update test name * fix: update user permission mapping * fix: create new user * fix: update root role test * fix: update tests * feat: Validation now works when updating a role * fix: Add in very barebones down migration for rbac so that tests work * fix: Improve responses from role resolution - getting a non existant role will throw a NotFound error * fix: remove unused permissions * fix: add test for connecting roles and deleting project * fix: add test for adding a project member with a custom role * fix: add test for changing user role * fix: add guard for deleting role if the role is in use * fix: alter migration * chore: Minor code cleanups * chore: Small code cleanups * chore: More minor cleanups of code * chore: Trim some dead code to make the linter happy * feat: Schema validation for roles * fix: setup permission for variant * fix: remove unused import * feat: Add cascading delete for role_permissions when deleting a role * feat: add configuration option for disabling legacy api * chore: update frontend to beta version * 4.6.0-beta.0 * fix: export default project constant * fix: update snapshot * fix: module pattern ../../lib * fix: move DEFAULT_PROJECT to types * fix: remove debug logging * fix: remove debug log state * fix: Change permission descriptions * fix: roles should have unique name * fix: root roles should be connected to the default project * fix: typo in role-schema.ts * fix: Role permission empty string for non environment type * feat: new permission for moving project * fix: add event for changeProject * fix: Removing a user from a project will now check to see if that project has an owner, rather than checking if any project has an owner * fix: add tests for move project * fix: Add in missing create/delete tag permissions * fix: Removed duplicate impl caused by multiple good samaritans putting it back in! * fix: Trim out add tag permissions, for now at least * chore: Trim out new add and delete tag permissions - we're going with update feature instead * chore: update frontend * 4.6.0-beta.1 * feat: Prevent editing of built in roles * fix: Patch an issue where permissions for variants/environments didn't match the front end * fix: lint Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
2022-01-13 11:14:17 +01:00
undefined,
);
});
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,
);
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,
[perms.DELETE_TAG_TYPE],
undefined,
feat: custom project roles (#1220) * wip: environment for permissions * fix: add migration for roles * fix: connect environment with access service * feat: add tests * chore: Implement scaffolding for new rbac * fix: add fake store * feat: Add api endpoints for roles and permissions list * feat: Add ability to provide permissions when creating a role and rename environmentName to name in the list permissions datastructure * fix: Make project roles resolve correctly against new environments permissions structure * fix: Patch migration to also populate permission names * fix: Make permissions actually work with new environments * fix: Add back to get permissions working for editor role * fix: Removed ability to set role type through api during creation - it's now always custom * feat: Return permissions on get role endpoint * feat: Add in support for updating roles * fix: Get a bunch of tests working and delete a few that make no sense anymore * chore: A few small cleanups - remove logging and restore default on dev server config * chore: Refactor role/access stores into more logical domains * feat: Add in validation for roles * feat: Patch db migration to handle old stucture * fix: migration for project roles * fix: patch a few broken tests * fix: add permissions to editor * fix: update test name * fix: update user permission mapping * fix: create new user * fix: update root role test * fix: update tests * feat: Validation now works when updating a role * fix: Add in very barebones down migration for rbac so that tests work * fix: Improve responses from role resolution - getting a non existant role will throw a NotFound error * fix: remove unused permissions * fix: add test for connecting roles and deleting project * fix: add test for adding a project member with a custom role * fix: add test for changing user role * fix: add guard for deleting role if the role is in use * fix: alter migration * chore: Minor code cleanups * chore: Small code cleanups * chore: More minor cleanups of code * chore: Trim some dead code to make the linter happy * feat: Schema validation for roles * fix: setup permission for variant * fix: remove unused import * feat: Add cascading delete for role_permissions when deleting a role * feat: add configuration option for disabling legacy api * chore: update frontend to beta version * 4.6.0-beta.0 * fix: export default project constant * fix: update snapshot * fix: module pattern ../../lib * fix: move DEFAULT_PROJECT to types * fix: remove debug logging * fix: remove debug log state * fix: Change permission descriptions * fix: roles should have unique name * fix: root roles should be connected to the default project * fix: typo in role-schema.ts * fix: Role permission empty string for non environment type * feat: new permission for moving project * fix: add event for changeProject * fix: Removing a user from a project will now check to see if that project has an owner, rather than checking if any project has an owner * fix: add tests for move project * fix: Add in missing create/delete tag permissions * fix: Removed duplicate impl caused by multiple good samaritans putting it back in! * fix: Trim out add tag permissions, for now at least * chore: Trim out new add and delete tag permissions - we're going with update feature instead * chore: update frontend * 4.6.0-beta.1 * feat: Prevent editing of built in roles * fix: Patch an issue where permissions for variants/environments didn't match the front end * fix: lint Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com> Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
2022-01-13 11:14:17 +01:00
undefined,
);
});
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,
[perms.UPDATE_FEATURE],
2023-03-23 09:12:38 +01:00
projectId,
undefined,
);
});