I tried urls with https and without https in the list and nothing. I also tried adding the configuration using a file provider but same results, no headers in the response.
I'm running 2.2.1 and the secureHeaders middleware is defined as follows:
Its been a while since I set this up. Those CORS headers may not be sent unless triggered by a request that requires them. In most cases an origin header.
CORS is very request dependent. I found it a little complex. And is why I specifically asked how you are testing. If you are using chrome you may not actually be seeing the preflight requests, I use firefox.
Yes you should be using the full scheme://host.domain format in the accesscontrolalloworiginlist.
To get the requests I needed for testing I ran without cors headers and found a pre-flight request (OPTIONS request). I copied as cURL and used that for my testing.
I would observe the access-control-allow-origin header. I would then change the origin header in the request to a domain not in the CORS list and observe the access-control-allow-origin was not present.
The anatomy of the pre-flight request will have components that look like:
You were right. I was thinking this wrong and testing it was more complicated than I thought.
So things I was doing wrong in case someone else finds this post later on.
I was trying to reuse middleware configurations, so I had multiple headers middlewares with different configurations that should compliment each other (I was trying to reuse the parts that were identical in different services and only add differences to a different middleware). That was totally breaking and configuration got lost.
I was understanding CORS wrong. We're using a CDN that will get CORS config from the source server and then apply it when serving files and I added the CDN to my CORS allow list, but when I tried loading the page from the site it failed since the origin (my own domain) was not on the list.
I was testing it wrong I thought that the full list of values should appear as header of my response.