How do I implement auth directive for mutations with Apollo?

5
votes

I am trying to set up an Apollo backend for a project I'm working on, where I'm attempting to implement schema directives. However, I am not able to add my schema directive to mutations. So to my main question: How do I implement an auth directive for mutations?

I have added @auth(requires: ADMIN) to the end of my users query, which is working fine. Apollo will then require a bearer token with admin access for performing the users query.

extend type Query {
    user(id: ID!): User
    users: [User!]! @auth(requires: ADMIN)
}

When I tried to do it in the same way for the editMyUser mutation, the auth directive seems to be enforced for all the mutations, instead of just the one I wanted. Even the signUp mutation will give "not authorized" error, when I add the @auth part to the editMyUser mutation. Even though there is no relation between them.

The role field which is supposed to be passed to the auth directive when invoked is logging out empty.

extend type Mutation {
    signUp(
        username: String!
        firstName: String
        lastName: String
        password: String!
        isAdmin: Boolean
        isActive: Boolean): User!
    login(
        username: String!
        password: String!): User!
    editMyUser(
        id: ID!
        firstName: String
        lastName: String
        password: String): User! @auth(requires: USER)
    adminEditUser(
        id: ID!
        firstName: String
        lastName: String
        password: String
        isActive: Boolean
        isAdmin: Boolean
        isBanned: Boolean): User!
}

This is how I implemented the schema directive

export default gql`
directive @auth(requires: Role = ADMIN) on OBJECT | FIELD_DEFINITION

enum Role {
    ADMIN
    USER
}

https://github.com/jwhenshaw/graphql-directives-auth This is the Auth Directive I've implemented in my code for reference.

So to summarise, when I implement auth directives for mutations they are implemented for all mutations, instead of just the one, and it is not even working correctly, as roles are not passed on to the directive.

I would love to get some help with this. Thanks!

2
javascriptauthenticationgraphqlapolloapollo-server

2 Answers

5
votes

Within that repo the AuthDirective class passes the objectType of the field being wrapped into the ensureFieldWrapped method. What this means is that for your example where you are assigning the directive directly onto a field, editMyUser, on the object of Mutation the method is wrapping all the children of Mutation (I believe the same should be true for your Queries as well actually).

So, within the example repo, this is fine as we have an Object type User and we wrap it and its fields. However, if you do not wish to do this we can alter the AuthDirective class to wrap just the field it is on.

I have done this and pushed to the repo, https://github.com/jwhenshaw/graphql-directives-auth, where you can see there is now a FieldAuthDirective and a ObjectAuthDirective. I still need to clean the code a bit but pushed a working example and left some logs to help highlight the differences. You can view it here https://qzj70qn2mj.sse.codesandbox.io/ if you don't fancy running it locally.

Hope this helps, let me know if I need to elaborate some more.

2
votes

The issue here is that the referenced implementation throws an error when the wrapping resolver does not find any required roles (neither for the object type nor the field in question) in these lines of code.

The logic is that as you use the directive for some field of an object type, you also need to provide a requirement for the type itself. In my opinion this logic isn't too bad and is as the code comment suggests to be on the safe side. The author of that implementation probably focused on usage of the directive for actual data types, not for queries or mutations.

Let me be even a little more specific: What you and I do (as I am trying to accomplish the same thing as you today), when using the directive for one or several queries/mutations is actually applying the directive on the fields of the schema types Query and Mutation. So if we don't want a minimum requirement for all queries and/or mutations of our schema, the code should not throw an error in that condition I linked above, but it should call the wrapped resolver just as if the requirements were met (because there are none).

Example:

if (!requiredRole) {
  // No auth required, just call the resolver
  return resolve.apply(this, args);
}

I hope this helps! 🙂