I’ve been working with the severless deploy lately trying migrate my API side to it rather than using netlify functions. The issue I’m trying to solve atm is that CORS settings is not respected for the Auth/current user query, this one
query __REDWOOD__AUTH_GET_CURRENT_USER { redwood { currentUser } }
Where as other graphql queries work (same function)
Using curl I can see this query does not have CORS hearders, but some of my other queries DO have cors headers.
I’m guessing because the auth is a plugin instead of a user server that it follows a different code path and that’s where the issue comes in. I’ve done a little digging and I added some logging to log out lambdaResponse
in packages/graphql-server/src/functions/graphql.ts
in the frame work, than deployed it to see if that would illuminate anything and I’m just as confused. for the above query the lambdaResponse
is
{
body: '{"data":{"redwood":{"currentUser":null}}}',
statusCode: 200,
headers: {
'access-control-allow-credentials': 'true',
'access-control-allow-origin': '*'
}
}
So it seems these headers are there being ignored but only for this query?
I’m happy to continue digging into this, but not sure where else to look in the framework?
Are you configuring CORS via the GraphQL handler options as described in Docs - GraphQL : RedwoodJS Docs ?
Yes, I am, which I assume is why most of my queries are working.
Probably relevant info that I’m using netlify/gotrue for auth.
Follow up.
I strongly suspected this is a bug, but to make sure it wasn’t a weird config issue in my project I made a minimum project to replicate it GitHub - Irev-Dev/redwood-serverless-cors-demo
and have made a GH issue CurrentUser query fails CORS · Issue #3812 · redwoodjs/redwood · GitHub
awesome, I’ll have to come back to this in a few hours, but as a quick test I’ve tried
curl 'https://mr1b728oh9.execute-api.us-east-2.amazonaws.com/.netlify/functions/graphql' \
-H 'authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MzgzNTQxOTEsInN1YiI6IjI2MWYxNWQ3LTlkNmYtNGU3OC1iM2MyLTEzMTkyMjhjYTI5YyIsImVtYWlsIjoiay5odXR0ZW5AcHJvdG9ubWFpbC5jaCIsImFwcF9tZXRhZGF0YSI6eyJwcm92aWRlciI6ImVtYWlsIn0sInVzZXJfbWV0YWRhdGEiOnt9fQ.oRinz5AnrOvoxA7X7uPGm-EVk5UEXQvrVZEHsJGwexA' \
-H 'auth-provider: netlify' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36' \
-H 'content-type: application/json' \
-H 'authority: mr1b728oh9.execute-api.us-east-2.amazonaws.com' \
-H 'pragma: no-cache' \
-H 'cache-control: no-cache' \
-H 'accept: */*' \
-H 'sec-gpc: 1' \
-H 'origin: https://main--jolly-lewin-4fa104.netlify.app' \
-H 'sec-fetch-site: cross-site' \
-H 'sec-fetch-mode: cors' \
-H 'sec-fetch-dest: empty' \
-H 'referer: https://main--jolly-lewin-4fa104.netlify.app/' \
-H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
--data-raw '{"query":"query __REDWOOD__AUTH_GET_CURRENT_USER { redwood { currentUser } }"}' \
--compressed -v
Which has all of the same headers as the post query has and I can see in the response access-control-allow-origin: *
so I think you’re onto something.
I had found this file but since it was on the request side I dismissed it.
I’m still very confused, when using curly if I add -H 'origin: https://main--jolly-lewin-4fa104.netlify.app' \
than the response contains access-control-allow-origin: *
but that’s something the browser should already ask.
Firefox gives a little more info about CORS errors than chrome:
So it looks like
access-control-allow-origin: *
is missing from the preflight, which might explain why I can’t replicate with Curl. But I’m still so confused as to why the preflight would be different when it’s hitting the same graphQL lambda function.
Doing a bit more reading on CORS I learnt that for requests with credentials are not allowed to use the wild-card *
for allowed origin but instead must use the exact origin, so I tried changing my cors config fro the handlers to
cors: {
origin: 'https://main--jolly-lewin-4fa104.netlify.app',
credentials: true,
},
and still no luck, I’m not sure what to try next.
source: Your CORS and API Gateway survival guide
Okay I figured it out 
This was the fix I needed in serverless.yml
So it was a config issue, not a bug in redwood, but it does have implications for the serverless setup command I think.
5 Likes