CORS issue specific to auth request

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

Do you think maybe some CORS related headers should/could be set here: redwood/AuthProvider.tsx at dc7849591febb030b78d22786201e329ca564ce0 · redwoodjs/redwood · GitHub ?

:clap: :clap: awesome, I’ll have to come back to this in a few hours, but as a quick test I’ve tried

curl '' \
  -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:' \
  -H 'pragma: no-cache' \
  -H 'cache-control: no-cache' \
  -H 'accept: */*' \
  -H 'sec-gpc: 1' \
  -H 'origin:' \
  -H 'sec-fetch-site: cross-site' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-dest: empty' \
  -H 'referer:' \
  -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:' \ 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: '',
  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 :tada:

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.