You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During discussions about using GraphQL we often mention a topic of applying things such as user permissions onto the user requests, to limit what user requested with what user can see (this proposal can probably solve more issues in the future). I was thinking about utilizing possibilities brought by having intermediate representation in form of ExecutionPlanInfo.
Idea
We could enhance ExecutionPlanInfo API with set theory operations such as union, diff and intersection. Example use:
Given a user GraphQL query:
{
# get all usersusers {
publicField1publicField4privateField2
}
}
and some perspective for user that contains all data visible for the current user (which can be i.e. cached somewhere in the user session):
{
# limit only to current user idusers (id: "1234") {
publicField1publicField2publicField3
}
}
we could apply some limitations on the produced view (i.e. limit query to span only on the current user himself and cut out private fields, he/she is not supposed to see), by simple intersection operation between execution plans of these two, which would produce:
{
# limit only to current user idusers (id: "1234") {
publicField1
}
}
Why do this at the ExecutionPlanInfo level, not on the Query AST? AST contains things such as query fragments, which will make those operations harder.
Missing parts
Dealing with field input args: example shows how we could apply arguments in the case when incoming query contained none, but how to deal with arguments that should i.e. be narrowed to specific range?
Displaying permission errors to end users: set operations assume, that we just cut the forbidden parts, but actually we should send some errors in reply with info about trying to access unauthorized fields.
The text was updated successfully, but these errors were encountered:
I've implemented an extension method that applies ASP.NET core policies by policies names to a particular field. So requesting unauthorized field will return unauthorized error for that field if nullable or bubble up if not
Motivation
During discussions about using GraphQL we often mention a topic of applying things such as user permissions onto the user requests, to limit what user requested with what user can see (this proposal can probably solve more issues in the future). I was thinking about utilizing possibilities brought by having intermediate representation in form of
ExecutionPlanInfo
.Idea
We could enhance
ExecutionPlanInfo
API with set theory operations such as union, diff and intersection. Example use:Given a user GraphQL query:
and some perspective for user that contains all data visible for the current user (which can be i.e. cached somewhere in the user session):
we could apply some limitations on the produced view (i.e. limit query to span only on the current user himself and cut out private fields, he/she is not supposed to see), by simple intersection operation between execution plans of these two, which would produce:
Why do this at the
ExecutionPlanInfo
level, not on the Query AST? AST contains things such as query fragments, which will make those operations harder.Missing parts
The text was updated successfully, but these errors were encountered: