-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
permissions: add new PermissionIntegrationsService #28400
Conversation
Important This PR includes changes that affect public-facing API. Please ensure you are adding/updating documentation for new features or behavior. Changed Packages
|
7ccf933
to
f769700
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking forward to using this 🎉
|
||
1. We will be using the `@backstage/plugin-catalog-node` package as it contains the extension point we need. Run this to add it: | ||
|
||
```bash title="from your Backstage root directory" | ||
yarn --cwd packages/backend add @backstage/plugin-catalog-node | ||
``` | ||
|
||
2. Next create a `catalogPermissionRules.ts` file in the `packages/backend/src/extensions` folder. | ||
2. Next create a `catalogPermissionRules.ts` file in the `packages/backend/src/modules` folder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: since there may be a lot of files related to permissions (and most deployments are likely to have a permission policy), it might be good to encourage grouping things under packages/backend/src/permissions
instead of generic 'extensions' or 'modules' folders:
packages/backend/src
+ permissions
+ rules // inventory of all custom permission rules for plugins
| + catalogPermissionRules.ts
| + scaffolderPermissionRules.ts
+ policy.ts // App specific permission policy file
+ module.ts // Permission backend module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd push back on this, ideally you should be creating a dedicated backend module for this and that's been the recommendation. We also have been using the extensions
folder in other places in the documentation so this would be a pattern people are following already for smaller things.
In a perfect world I would have had time to finish this PR #27391 that would create a permissions module for you making the docs and process a lot better!
I was never a fan of permissions integrations 😅 hot take: is there a reason we can't just group this into the permissions service, is there a lot of value in keeping these things separate? Otherwise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks cool 😄 - Maybe I need to read it again tomorrow when I'm less tired, but in the context of the to-do
plugin does this really show the benefits of this feature? Or is it worth adding more examples later on perhaps, I probably just need to read the guides in full instead of just the changes 😅
Edit: Ok I see now 👍
Kudos!
docs/permissions/plugin-authors/03-adding-a-resource-permission-check.md
Outdated
Show resolved
Hide resolved
143010a
to
0330bc8
Compare
@benjdlambert I kinda like |
0330bc8
to
dbed1bd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great! Can we see how catalog-backend-module-unprocessed
looks like? Asking because it's a corner case where a module brings new endpoints with extra permissions into the plugin. It would be great to see if the new service fits this use case
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
…resource type Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
…rvice Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
f45cb90
to
4e073c7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I'll work on updating Scaffolder to use this new service
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aight, just little nits, solid work
...es/backend-defaults/src/entrypoints/permissionsRegistry/permissionsRegistryServiceFactory.ts
Outdated
Show resolved
Hide resolved
packages/backend-plugin-api/src/services/definitions/PermissionsRegistryService.ts
Outdated
Show resolved
Hide resolved
packages/backend-plugin-api/src/services/definitions/PermissionsRegistryService.ts
Outdated
Show resolved
Hide resolved
].map(i => [i.name, i]), | ||
).values(), | ||
); | ||
): express.Router & { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, i guess why not - keeps it compatible
plugins/permission-node/src/integration/createPermissionIntegrationRouter.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Fredrik Adelöw <freben@gmail.com> Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Thank you for contributing to Backstage! The changes in this pull request will be part of the |
Hey, I just made a Pull Request!
This adds a new
PermissionIntegrationsService
that replaces the existingcreatePermissionIntegrationRouter
as well as all extensions points used to add custom rules. It removes the need to manually wire up the integrations router, and also allows for plugin modules to install additional permissions, permission rules, and even resource types.Naming-wise I've gone with
PermissionIntegrationsService
for now, but open to other options. Some other ones that I considered:PermissionsIntegrationService
PermissionRegistrationService
PermissionMetadataService
I figured that keeping "integrations" in there minimizes confusion in the migration from
createPermissionIntegrationRouter
, and is an alright name for the future too. As forPermissionIntegrationsService
vsPermissionsIntegrationService
I figured we're dealing with multiple integrations soPermissionIntegrationsService
makes more sense, but then again this does look a bit nicer:Thoughts on that? 😁
✔️ Checklist
Signed-off-by
line in the message. (more info)