3 ms·

> It's a nice way to make an API "public", or would be if CORS supported a goddam wildcard for the host. I don't get what you mean. Access-Control-Allow-Origin

> It's a nice way to make an API "public", or would be if CORS supported a goddam wildcard for the host. I don't get what you mean. Access-Control-Allow-Origin supports a wildcard. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin#syntax https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

chuckadams 2y ago
Yah you saw that before I edited it out, I realized that gripe was actually about the behavior of AWS API Gateway rather than CORS itself. It hates the wildcard, or something, I can't even remember exactly what the issue was. Thus did I zap it.
LudwigNagasena 2y ago
Also, nothing prevents you from checking the host server-side according to arbitrary logic and putting it into the CORS header dynamically.
- Retr0id 2y ago
  Nothing prevents this, but the client must still emit preflight checks (an extra round-trip) for every endpoint, and again if headers need to change.
dopp0 2y ago
I think what he meant is that the wildcard is not supported in the origin itself, for instance: https://*.somedomain.com https://*.somedomain.com. per documentation, it's either "*" or "https://subdomain.somedomain.com https://subdomain.somedomain.com"
- chuckadams 2y ago
  That was in fact it, lack of a subdomain wildcard. I got really confused because I opened one project I thought had this issue, saw the ACAO header was set to *, and thought I hallucinated the whole thing out of some different issue. But it was a different project where I needed to allow internal access, which would have been easy with a hardwired response with a wildcard, but instead I needed to write a whole lambda endpoint just to pull out the requesting host and put it in the ACAO header. Also easy, but what a waste. Either way, kind of a digression into details of CORS that wasn't necessary for the introductory treatment, so I edited it out.

chuckadams 2y ago

Yah you saw that before I edited it out, I realized that gripe was actually about the behavior of AWS API Gateway rather than CORS itself. It hates the wildcard, or something, I can't even remember exactly what the issue was. Thus did I zap it.

LudwigNagasena 2y ago

Also, nothing prevents you from checking the host server-side according to arbitrary logic and putting it into the CORS header dynamically.

Retr0id 2y ago
Nothing prevents this, but the client must still emit preflight checks (an extra round-trip) for every endpoint, and again if headers need to change.

dopp0 2y ago

I think what he meant is that the wildcard is not supported in the origin itself, for instance: https://*.somedomain.com https://*.somedomain.com. per documentation, it's either "*" or "https://subdomain.somedomain.com https://subdomain.somedomain.com"

chuckadams 2y ago
That was in fact it, lack of a subdomain wildcard. I got really confused because I opened one project I thought had this issue, saw the ACAO header was set to *, and thought I hallucinated the whole thing out of some different issue. But it was a different project where I needed to allow internal access, which would have been easy with a hardwired response with a wildcard, but instead I needed to write a whole lambda endpoint just to pull out the requesting host and put it in the ACAO header. Also easy, but what a waste. Either way, kind of a digression into details of CORS that wasn't necessary for the introductory treatment, so I edited it out.