6 ms·

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse

by zmxz 4y ago

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

LunaSea 4y ago
If you serve your static files from a CDN it's simply not possible to do so. It's a very common case.
- tylerhou 4y ago
  IIRC Cloudflare has page rules, which makes this possible? In fact, with page rules, Cloudflare can proxy a subpath (like /api) to a completely different domain.
  - LunaSea 4y ago
    As I mentioned above this doesn't work for all CDNs and also involves trusting your CDN to MitM your API
    - zmxz 4y ago
      This kind of comment falls under what I posted originally - people making up reasons why they can't go with proxy solution.
      - LunaSea 4y ago
        I don't think that security requirements are a "made up" restriction. It's like saying that a house built without a lock is a made up issue and that no lock pr door is needed.
        zmxz 4y ago
        They're not, but you're blatantly refusing to read what's being written. Public CDN should never be trusted. If you use a CDN in the first place and have strict security requirements, then you create your own private CDN. And if you can control that private CDN, you have all the ingredients to avoid CORS. It's really that simple. No one is saying you are wrong, but you're refusing to look at the entire picture and you focus only on a subset, in which - of course - your argument works.
        LunaSea 4y ago
        So your point is that there is no reason to not serve everything behind the same origin, it only requires setting up a full fledged CDN to do so. I'm sorry but that's simply not an acceptable constraint.
        zmxz 4y ago
        I'm sorry that we ended up discussing this because all you did was invent situations and argued with people who didn't even state any of what you managed to read. No one is telling you not to deal with CORS your way. Fact of the matter is that you can avoid it, but you're making up reasons why you can't. The only reason you can't is because you won't. You're free to use whatever approach you like, there's no police here, just don't state that I or anyone else wrote what we didn't. It'd be grown up thing to do. Thanks and best of success with your projects.
- zmxz 4y ago
  Can you provide an example, just so we can be on the same page? You do an XmlHttpRequest or fetch() to a static asset and it's a non-trivial request to CDN, I just wonder how it looks like and why it exists in the first place.
  - LunaSea 4y ago
    Say that you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.) but you also want said static files to be served by a CDN. Basically that won't work besides making your CDN somehow proxy requests for which not static file exists.
    - snowwrestler 4y ago
      We use Fastly (the Hosts feature) to do exactly this. Basically it routes requests to different backends based on the URL path. If it starts with /assets, the backend is S3. If it starts with /api, the backend is our application. If it starts with /blog, the backend is Wordpress. All on different hosting platforms. (In case it’s not clear, Fastly is also caching and serving these requests as a CDN.)
      - LunaSea 4y ago
        So that would indicate that you don't do end-to-end TLS on your infrastructure for the API which means that Fastly man-in-the-middles your API. In a lot of sensitive businesses that wouldn't be allowed.
        snowwrestler 4y ago
        Are you sure about that? Have you talked to a good lawyer about it?
        LunaSea 4y ago
        This is not necessarily only a legal issue it's also an information security issue. You can't guarantee the integrity and privacy of the full request and response chain. This goes against various security standards and ISOs. You might be able to get away with it and trust the CDN but that's an awful lot of trust.
