CORS settings ESPv2 not working as intended

[Eric Wennerberg]

Hello!

Thanks to ESP we should be able to talk directly from our frontend clients (Web) to our backend gRPC services, without using gRPC-web, which is great. 

However, we are running into issues with the CORS settings. We have been following this documentation and set `--cors_preset=basic` in our startup options (we have not been setting specific "Allow-Origin" settings as this has only been tried in development). With this startup option, we can successfully get the pre-flight OPTIONS HTTP request from the client to work (headers returned), but the "real" request does not work. The real request does hit our backend and returns a response, as expected, but the CORS-headers are not returned from ESP and our browser blocks the response from reaching the client.

Are we missing something in our setup, or is this expected behavior from ESPv2?

Best regards

[Kristian Drucker]

Hey,

Did you try setting `--cors_expose_headers` to the headers you want returned?

Kristian

[Eric Wennerberg]

No, we did not try that setting, but expected CORS specific headers (`Access-Control-Allow-Origin` etc) to be returned without having to be exposed. Especially since they are already exposed in the preflight response.

[Eric Wennerberg]

I will try to set that header, and let you know what I find! Thanks

[Kristian Drucker]

From my experience, ESPv2 drops headers that aren't defined in there, so rather have it there than not.

[Eric Wennerberg]

Tried again with these settings:
`--cors_preset=basic`
`--cors_expose_headers="Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Headers"`

Still get the same response (no CORS headers at all in the "real" request).

Get the following headers from pre-flight response:

access-control-allow-headers:

DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization

access-control-allow-methods:

GET, POST, PUT, PATCH, DELETE, OPTIONS

access-control-allow-origin:

http://localhost:3000

access-control-expose-headers:

"Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Headers"`

So, the new setting is applied (I see my newly exposed headers in the list), but real request still contains no CORS headers.

[Wayne Zhang]

Hmm,  the development environment works, but production doesn't work.  What is the difference between these two when deploying ESPv2?  

Could you check if the CORS flags have been set to the production environment correctly?  Usually you can check logging in Cloud Console. 

I assume you did not set this flag --cors_allow_origin=. If set, you may have to change it to production server name.

If not set, its default is "*" which should match any host.

You can even enable debug by adding flag --enable_debug to get more detail information

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/e66e2f26-d2e0-47ec-9282-32084fc89de0n%40googlegroups.com.

[Eric Wennerberg]

I should clarify, we have only tested in development (with settings from documentation), and that does not work.

We also enabled debug, but were not able to find anything useful in the logs.

We don't think the problem is with what settings we are using, but rather that only the browser pre-flight request will be returned the correct CORS headers. The subsequent GET (which hits our backend service) will not have these headers set, and the browser rejects it.

[Wayne Zhang]

Could you send the ESPv2 log with enabled debug to me? I can help to take a look at it. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/ed9e208f-0810-46ed-9dca-72950cf82a91n%40googlegroups.com.

[qiwz...@google.com]

Any update? 

[Eric Wennerberg]

Hello, 

Sorry for late reply!

We have not pursued this any further yet, and don't have any logs to share at this moment.

Thanks