4 ms·

You don't have to disable CORS to call routes on a different domain. Just configure your server properly so it knows which sites can have access to the routes.

You don't have to disable CORS to call routes on a different domain. Just configure your server properly so it knows which sites can have access to the routes. That's literally the whole point of CORS.

indigodaddy 2y ago
So like for Python just use request referrer and then have some logic for allowed referrer/URLs on all routes or something like that? Or is that something you’d more want to do at the web server or proxy level like with gunicorn/nginx/caddy? I have gunicorn in front and have been doing similarly at the Python/route level
- bitexploder 2y ago
  This is overthinking it: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS You configure it mostly in HTTP headers, generally at your HTTP server/static asset serving level.
  - Joker_vD 2y ago
    Oh, so you can use something other than * in Access-Control-Allow-Origin? That's good to know!
  - indigodaddy 2y ago
    Ok right so at web server or r. proxy level
  - KronisLV 2y ago
    > If the server specifies a single origin (that may dynamically change based on the requesting origin as part of an allowlist) rather than the "*" wildcard, then the server should also include Origin in the Vary response header to indicate to clients that server responses will differ based on the value of the Origin request header. I dislike this about CORS, especially when you'd want to configure it at the web server/ingress level, but suddenly need dynamic logic to return the appropriate header, for example here's an older example I used when fronting some apps with Apache: https://stackoverflow.com/a/22331450 https://stackoverflow.com/a/22331450 I understand why it's in place (because you probably shouldn't leak all of the allowed domains), but dealing with that can be a bit awkward.
    - bitexploder 2y ago
      Yeah, browser security on the whole is surprisingly complicated. SameSite cookies, CORS, CORS Preflight, the in the weeds behaviors of many things are just invisible or not intuitive until you are deep into them.

indigodaddy 2y ago

So like for Python just use request referrer and then have some logic for allowed referrer/URLs on all routes or something like that? Or is that something you’d more want to do at the web server or proxy level like with gunicorn/nginx/caddy? I have gunicorn in front and have been doing similarly at the Python/route level

bitexploder 2y ago
This is overthinking it: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS You configure it mostly in HTTP headers, generally at your HTTP server/static asset serving level.
- Joker_vD 2y ago
  Oh, so you can use something other than * in Access-Control-Allow-Origin? That's good to know!
- indigodaddy 2y ago
  Ok right so at web server or r. proxy level
- KronisLV 2y ago
  > If the server specifies a single origin (that may dynamically change based on the requesting origin as part of an allowlist) rather than the "*" wildcard, then the server should also include Origin in the Vary response header to indicate to clients that server responses will differ based on the value of the Origin request header. I dislike this about CORS, especially when you'd want to configure it at the web server/ingress level, but suddenly need dynamic logic to return the appropriate header, for example here's an older example I used when fronting some apps with Apache: https://stackoverflow.com/a/22331450 https://stackoverflow.com/a/22331450 I understand why it's in place (because you probably shouldn't leak all of the allowed domains), but dealing with that can be a bit awkward.
  - bitexploder 2y ago
    Yeah, browser security on the whole is surprisingly complicated. SameSite cookies, CORS, CORS Preflight, the in the weeds behaviors of many things are just invisible or not intuitive until you are deep into them.