- tomjakubowski 4y ago
  Only if you need to read those assets from Javascript with a cross-domain request… right? (nb: you can always insert cross-origin assets to web page, with e.g. a video or img tag, you just can't read the data from JS) Say you stand up a website with an API at https://example.com https://example.com. You host your static assets on the CDN, at https://example.myfastcdn.com/ https://example.myfastcdn.com/. So example.com's home page looks like: <head> <script src="https://example.myfastcdn.com/app.js"></script> </head> <body> <div id="site-root"></div> </body> The origin when you load your site is https://example.com https://example.com, so the scripts hosted on the CDN can still make API requests to https://example.com https://example.com. What am I missing here?
beebeepka 4y ago
Well, sure. But, as a non-expert, cors kind of makes sense to me in development. What would you suggest? It's an honest question.
- jeroenhd 4y ago
  Running a proxy on localhost isn't very difficult; it requires maybe 10 or 20 lines of nginx config, less with Caddy? Certainly something that can be stuffed into the README for developers.
  - taberiand 4y ago
    Or better yet, into the devcontainer
- zmxz 4y ago
  A web server (nginx) that can proxy your request to the other domain, but your browser sends everything to one domain, thus avoiding CORS. Example: you have http://ui.localhost http://ui.localhost and you have http://api.localhost http://api.localhost UI speaking to API = CORS But, instead of doing fetch('http://api.localhost/resource http://api.localhost/resource'), you do fetch('http://ui.localhost/api/resource http://ui.localhost/api/resource') In the nginx config for ui.localhost domain, you create a rule that says "everything that starts with /api, intercept it, remove /api at the start of the path and send the rest to http://api.localhost http://api.localhost, ending up with http://api.localhost/resource http://api.localhost/resource" I do frontend and backend development and I have this setup with docker-compose, the config for nginx is really trivial and widely available in many tutorials.
  - rojer_31 4y ago
    Scenario: In production where assuming ui.example.com is only for static resources/SSG and api.example.com is for dynamic api endpoints, we usually protect the api domain with WAF in CDN which will cost extra and typically unnecessary for the UI domain. So in this case by doing this reverse proxy, we will bypass the WAF layer or atleast feed WAF incorrect data (our server is requesting instead of the user directly). Since WAF usually has extra (significant) costs, what would you suggest in this case?
moring 4y ago
I'll bite. I'm working on an application that uses Firebase, so the front-end is hosted on Firebase hosting (probably with some kind of CDN before that) and available through a firebase-supplied domain, and the back-end runs on Cloud Run behind a cloud-run-supplied domain. The domains are different, so CORS happens. I'd like you to back up your claim that a server-side proxy or using the same domain is the easiest solution, and in particular, easier than the solutions suggested by cakoose.
- djsweet 4y ago
  I've worked with Firebase Hosting for around three years, using Firebase Functions instead of Cloud Run, but in your particular example, you can configure your Firebase Hosting to rewrite requests against your Cloud Run instances as documented in https://firebase.google.com/docs/hosting/full-config#rewrite-cloud-run-container https://firebase.google.com/docs/hosting/full-config#rewrite.... This doesn't require handling an OPTIONS request for every endpoint, which I agree could be fairly simple, but Firebase Hosting configuration could very well be less invasive than this change in the rest of the codebase.
  - moring 4y ago
    Thanks a lot, I'll have a look into this.
- zmxz 4y ago
  There's 1 way to solve this, and it's to have the same domain that the end client (browser, app) uses. It means you'd create 1 domain that's exposed to client and on the web server level you perform routing (proxying) to appropriate firebase/cloud run domains. As for whether that's easier - I've been doing it like this since forever, so I'm biased and it's easy for me. It's easy because I don't have to worry about problems related to cross origin resource sharing and because I know how to write the necessary configs. If you don't have to walk through mine field, you never worry about mines. That's the easy part I refer to. I don't even need to test whether CORS is set up properly, worry about preflight and what not etc. - it works, forever. Whether it will be as easy for you, I can't tell that, you can have completely different opinion and be correct about it, but the fact remains that proxy between 2 resources removes the problem. I consider problem removed as something easy, you might not.
chopin 4y ago
Authentication with a SAML provider can make this a pain in the ass. Especially if you don't have control over the provider.
icedchai 4y ago
Many devs (young or not, age doesn't matter) simply have no idea how CORS works and don't understand the "same origin" policy. I've seen hundreds of hours wasted on CORS / OPTIONs request implementations that could've been saved with a reverse proxy, if only they knew what one was.
- LanceH 4y ago
  CORS is one of my favorite interview questions (front-end/react dev) as it has the potential to tell me if the interviewee is the person who has researched the problem and implemented solutions. There is a lot of potential discussion from how it works, why it's necessary, to how it is solved in production vs development.
  - javier2 4y ago
    CORS is something I 'fixed' once, five years ago. Hard to talk in detail about that anymore. I wish we would have the time to implement it safely, but alas. We still can't produce an allowList of allowed domains :/
    - LanceH 4y ago
      > CORS is something I 'fixed' once, five years ago I'm careful that I don't demand anyone go into depth on any particular subject. CORS is just one opportunity that seems to need a fix with every new project. It also has a variety of solutions, which is again opportunity to show what they know. There is little point in looking for what a client doesn't know. I've got that covered.

by zmxz 4y ago

LunaSea 4y ago

If you serve your static files from a CDN it's simply not possible to do so. It's a very common case.

tylerhou 4y ago
IIRC Cloudflare has page rules, which makes this possible? In fact, with page rules, Cloudflare can proxy a subpath (like /api) to a completely different domain.
- LunaSea 4y ago
  As I mentioned above this doesn't work for all CDNs and also involves trusting your CDN to MitM your API
  - zmxz 4y ago
    This kind of comment falls under what I posted originally - people making up reasons why they can't go with proxy solution.
    - LunaSea 4y ago
      I don't think that security requirements are a "made up" restriction. It's like saying that a house built without a lock is a made up issue and that no lock pr door is needed.
      - zmxz 4y ago
        They're not, but you're blatantly refusing to read what's being written. Public CDN should never be trusted. If you use a CDN in the first place and have strict security requirements, then you create your own private CDN. And if you can control that private CDN, you have all the ingredients to avoid CORS. It's really that simple. No one is saying you are wrong, but you're refusing to look at the entire picture and you focus only on a subset, in which - of course - your argument works.
        LunaSea 4y ago
        So your point is that there is no reason to not serve everything behind the same origin, it only requires setting up a full fledged CDN to do so. I'm sorry but that's simply not an acceptable constraint.
        zmxz 4y ago
        I'm sorry that we ended up discussing this because all you did was invent situations and argued with people who didn't even state any of what you managed to read. No one is telling you not to deal with CORS your way. Fact of the matter is that you can avoid it, but you're making up reasons why you can't. The only reason you can't is because you won't. You're free to use whatever approach you like, there's no police here, just don't state that I or anyone else wrote what we didn't. It'd be grown up thing to do. Thanks and best of success with your projects.
zmxz 4y ago
Can you provide an example, just so we can be on the same page? You do an XmlHttpRequest or fetch() to a static asset and it's a non-trivial request to CDN, I just wonder how it looks like and why it exists in the first place.
- LunaSea 4y ago
  Say that you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.) but you also want said static files to be served by a CDN. Basically that won't work besides making your CDN somehow proxy requests for which not static file exists.
  - snowwrestler 4y ago
    We use Fastly (the Hosts feature) to do exactly this. Basically it routes requests to different backends based on the URL path. If it starts with /assets, the backend is S3. If it starts with /api, the backend is our application. If it starts with /blog, the backend is Wordpress. All on different hosting platforms. (In case it’s not clear, Fastly is also caching and serving these requests as a CDN.)
    - LunaSea 4y ago
      So that would indicate that you don't do end-to-end TLS on your infrastructure for the API which means that Fastly man-in-the-middles your API. In a lot of sensitive businesses that wouldn't be allowed.
      - snowwrestler 4y ago
        Are you sure about that? Have you talked to a good lawyer about it?
        LunaSea 4y ago
        This is not necessarily only a legal issue it's also an information security issue. You can't guarantee the integrity and privacy of the full request and response chain. This goes against various security standards and ISOs. You might be able to get away with it and trust the CDN but that's an awful lot of trust.
tomjakubowski 4y ago
Only if you need to read those assets from Javascript with a cross-domain request… right? (nb: you can always insert cross-origin assets to web page, with e.g. a video or img tag, you just can't read the data from JS) Say you stand up a website with an API at https://example.com https://example.com. You host your static assets on the CDN, at https://example.myfastcdn.com/ https://example.myfastcdn.com/. So example.com's home page looks like: <head> <script src="https://example.myfastcdn.com/app.js"></script> </head> <body> <div id="site-root"></div> </body> The origin when you load your site is https://example.com https://example.com, so the scripts hosted on the CDN can still make API requests to https://example.com https://example.com. What am I missing here?

beebeepka 4y ago

Well, sure. But, as a non-expert, cors kind of makes sense to me in development. What would you suggest? It's an honest question.

jeroenhd 4y ago
Running a proxy on localhost isn't very difficult; it requires maybe 10 or 20 lines of nginx config, less with Caddy? Certainly something that can be stuffed into the README for developers.
- taberiand 4y ago
  Or better yet, into the devcontainer
zmxz 4y ago
A web server (nginx) that can proxy your request to the other domain, but your browser sends everything to one domain, thus avoiding CORS. Example: you have http://ui.localhost http://ui.localhost and you have http://api.localhost http://api.localhost UI speaking to API = CORS But, instead of doing fetch('http://api.localhost/resource http://api.localhost/resource'), you do fetch('http://ui.localhost/api/resource http://ui.localhost/api/resource') In the nginx config for ui.localhost domain, you create a rule that says "everything that starts with /api, intercept it, remove /api at the start of the path and send the rest to http://api.localhost http://api.localhost, ending up with http://api.localhost/resource http://api.localhost/resource" I do frontend and backend development and I have this setup with docker-compose, the config for nginx is really trivial and widely available in many tutorials.
- rojer_31 4y ago
  Scenario: In production where assuming ui.example.com is only for static resources/SSG and api.example.com is for dynamic api endpoints, we usually protect the api domain with WAF in CDN which will cost extra and typically unnecessary for the UI domain. So in this case by doing this reverse proxy, we will bypass the WAF layer or atleast feed WAF incorrect data (our server is requesting instead of the user directly). Since WAF usually has extra (significant) costs, what would you suggest in this case?

moring 4y ago

I'll bite. I'm working on an application that uses Firebase, so the front-end is hosted on Firebase hosting (probably with some kind of CDN before that) and available through a firebase-supplied domain, and the back-end runs on Cloud Run behind a cloud-run-supplied domain. The domains are different, so CORS happens. I'd like you to back up your claim that a server-side proxy or using the same domain is the easiest solution, and in particular, easier than the solutions suggested by cakoose.

djsweet 4y ago
I've worked with Firebase Hosting for around three years, using Firebase Functions instead of Cloud Run, but in your particular example, you can configure your Firebase Hosting to rewrite requests against your Cloud Run instances as documented in https://firebase.google.com/docs/hosting/full-config#rewrite-cloud-run-container https://firebase.google.com/docs/hosting/full-config#rewrite.... This doesn't require handling an OPTIONS request for every endpoint, which I agree could be fairly simple, but Firebase Hosting configuration could very well be less invasive than this change in the rest of the codebase.
- moring 4y ago
  Thanks a lot, I'll have a look into this.
zmxz 4y ago
There's 1 way to solve this, and it's to have the same domain that the end client (browser, app) uses. It means you'd create 1 domain that's exposed to client and on the web server level you perform routing (proxying) to appropriate firebase/cloud run domains. As for whether that's easier - I've been doing it like this since forever, so I'm biased and it's easy for me. It's easy because I don't have to worry about problems related to cross origin resource sharing and because I know how to write the necessary configs. If you don't have to walk through mine field, you never worry about mines. That's the easy part I refer to. I don't even need to test whether CORS is set up properly, worry about preflight and what not etc. - it works, forever. Whether it will be as easy for you, I can't tell that, you can have completely different opinion and be correct about it, but the fact remains that proxy between 2 resources removes the problem. I consider problem removed as something easy, you might not.

chopin 4y ago

Authentication with a SAML provider can make this a pain in the ass. Especially if you don't have control over the provider.

icedchai 4y ago

Many devs (young or not, age doesn't matter) simply have no idea how CORS works and don't understand the "same origin" policy. I've seen hundreds of hours wasted on CORS / OPTIONs request implementations that could've been saved with a reverse proxy, if only they knew what one was.

LanceH 4y ago
CORS is one of my favorite interview questions (front-end/react dev) as it has the potential to tell me if the interviewee is the person who has researched the problem and implemented solutions. There is a lot of potential discussion from how it works, why it's necessary, to how it is solved in production vs development.
- javier2 4y ago
  CORS is something I 'fixed' once, five years ago. Hard to talk in detail about that anymore. I wish we would have the time to implement it safely, but alas. We still can't produce an allowList of allowed domains :/
  - LanceH 4y ago
    > CORS is something I 'fixed' once, five years ago I'm careful that I don't demand anyone go into depth on any particular subject. CORS is just one opportunity that seems to need a fix with every new project. It also has a variety of solutions, which is again opportunity to show what they know. There is little point in looking for what a client doesn't know. I've got that covered.