Hacker News new | ask | show | jobs
by LunaSea 1362 days ago
If you serve your static files from a CDN it's simply not possible to do so.

It's a very common case.
3 comments
zmxz 1362 days 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.
link
LunaSea 1362 days 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.

link
chrisweekly 1362 days ago
It's an extremely common scenario. The obvious and straightforward solution is to configure path-based cache rules exactly like you describe, to proxy requests which don't correspond to static assets. Cloudfront allows you to do this out of the box, as do other major CDN providers. If your CDN doesn't support this, consider switching - or introduce an edge proxy to facilitate it.
link
snowwrestler 1362 days 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.)

link
LunaSea 1362 days 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.

link
snowwrestler 1362 days ago
Are you sure about that? Have you talked to a good lawyer about it?
link
LunaSea 1362 days 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.

link
zmxz 1362 days ago
Serving said JS on CDN implies that the JS performs xhr/fetch, which means I have control over said CDN

Given the fact I have control over domain(s), I'd have http://domain.tld/api for API and serve static js from http://domain.tld/static/*.js

Given the fact I have the need for CDN, it means I've got enough traffic that justifies the bill incurred

link
tomjakubowski 1361 days ago
> you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.)

What is the benefit or purpose of doing this?

link
icedchai 1361 days ago
You don't have CORS configuration to worry about. It simplifies development and deployment.
link
tomjakubowski 1361 days ago
You don't need to set up CORS to load assets on a page from a CDN's origin. Cross-origin taint only matters when trying to read asset data from a script.

I think we may be talking past each other and one of us is misunderstanding OP.

link
icedchai 1361 days ago
Yes, but you need it if your API isn't on the same origin as your static assets.
link
tomjakubowski 1361 days 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. You host your static assets on the CDN, at 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><!-- app.js renders some application here -->
    </body>
The origin when you load your site is https://example.com, so the scripts hosted on the CDN can still make API requests to https://example.com.

What am I missing here?

link
tylerhou 1362 days 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.
link
LunaSea 1362 days ago
As I mentioned above this doesn't work for all CDNs and also involves trusting your CDN to MitM your API
link
zmxz 1362 days ago
This kind of comment falls under what I posted originally - people making up reasons why they can't go with proxy solution.
link
LunaSea 1362 days 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.

link
zmxz 1361 days 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.

link
LunaSea 1361 days 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.

link