-
Notifications
You must be signed in to change notification settings - Fork 444
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Extend user API key capabilities #5509
Comments
@NateWr, FYI. I'm content to start working towards multiple API keys per user -- that's clear enough -- but the At a basic level we could assign role IDs to API keys and use our existing permissions capabilities, but I suspect longer-term that this may not be flexible/fine-grained enough. For example, permitting an editor role wholesale is way too powerful/risky for most API interactions. Another option would be to explicitly align API key capabilities with API endpoints -- to allow for endpoints to be explicitly named and allowed. |
Sounds good. I think this goes back to discussions we had a long time ago about distinguishing roles and permissions. Access could be granted based on permissions and roles could be assigned different sets of permissions. This would be useful more generally for things like #5504 and other similar requests. In the past, I think you expressed concern that this would cause compounding complexity in the authorization system, which is already challenging enough to work with. It would certainly constitute a major refactor, but it's one that I think will have to come some day -- whether or not this is that day.
I don't think this will work as intended because many endpoints respond differently to different roles. For example, the If we don't go in for the wholesale refactor of permissions/access, I'd suggest thinking through what particular use-cases we think are needed for access in the API keys. In my experience with third-party services, there is often not a lot of fine-grained control over API key access. It's tied to a user account and given permissions based on that account. API keys are usually given out to trusted parties. If we think there are some key permissions levels that we need to disambiguate, we may be able to do that without rethinking how permissions are granted. For example, if this is really driven by the beacon's need to access stats and get a list of plugins, but not other manager responsibilities, we could create a new role under the hood, that's never surfaced to the UI (like The database table spec you set out looks good. A couple of suggestions:
|
Re: limited access to a user's capabilities, see also: #7424 (Add support for "log in as" that is scoped to the context) |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Extend user API key capabilities to support
This will make it safer to grant API keys from high-level accounts like editors/managers, and to avoid reuse of a single API key for multiple purposes.
From the document "Beacon Data Requirements":
The text was updated successfully, but these errors were encountered: