4 ms·

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?

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?