-
Notifications
You must be signed in to change notification settings - Fork 162
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
Support service access permissions #538
Conversation
void authorizeDataRead(String token, String keyspace, String table, SourceAPI sourceAPI) | ||
throws UnauthorizedException; |
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.
Sorry for the late comment, but having a fixed enum for sourceAPI
may be inconvenient to API extensions that are not part of this repo... 🤔
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.
What do you mean? The c2 is importing the stargate code, and this enum will be visible. The same pattern is implemented for Scope
- this is an enum as well.
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 mean if somebody implements a different "API" on top of Stargate in another repository, they will not be able to construct the sourceAPI
parameter for their API without first making changes to Stargate core, which would cause a dependency cycle.
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.
Good point, but don't you think that having type-safe API instead of string API is worth that price?
They can firstly add the new API to the SourceAPI
enum without using it. Next, they can submit a new module that leverages the new SourceAPI
value.
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.
We could use something other than a fixed enum
to identify API types. We could use the OSGi bundle ID for that, as an example, but there are many options, I guess. If we want to be able to list all possible values, we could have a service where API ID would have to be registered before they are used for authorization purposes.
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 think that the use case that we discussing now is hypothetical. Let's get back to it if it turns out that we have such a use-case and it is problematic, ok?
No description provided.