Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to win at CORS

jakearchibald.com

Post reply on HN
Print view View original

41–50 of 128 posts

Re: How to win at CORS

#41

Post by Benjamin_Dobell »

88913527 wrote: post #28
jaffathecake wrote: post #27

Earlier quoted context omitted.

Author here! The post covers this detail. This happens because your response is missing a Vary header. Getting Vary right isn't just important for Chrome, it's important for CDNs too.

You're right, the real issue is CloudFront won't include Origin in the Vary response header if it wasn't included in the initial request. And if you change your HTML attributes, you're changing your request, but you essentially end up with a poisoned local cache. Rolling out crossorigin="anonymous" on previously cached assets is a subtlety you won't know about (even if you think you know CORS) until your site breaks…

If your data is coming from an S3 origin and the original (cached request) was not CORS (but you also want to support CORS), then you can inject the necessary headers with Lambda@Edge or CloudFront Functions.

S3 is used as an example, as it does not include a Vary header for non-CORS requests. However, the same would be true of some other origin which isn't correctly inserting a Vary header.

Re: How to win at CORS

#42

Post by jaffathecake »

jaffathecake wrote: post #36
88913527 wrote: post #28

Earlier quoted context omitted.

You're right, the real issue is CloudFront won't include Origin in the Vary response header if it wasn't included in the initial request. And if you change your HTML attributes, you're changing your request, but you essentially end up with a poisoned local cache. Rolling out crossorigin="anonymous" on previously cached assets is a subtlety you won't know about (even if you think you know CORS) until your site breaks…

Yeah, it's generally understood that you need to change the URL to cache-bust when the content changes, but it's easy to forget that you need to do the same thing if important headers change. Hmm, I think I'll add a section to the article on this when I'm back at my laptop.

Aaaand it's done https://jakearchibald.com/2021/cors/#cors-and-caching

Thanks for prompting this!

Re: How to win at CORS

#43

Post by jaffathecake »

roca wrote: post #38

I tried really hard to get and to default to requiring same-origin but people were still skeptical about CORS deployment, and there were also arguments for consistency with . Oh well, I think we eventually got to a consensus that that "consistency" is not worth having.

I think you folks were in a really tricky spot. Making / require CORS would have been the right decision for security reasons, particularly since / introduces range requests. It would have prevented these security bugs https://jakearchibald.com/2018/i-discovered-a-browser-bug/.

However, the competition at the time was Flash, and making / so much harder than it was with Flash would have put developers off.

Fwiw, I regret that opaque responses can go into the service worker cache, since it caused quota-sniffing issues that we had to work around. But, if we didn't allow it, it would have been a feature regression vs appcache. sigh

Re: How to win at CORS

#44

Post by jaffathecake »

billfruit wrote: post #20
jaffathecake wrote: post #17

Earlier quoted context omitted.

Author here! I added a small reference to the acronym in the article, but I don't think it really matters. I actually forgot what it stands for the other week, but it didn't prevent me understanding it. And relearning the acronym didn't help me understand it more.

Thank you. I was just nitpicking, there.

At least the expansion of the acronym isn't actively harmful to understanding what it is, unlike AJAX, JAMStack etc etc

Re: How to win at CORS

#45

Post by humbleMouse »

jaffathecake wrote: post #17
billfruit wrote: post #2

How they jump into the article without explaining or even expanding what the CORS acronym stands for.

Author here! I added a small reference to the acronym in the article, but I don't think it really matters. I actually forgot what it stands for the other week, but it didn't prevent me understanding it. And relearning the acronym didn't help me understand it more.

I’m pretty sure “Cross Origin Request” is extremely helpful for people learning this concept. It literally describes exactly what is happening.

Re: How to win at CORS

#46

Post by humbleMouse »

nhumrich wrote: post #30

How to win at CORS: Don't use it. Just put the apis you need on the same domain, use a reverse proxy. Same-site just works, always.

Exactly, the whole concept of CORS is just a security issue waiting to happen. Especially these days with all these cloud systems having 14 network layers that all ignore certain headers and add other ones.

Re: How to win at CORS

#47

Post by jaffathecake »

chrismorgan wrote: post #34
jaffathecake wrote: post #26

Earlier quoted context omitted.

Seems like your HTML formatting opinions are very similar to the owner of the fetch spec! Yeah, I don't always agree with Prettier, but ugh, I wasted hours in my early career arguing about formatting with teammates, but now I just let Prettier do it's thing, get over it, and spend the time on something else.

Hence me only living life on the edge like that in personal projects! Most of what I write with others these days is in Rust, and I definitely go along with using rustfmt on such projects, even if I regularly dislike its opinions (sometimes even strongly).

If you're interested, the discussion rages on in https://github.com/prettier/prettier/issues/5246

Re: How to win at CORS

#48

Post by Animats »

You can't always access an image across origin boundaries.

If you load an IMG into WebGL as a texture, that's not allowed cross-domain. It's considered "processing" the image, rather than just displaying it. I ran into this when displaying slippy maps from map tiles. You can display the map tiles with JavaScript regardless of origin, but use WebGL, and you have to deal with the origin problem.

Re: How to win at CORS

#49

Post by jaffathecake »

Animats wrote: post #48

You can't always access an image across origin boundaries. If you load an IMG into WebGL as a texture, that's not allowed cross-domain. It's considered "processing" the image, rather than just displaying it. I ran into this when displaying slippy maps from map tiles. You can display the map tiles with JavaScript regardless of origin, but use WebGL, and you have to deal with the origin problem.

The article covers this. It's because WebGL has texture readback, giving you access to the pixel data.

Reading image pixels isn't allowed unless the resource passes a CORS check.

Re: How to win at CORS

#50

Post by pachico »

Rather than adding my own personal experience in the matter, I want to do gratulate the author for the article.

It's engaging and even entertaining. Very well done!

Post reply on HN