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

71–80 of 128 posts

Re: How to win at CORS

#71

Post by eurasiantiger »

thepasswordis wrote: post #37

CORS has been no shortage of greys in my beard! When I'm writing some frontend that is hosted on localhost, with an API that is hosted on its domain somewhere, it always is some sort of PITA to get the dev environ started. There's a plugin for firefox that ignores CORS which is helpful for this. It's becoming less useful for me as my APIs now usually have a toggle to add a cross origin header which allows localhost.…

Just use http-proxy to set up a local domain so you can access your dev environment at frontend.yoursite.local (proxied to localhost:3000) and the api at api.yoursite.local (proxied to whatever 3rd party api). Boom, problem solved. You can even rewrite headers and content of the requests in and out.

Re: How to win at CORS

#72

Post by mrweasel »

kindall wrote: post #7
billfruit wrote: post #2

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

If you don't already know what CORS is, you're probably not a Web developer and don't need to know.

Sometimes OPS people get the job of fixing CORS for developers who don't understand how it works exactly.

I work with a client who built a web app in... Vue, I think. For unknown reasons they decided that it would be better that the APIs they need to call to live on the same domain. At the same time, the developers decided that the API microservices should not return CORS headers. Instead it was left to operations to hack in CORS headers in the webserver/loadbalancer.

Re: How to win at CORS

#73

Post by speleding »

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…

Ha, I feel your pain, I ran into something similar with Chrome and Cloudfront.

For us it got triggered because an image on the site appeared both as a video "poster" attribute (which loads with CORS) and as a regular image. So depending on which image the user encountered first you would see a CORS error. But it would be gone after a reload, so devilishly hard to reproduce until you realise what's happening.

Also took me ages to figure out that Cloudfront didn't include the Origin in the Vary header if it wasn't in the original request.

(@jaffathecake perhaps that Cloudfront behaviour warrants a special mention. Great article by the way, I learned a lot)

Re: How to win at CORS

#74

Post by jaffathecake »

fadikhadra wrote: post #70
jaffathecake wrote: post #64

Bonus fact: I wanted the 'app' ( https://jakearchibald.com/2021/cors/playground/ ) to allow the HTTP method to be set to anything, which meant I needed a server that could accept anything. I usually use NodeJS, but it turns out the HTTP library they use turns the HTTP method into an enum, so only a subset is supported ( https://github.com/nodejs/node/blob/d798de1c653efa5ec0015d44... ). This restriction only exists in…

Hey Jake, would love to see this topic discussed in HTTP 203!

We've got an episode on Deno https://www.youtube.com/watch?v=SYkzk_j3yb0&list=PLNYkxOF6rc..., and another which covers cross-origin fetches https://www.youtube.com/watch?v=vfAHa5GBLio&list=PLNYkxOF6rc... (although it isn't CORS specific), or did you mean something more specific?

Re: How to win at CORS

#75

Post by qubyte »

This is the resource I wish I'd had some years ago when I was starting out as a server dev. I remember the (lack of a) Vary header in particular causing me hours of frustration.

Re: How to win at CORS

#76

Post by lwouis »

When developing a webapp these days, I use a local proxy.

This allows me to type a staging/production URL into Chrome, and get the frontend and the backend from either my local machine or staging/prod. I can mix and match any combination by checking/unchecking a box in Proxyman.

This means there is no need to whitelist localhost for CORS, and other hoops. Another advantage is that you're experiencing the app with SSL, so you may notice bugs that you would miss if you're used to work with HTTP locally. I've had these bugs which "only happen on production" in the past, and it's a nasty thing to deal with because it will be in a rush, since it happens as a surprise, and impacts users immediately. It can also bypass QA if the QA environment is also using workarounds and not a prod-like setup with SSL and the likes.

I recommend giving it a try. It's a workflow I haven't seen promoted anywhere before.

Re: How to win at CORS

#77

Post by jaffathecake »

chrismorgan wrote: post #69
jaffathecake wrote: post #64

Bonus fact: I wanted the 'app' ( https://jakearchibald.com/2021/cors/playground/ ) to allow the HTTP method to be set to anything, which meant I needed a server that could accept anything. I usually use NodeJS, but it turns out the HTTP library they use turns the HTTP method into an enum, so only a subset is supported ( https://github.com/nodejs/node/blob/d798de1c653efa5ec0015d44... ). This restriction only exists in…

My recollection from circa 2013 is that Node.js at least used to use the nginx HTTP parser, which was a horror of manually-implemented state machine written so in the name of performance, but consequently basically unmaintainable and fairly bug-riddled. And not as fast as it should have been, anyway. (The state machine approach is fine, but it should have used a lot more code generation.) It read the method byte by b…

Whoa, I didn't know that! But yeah, it seems like https://github.com/nodejs/http-parser is based on nginx. It now uses https://github.com/nodejs/llhttp but has some of the same legacy.

On the other hand, deno's HTTP stuff is built on top of Hyper, a Rust library https://github.com/hyperium/hyper

Re: How to win at CORS

#78

Post by lucideer »

lloydatkinson wrote: post #56

CORS is a stupid idea that serves no purpose. If someone is really determined they will either 1) turn off CORS with a browser extension 2) simply call your precious API from something other than an a browser It is essentially security by obscurity and protects nothing. Don't get me started how some technologies like AWS Lambda with a Gateway, when a function has an error, responds by default in such a way it makes t…

Being an engineer who doesn't understand CORS is ok; I've worked with a few good ones who struggled with it, so clearly CORS is not a very intuitive tech.

Not understanding CORS and making a comment like this is taking that ignorance to a new level though. Please read up on what you're talking about.

Re: How to win at CORS

#79

Post by speleding »

Benjamin_Dobell wrote: post #41
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…

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.

That works, but I found a simpler / cheaper alternative to fix this particular Cloudfront problem: Create a custom "Cache policy" that only includes the header "origin" and then the answer from Cloudfront will always include "Vary: origin", even if it wasn't in the request (That behaviour is not documented anywhere I could find, stumbled upon it by accident)

Re: How to win at CORS

#80

Post by raihansaputra »

lwouis wrote: post #76

When developing a webapp these days, I use a local proxy. This allows me to type a staging/production URL into Chrome, and get the frontend and the backend from either my local machine or staging/prod. I can mix and match any combination by checking/unchecking a box in Proxyman. This means there is no need to whitelist localhost for CORS, and other hoops. Another advantage is that you're experiencing the app with SSL…

Thanks for the tip for Proxyman!
Post reply on HN