User Auth system with protected graphQL queries

[Asone]

The demo should implement a user system that would allow to build auth guarded endpoint in order to restrict some operations to the authenticated users.

[Asone]

Additional notes after some R&D :

Adding user table and auth system is quite simple and is already provided in the branch that will be delivered through #32.

However, creating a guard mechanism over the graphQL queries appears to be trickier than expected.
Different approaches have been studied.

Use multiple schemas to deliver different sets of queries over different endpoints

This approach intended to split the original schema to provide two different schemas depending on the used endpoint by the user :

1. The public endpoint that would have delivered only the queries and mutations that should not be restricted by user system
2. The admin endpoint that would have delivered a full set of queries, including the ones restricted by the user system

It is not natively possible to do that as it is not possible to merge different schemas altogether. The only way to achieve this, would have been to duplicate the methods included in the original schema which does not seem desirable as it means double maintenance for any modification that would have been provided on any schema method.

Some discussion around that topic can be found here

Create Juniper path guard

a Juniper guard feature has been proposed through a PR on Juniper repo.

The proposal modifies the codegen behavior to implement the desired guard. This is unlikely as said before because it would modify Juniper to be more a framework than just a lib.

Similarly a discussion has been debated around an authentication system in Juniper.

In both cases the approach seems to be an anti-pattern of graphQL team's recommendations as it is considered that this should be differed to the business logic layer instead of the API layer.

Anyway, a solution for this would have been to build macros to add the expected capability, however it seems that juniper currently makes impossible to use additional macros on top of the juniper ones as codegen rewrites the code in a way any proc_macro_attribute gets wiped at compilation.

Solution proposal

In order to fit as much as possible with the recommendations, it seems that the most logic and proper way to implement the user protection system would be to inject some additional data into the context and then use this data inside the query methods to allow or reject the queries/mutations.