To check that users do indeed have permissions to update the roles from
project-service, we've been depending on req.user.id.
We had one error on Friday March 8th, where we managed to send
undefined/null to a method that requires a number. This PR assumes that
if we have an API token, and we have admin permissions and userId is not
set we're a legacy admin token.
It uses the util method for extractUserId(req: IAuthRequest | IApiRequest), so if we've passed through the apiTokenMiddleware first, we'll have userId -42, if we haven't, we'll get -1337.
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.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
This deprecates the `username` properties on api-token schemas, and adds
a `tokenName` property.
DB field `username` has been renamed to `token_name`, migration added
for the rename.
Both `username` and `tokenName` can be used when consuming the service,
but only one of them.
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
There's a couple of things I'd like to get opinions on and discuss:
- Frontend still uses the deprecated `username` property
- ApiTokenSchema is used both for input and output of `Create`
controller endpoints and should be split out into separate schemas. I'll
set up a task for this
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* refactor: remove unused API definition routes
* feat: add support for proxy keys
* feat: support listening for any event
* feat: embed proxy endpoints
* refactor: add an experimental flag for the embedded proxy
* 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>
- When updating a toggle
- If the project is updated, the user performing the operation
will need UPDATE_FEATURE permission for both old and new project
fixes: #837
feat: options are now typed
- This makes it easier to know what to send to unleash.start / unleash.create
- Using a Partial to instantiate the config, then melding it with defaults to get a config object with all fields set either to their defaults or to whatever is passed in.
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com>
This PR Introduces first steps towards RBAC according to our specifications. Rbac will assume users to exist in the Unleash user table with a unique id. This is required to make correct mappings between users and roles.
