Implementing kind of auth middleware

[lorado]

Hi. I decided to discuss it with you... I wish a possibility simply to define, if some queries are protected. As I used rebing/graphql-laravel before, I am very inspired how they solved it there.

As first - there are multiple possibilities, how it could be used (all situations are already implemented in rebing lib)

Schema-scoped

This seems to be the simplest solution. We can define multiple schemas. As option, it would be nice to define middlewares for schemas in config. Maybe something like this:

[...
    'schema' => [
        'default'     => 'default',
        'definitions' => [
            'default' => [
                'query'    => [...],
                'mutation' => [...],
                'middleware' => ['auth']
            ]
        ]
    ],
]

OR: as we speak about authorization, just define 'authorization' => true

It looks simple though, I don't think it is very useful. In my last application I was using apollo-client with some extra plugins. We decided to use single schema, but if user is logged in - then we simple added authorisation header. If user is allowed to query particular data was decided on server, depending on authorisation header. Anyway I think it is quite uncomfortable to use multiple schemas on client side, and each time to decide, which should be used... So in my opinion this option make simply no sense...

Query/Mutation-scoped

May be we could implement something like authorize() Method in query/mutation, that should return a boolean. If false is returned, then GraphQL throws an error (like 'Unauthorized'). Usage could then look like this (same as in rebing lib)

use Auth;

class UsersQuery extends Query
{
    public function authorize(array $args)
    {
        // true, if logged in
        return !Auth::guest();
    }
    ...
}

Field-scoped

This is not as much as middleware, but as idea - hide fields, that user may not access. This is called privacy in rebing lib (see here). This seems to be very helpful, but I don't know, if it is so in practice.

What do you think? Should we implement something of this?

[lorado]

I implemented a Query/Mutation-scoped approach. Unfortunately in pull request #27, but it is really a small oneliner, that was added, and it works as expected.

Changes are relevant only for Field. Transformations are still the same