Support service access permissions #538
Conversation
tomekl007
requested review from
dimas-b,
dougwettlaufer,
EricBorczuk,
mpenick,
olim7t and
pcmanus
as code owners
| void authorizeDataRead(String token, String keyspace, String table, SourceAPI sourceAPI) | ||
| throws UnauthorizedException; |
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.