Passing HTTP headers for @lambda

Users GraphQL
,
1

Hello,
is it possible to pass / add HTTP headers when using @lambda? There are similar options for @custom directive (forwardHeaders / secretHeaders), and it would be useful for @lambda also (or it could pass all client HTTP headers in a new “headers” object).

3

Hi @miko,

At present, there is no way to pass client headers to the lambda server. Could you please give a specific example of the use-case (where and how it would be useful)? and I would be happy to accept it as an enhancement request :smiley:

Thanks.

1 Like
4

Sure. I am using X-Auth-Token header to pass JWT, and @auth rules to define access level.
When using @lambda queries/mutations, I would like to have the same access level (using the same rules), so I would like to pass the same X-Auth-Header value when querying graphql endpoint.
I could use the this header also when calling external APIs (given they trust this JWT).
BTW, I am using my own lambda server implementation.

5

Great! can you share the repo if it is public?

FYI, the auth header is accessible to the lambda server. The HTTP body that is sent to the lambda server from Dgraph Alpha looks like this:

{
  "resolver": "Query.todoTitles",
  "parents": [{...}, {...}, ...],
  "args": {...},
  "authHeader": {
    "key": "<the-name-of-the-auth-header, e.g.: X-Auth-Token>",
    "value": "<value-of-the-auth-header, i.e., the JWT>"
  }
}

If you are using dgraph-lambda, then authHeader is automatically applied to the graphql() calls inside the lambda resolver:

async function todoTitles({ graphql }) {
  const results = await graphql('{ queryTodo { title } }')
  return results.data.queryTodo.map(t => t.title)
}

If you would require any other headers from the client on lambda server, let us know your use-case and we can think about supporting that.

Thanks

6

@abhimanyusinghgaur, is authHeader removed from the body when calling addGraphQLResolvers and addMultiParentGraphQLResolvers? Reviewing a docs PR and there is no mention of this authHeader in the body of these resolvers.

https://github.com/dgraph-io/dgraph-docs/pull/32

7

I think yes. It is not sent as an argument to the resolver function, but instead, if someone is using the graphql argument from inside the resolver function, then the authHeader is automatically applied to that GraphQL call.

@gja can confirm this.

1 Like
8

This may explain why my mutations aren’t working on a type with @auth rules.

I was attempting to keep a field up to date via a @lambda resolver but it doesn’t work on types with auth rules.

Is there a way to hard code an authHeader for special use cases?

I’d like to allow some internal mutations that may have higher permissions than the user may have.

9

Yes, this behavior is correct. I don’t think there is a way to avoid this behavior at the moment, the graphql() function carries forth your existing auth headers. You can entirely bypass auth by making dql queries from lambda