Is it possible to get the headers from the request?

Hello!

First of all, thank you so much for making Graphene and Graphene Django, they’re incredible.

Currently I’m trying to implement an authentication system, my idea was to return a JWT on a successful login and then send the token in a Authorization header, however, I don’t have any idea on how to access the request headers (or even if it’s possible).

Thank you so much once again 👏

[abaskov]

@Oxyrus you can access request and its headers by using context field from info parameter in your resolve methods:

def resolve_some_field(self, info, ...):
    auth_header = info.context.META.get('HTTP_AUTHORIZATION')

However, for authentication purposes, you’d have to do that for all of your queries and mutations. Instead of that, you can define a custom view for your /graphql endpoint like this:

class TokenAuthGraphQLView(GraphQLView):
    def dispatch(self, request, *args, **kwargs):
        auth_header = request.META.get('HTTP_AUTHORIZATION')
        if valid_header(auth_header):
            return super().dispatch(request, *args, **kwargs)
        else:
            return HttpResponse('Authorization Error', status=401)

And use this view in your urls.py. You need to define valid_header function that will do actual validation.

Let me know if this helps.

[abaskov]

@Oxyrus that’s correct.

In this case, you can implement your own Middleware (http://docs.graphene-python.org/en/latest/execution/middleware/) and have different rules for different fields in your schema.

Other option would be to have two endpoints. One for non-logged users served by GraphQLView with query containing fields that should be exposed to everyone. And another endpoint served by TokenAuthGraphQLView with queries and mutations available to logged in users. I like it as it makes it easier to distinguish between public and private APIs, but GraphQL specification recommends having only one endpoint, so it might not follow the specification fully.

The third option would be to authenticate non-logged users as guests and provide access to certain fields based on your authorization rules and framework, but that’s basically the same as having authentication checks in all fields.