I'm currently running into issues with the CORS assertion and IE 11. I've verified that this RestAPI endpoint is working without any issues in Chrome and Microsoft Edge.
I've configured the CORS assertion with the following settings and I always receive an error message in the IE developer console stating:
Viewing the Network tab I can see that the initial Preflight request is being made using the HTTP OPTIONS method with the Access-Control-Allow-Headers value in the Request and Response both containing the api-key header.
Has anyone else ran into this issue and found a way around it?
My settings in the CORS assertion are as follows:
Can you confirm the version of Gateway you are using? We had seen this in versions prior to 9.3 specifically with IE11.
Resolved Issues - CA API Gateway - 9.3 - CA Technologies Documentation
This issue stemmed from the presence of multiple "Access-Control-Allow-Headers" headers.
I'm using version 9.3.
So this seems like this may be a bug? Doing the following resolves the issue in IE:
Apologies on the delay. What change was made? It looks like you remove the header and then immediately add it back. Since it is already on 9.3, without this in place are you seeing the multiple headers?
Access-Control-Allow-Headers: authorization Access-Control-Allow-Headers: x-request-id Access-Control-Allow-Headers: x-msg-id
Removing the header and then immediately adding it back was the only changed that I made to the policy. Without those two assertions in place I end up receiving the same error message that I was seeing before only in IE 11:
Request header api-key was not present in the Access-Control-Allow-Headers listAccess is denied
What is odd is that the request header is present in the Access-Control-Allow-Headers list even without these two assertions in place. I haven't had a chance to use wireshark or another proxy to see in more detail what the API Gateway is sending back to the client using IE 11 but using the network tab in IE's dev tools I can see that the correct Access-Control-Allow-Headers key/value is being sent in the request from the client and then included in the response from the gateway.
However, without these assertions it still works fine in Chrome and Firefox by just using the Process CORs assertion using the settings that I documented above. IE 11 is the only browser that I run into this issue with.
Just to verify, because this seems like either a new "bug" or a reversion of one we fixed before, can you please verify the version? I know you noted 9.3, but if you can perhaps provide the output of the following command, it should help us better understand what version and what CR has been applied. I also of course want to rule out the possibility that this system is really on 9.2 instead of 9.3 (we've seen that happen many times before, especially from customers who run with a mix of versions in their environments).
rpm -qa | grep ssg
Additionally, if you can, please include the version of the OS you are running IE on and what the specific version of IE is too so we can best try to reproduce this in our labs.
I don't have access to the ssgroot account at the moment to run that command, however I'm able to see the following via the ssgconfig account:
- ssg-nshieldpci-12.30.00-1.el6_x86_64 - ssg-9.3.00-7814_noarch - ssg-platform-1.7.00-181_noarch - ssg-appliance-9.3.00-7814_x86_64 - ssem-1.18.00-6750_noarch
Additionally, connecting via the Policy Manager I can see that the API Gateway is version 9.3.00-CR01.
OS: Windows 10 Enterprise x64
IE: IE 11
Perfect. Thank you, Matthew. It is indeed 9.3.00 CR1 then, which is good. This definitely sounds like it has the potential to be a bug (perhaps either a new one or the previous one we mentioned as it may have come back in the latest version). At this point, I believe a support case may be needed so we can more securely gather the necessary information and run some tests in your environment to see if we can narrow it down any further, and we can then have it more formally tracked with our Engineering team. Please let me know once you've opened it, as I'd like to keep an eye on it when filed so that we can come back here with the resolution for others who are coming across this thread.
Okay the issue is with the multiple headers that IE 11 does not like so you need to use the cluster wide property cors.useMultiValuedHeaders and set it to true from the default of false. This will remove the need to have the header assertions.
Quick note: I created this idea in the community to make it true by default as I don't see any reasons why it shouldn't be true out of the box. Make cors.useMultiValuedHeaders default to "true" instead of "false".