Swagger-ui: Response headers incomplete when making CORS requests

[blortfish]

• OS: macos
• Browser: chrome
• Version: 66
• Method of installation: npm
• Swagger-UI version: 3.15.0
• Swagger/OpenAPI version: 2.0

Describe the bug you're encounering

I've noticed that when you host swagger-ui on a particular domain and you make calls to a CORS enabled api, not all response headers are shown. I think this may be a bug related to the preflight OPTIONS call, but I may just be misunderstanding something.

To reproduce...

1. Run this endpoint with the provided sample data: http://petstore.swagger.io/#/pet/addPet and notice your response will include headers. Likely something like this -
   
2. Download and setup swagger-ui locally following readme instructions for development. Run the same endpoint. This should be hosted at http://0.0.0.0:3200/#/pet/addPet Making the same call I see something like this -
   

Expected behavior

The response headers should be very similar since the call is made to the same endpoint

Additional context or thoughts

I believe that something is going awry when CORS is required. I tested this assumption by hosting the same petstore swagger document locally at http://0.0.0.0:3200/test.json , removing the host property making CORS unnecessary. I received this in response -

Of course the actual call failed (404) since i'm not hosting the api, but I do in fact receive the expected response headers from the dev server.

[hkosova]

See if this helps: https://github.com/swagger-api/swagger-ui/issues/3340#issuecomment-313550973

[shockey]

Hey @blortfish!

It's a CORS issue indeed - the browser only exposes a response header to Swagger-UI if that header is listed in Access-Control-Expose-Headers. Note that Allow-Headers (which you did define) is to tell the browser what request headers it can send, and Expose-Headers is to tell the browser what response headers it can read.

There are a few allowed by default, which is why you're seeing some but not all of your headers 😄

[shockey]

PS: Looks like @hkosova beat me to it, as usual 😉

You might be able to get away with Access-Control-Expose-Headers: * if you only need to support newer browsers - it was added to the Fetch living standard in 2015. Do some checks on your end if you end up using that trick.

[blortfish]

Ahh apologies for duplicating. Unfortunately, I don't have access to the API servers that would need to serve up the header. Being that this is part of CORS I don't think there would be any work around. It seems reaching out to API owners is the only option.

That said, if there is some other way around this I'm all ears. If not, feel free to close this issue. Thanks for the quick response!

[shockey]

@blortfish, while you're right in that there's not really a way to throw out CORS.... you do have a couple of options while you wait to hear back:

• Run your browser without CORS enabled. With Chrome, the --disable-web-security command line flag will get you there. Also consider browser extensions, looks like there's a few out there that claim to be able to toggle CORS enforcement on and off.
• Use a CORS proxy to talk to the API. Some public ones exist, like Crossorigin.me[1] and CORS Anywhere[2]. If privacy or ownership of your infrastructure is a concern, CORS Anywhere is also available as a library[3], and CORS-Proxy[4] publishes a Docker image that you can spin up wherever you'd like to.

[blortfish]

@shockey thank you for all of the suggestions and information. These are all great options to consider. In the end we will be recommending that our users either whitelist headers in Access-Control-Expose-Headers or allow *.

[lock[bot]]

Locking due to inactivity.

This is done to avoid resurrecting old issues and bumping long threads with new, possibly unrelated content.

If you think you're experiencing something similar to what you've found here: please open a new issue, follow the template, and reference this issue in your report.

Thanks!