Skip to content
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

Intoduce set operations on the ExecutionPlanInfo #64

Closed
Horusiath opened this issue Aug 6, 2016 · 1 comment
Closed

Intoduce set operations on the ExecutionPlanInfo #64

Horusiath opened this issue Aug 6, 2016 · 1 comment

Comments

@Horusiath
Copy link
Contributor

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:

{
    # get all users
    users {
        publicField1
        publicField4
        privateField2
    }
}

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 id
    users (id: "1234") {
        publicField1
        publicField2
        publicField3
    }
}

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 id
    users (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.
@xperiandri
Copy link
Collaborator

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

@xperiandri xperiandri closed this as not planned Won't fix, can't repro, duplicate, stale Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants