Accessing request cookies header in a AppSync NodeJS Lambda Resolver

[isi-gach]

How can I get the request cookies in an AppSync Javascript Lambda Resolver?
It seems that it could be done using a Request Body Mapping Template
https://faragta.com/aws-api-gateway/pass-cookie-values-from-api-gateway.html
With this VTL call $util.escapeJavaScript($input.params().header.Cookie)
but I don't know what's the equivalent for Amplify/AppSync

Ideally using configuration files instead of the AWS Console UI.

The use case is reading a request cookie with the HttpOnly flag (so it's not accessible in the browser), apply sha256 to that cookie and make a new Http request.

[jkeys-ecg-nmsu]

Have you tried logging the event to the lambda and checking CloudWatch to see the structure of the input? @isi-gach

[isi-gach]

hi @jkeys-ecg-nmsu
With this lambda function:

exports.handler = function (event, context) {
  console.log(`JSON.stringify(event) = ${JSON.stringify(event)}`);
  context.done(null, 'Hello World');
};

and this in Before mapping template:

## [Start] Stash resolver specific context.. **
$util.qr($ctx.stash.put("typeName", "Query"))
$util.qr($ctx.stash.put("fieldName", "getRRBanners"))
{ "test": "$input.params().header.Cookie" }
## [End] Stash resolver specific context.. **

the request:

This is what I see on CloudWatch:

The Cookie entry is missing in the headers object and using $input doesn't seems to work

[jkeys-ecg-nmsu]

This seems like a problem with AppSync's implementation of Lambda resolvers. Have you tried sending your cookie under a different header?

[isi-gach]

hi @jkeys-ecg-nmsu
Other headers are visible, for instance, you can see my custom header "x-isi": "foo" in the screenshot above.
But the cookie that I need has the HttpOnly flag, so I cannot read it in the browser to send it as a custom header.

[jkeys-ecg-nmsu]

I would contact the AppSync service team if possible.

The fact that basic support plan accounts can't submit bug reports to service teams is unfortunate.

[LMulvey]

Hey there! I'm seeing that you're using the mapping template directly from the API Gateway tutorial, however, AppSync's mapping templates work a little differently.

If you use this as your request VTL template on your resolver:

{
    "version": "2018-05-29",
    "operation": "Invoke",
    "payload": {
        "request": $util.toJson($context.request)
    }
}

You'll be able to access the cookie inside the event parameter inside the Lambda:

exports.handler = function (event, context) {
  console.log({ request: event.request }); // request.cookie will have the cookies delimited by semi-colons
  context.done(null, 'Hello World');
};

Hope that helps!

[jkeys-ecg-nmsu]

@LMulvey sorry about not noticing that before telling OP to contact you.

On the other hand, that was very insightful and I would like to put in my vote for more samples like that in the AppSync documentation. Common resolver use cases and detailed examples on composing complex resolvers would go a long way towards eliminating these kind of questions on the Amplify issues pages.

[LMulvey]

Don't apologize to me, heh–I'm not part of the AppSync team. Just someone who's been working on it the last few months and has spent a lot of time in the docs.

I agree that there should definitely be more use case examples in the docs. This was pulled from here and tested locally: https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html but it actually makes no mention of cookies–I had to validate that myself.

[tinnou]

You're right, AppSync currently does not expose Cookies via the $ctx.request object. It is good feedback and I will take this to the team. In the meantime, would you be able to extract the cookie header on the client and use a different header to pass it through AppSync?

I'm also taking a note on updating the documentation to reflect that Cookies are not available.

[isi-gach]

hi @tinnou
The cookie has the HttpOnly flag so it's not accessible on the client. This is a big blocker for us to use AppSync. Is there any other workaround or the only alternative is to use API Gateway instead of GraphQL?

[tinnou]

@isi-gach, in that case there is no workaround to date.