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

121–128 of 128 posts

Re: How to win at CORS

#121

Post by jaffathecake »

Steltek wrote: post #115
jaffathecake wrote: post #94

Earlier quoted context omitted.

The article mentions the SameSite stuff early on, then kinda mentions it in passing when it comes to CORS + credentials "The same-site rules around cookies still apply, as do the kinds of isolation we see in Firefox and Safari. But these only come into effect cross-site, not cross-origin". Seems like I need to word it better though.

Is it fair to say that the strongest CORS request allows the weakest? That is, if your server supports a preflighted, credentialed, cached CORS request with weird headers and methods, then it would support just about anything? Perhaps a detailed walkthrough of that one specific scenario, which would enable almost all others, would be helpful.

Yeah, the most permissive CORS allows everything, although it's kinda risky to do if you don't understand the consequences.

Re: How to win at CORS

#122

Post by ourcat »

jaffathecake wrote: post #120
ourcat wrote: post #119

Earlier quoted context omitted.

Hi Jake! (I watch your videos ;)) Many times, the (Angular) ServiceWorker has given us CORS headaches on various requests to our APIs and AWS storage files. The only method we've found, after various AWS configs and ngsw-config.json attempts, was to add `ngsw-bypass=true` to all requests. I'll see if I can find the Github issue, where this has come up before. Incidentally, while you're here, I'm planning on building…

COOP+COEP won't change how CORS works, but it means you can't have no-cors resources on your page unless they have CORP headers

Very useful info. Thanks!

Re: How to win at CORS

#123

Post by floppydiskette »

jaffathecake wrote: post #26
chrismorgan wrote: post #19

Earlier quoted context omitted.

Well, for my own personal stuff I omit just about all that I can—head/body start and end tags, html end tag (not start tag because it has at least a lang attribute), tbody start tag where possible, thead/tbody/tfoot/tr/th/td/li/dt/dd/p end tags almost all of the time, attribute value quotes where valid… mostly just because it’s fun doing so, and in some cases because it makes things decidedly cleaner (especially tabl…

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.

This is the way! I used to get annoyed by unnecessary trailing slashes, but it’s really a non-issue. Not to mention it’s required in JSX anyway.

Re: How to win at CORS

#124

Post by ufmace »

Steltek wrote: post #115
jaffathecake wrote: post #94

Earlier quoted context omitted.

The article mentions the SameSite stuff early on, then kinda mentions it in passing when it comes to CORS + credentials "The same-site rules around cookies still apply, as do the kinds of isolation we see in Firefox and Safari. But these only come into effect cross-site, not cross-origin". Seems like I need to word it better though.

Is it fair to say that the strongest CORS request allows the weakest? That is, if your server supports a preflighted, credentialed, cached CORS request with weird headers and methods, then it would support just about anything? Perhaps a detailed walkthrough of that one specific scenario, which would enable almost all others, would be helpful.

I don't think that's very accurate generally - the CORS Access-Control headers are pretty flexible, and can be locked down to only allow the specific weird thing you want to do. The part where that is kind of true is setting cookies with SameSite=None - it's needed for the CORS credentials to work, but it might cause security issues with other uses of your website.

Re: How to win at CORS

#125

Post by derekzhouzhen »

The problem with CORS is that most people do not understand it and will not bother the change anything to make life easier for other developers. At least, static files open to the public shall have 'Access-Control-Allow-Origin' set to '*' by default. Vercel and github page do that already which is nice. Most other web host don't, Not even Netlify, who supposedly advocates for the JAMStack.

For dynamically generated content, the site runner should also consider open up if the content is for public consumption and not varying by user's credential.

Re: How to win at CORS

#126

Post by skoskie »

Dude, writing out the background and history of everything must have taken quite some time, but I found it very valuable in helping to understand the present state of things. I just want to say thank you.

Re: How to win at CORS

#128

Post by nhumrich »

blacktriangle wrote: post #86
fraktl wrote: post #63

Earlier quoted context omitted.

This. But hey, with so many impostors around - they're not capable of fathoming how golden this advice is. Sad truth is, since "developers" don't use this, they genuinely don't understand browsers and HTTP and that's what 's dangerous.

This is just not an option for so many very legitimate use cases. Building client-side apps that aggregate and display information from multiple web services hosting on domains totally outside of my control is valuable.

Yes, but in those cases, you aren't the one worrying about cors. The services you use are.
Post reply on HN