CORS was not a mistake. It was created to drive frontend engineers to insanity, and it accomplishes that to perfection.

@RaZziaN1

5 ай бұрын

no need to drive them, frontend devs will do it by themselves

@btonez13

5 ай бұрын

see also: OAuth 2

@1Caja

5 ай бұрын

​@@btonez13OAuth2 is great wdym? It's also easy to implement yourself either from documentations (Microsoft has some good ones) or from the RFC

@blatisgense933

5 ай бұрын

Omg literally me

@glaxmattbas

5 ай бұрын

I believe all front-end tech has that goal

It's more of a NextJS app router issue that you do no have a way to set common headers on the same URL for different http method. Most web-frameworks have CORS in mind and can let you easily setup CORS in some kind of middleware.

@samuellaycock4250

5 ай бұрын

Yeah. CORS is definitely a flawed spec, no doubt about it, but the “obnoxious” bit here is a Next thing

@MrRaitiz

5 ай бұрын

Most definitely, it just shows how immature these JS frameworks for backend are. I mean its not end of the world as CORS is not THAT complicated. Also the preflight (OPTIONS http verb call) is meant for browsers to check the response headers so that the actual request can/cannot be sent, if can be sent then after the actual request browser checks that request response headers for the actual response.

@manikandanbalakrishnan7701

5 ай бұрын

Oh yes these Js framework's are really immature, I did try to implement API using nextjs lots of issues like this. Java , phyton or c# is better for API development. I switched to remix for frontend from nextjs.... Much more flexible and uses unwrapped native node JS request and response.....

@monishbiswas1966

5 ай бұрын

@@MrRaitiz indeed, he key point about OPTIONS is that it guards against any side effects of the request, effectively to guard against a CSRF attack. Servers could guard against this by checking the CORS headers before carrying out the request, but it looks like the CORS spec takes a precautionary approach and assumes the server does not do this, The weird thing is the websocket spec takes the opposite approach and relies on the web sockets server to validate the Origin header within the app logic. I wonder how many webscketa servers do not check the Origin.

@asdf9833

5 ай бұрын

I agree, this is a framework problem. On top of that, with server actions nextjs implemented an origin header check on the server. This is obnoxious part, instead of providing a good DX on top of a browser enforced CORS, they implement something else, that is much less flexible, adding another set of error messages to the pile. Have fun implementing a multi tenant app where users suppose to point their custom domain to your app. You’ll need to know all allowed hosts at build time AND still have to deal with CORS to prevent cross scripting issues between your tenants …

I hate that this video gives the impression that the problem is CORS, but in fact, the real problem is with Next.js.

@vaap

5 ай бұрын

yea this video missed the mark soo bad, it comes off like Theo doesn't really understand what CORS solves.

@JEsterCW

4 ай бұрын

As always, i found out that vercel with next only makes problems 😂

I could say that the web is CORSed

@rubendacostaesilva8442

5 ай бұрын

Get out!!!

@elmalleable

5 ай бұрын

​@@rubendacostaesilva8442😂😂😂😂

@w1atrak1ng

5 ай бұрын

Banger

@alchemistmd2422

5 ай бұрын

Bruh

@ninetysixvoid

5 ай бұрын

FR1!1!

Most backend frameworks, like laravel or aspnet.core, deal with CORS gracefully. This is more of an issue with nextjs than any other thing.

@GamePlayByFaks

5 ай бұрын

that won't solve node.js cor's issues :D

@fnfal113

5 ай бұрын

@@GamePlayByFaks fun fact cors package is configurable on nodejs

@GamePlayByFaks

5 ай бұрын

@@fnfal113 let's be real not everybody add's packages to handle cor's that's just reality of it, since dependency hell on nodejs all ready is a thing... Note: Also don't forget not everybody use latest and greatest stuff around, like we have spa vue.js v1.x with node.js that is a bit outdated, so each time is a gamble.

@proosee

5 ай бұрын

Thank you, exactly what I wanted to say. Nodejs logic: "we can't write proper code to handle a web standard or copy solution from other technologies" = "web standard is stupid". Guys, just look how it is done in other frameworks, why do JS devs need to invent everything again from scratch?

@shacharronzohar6960

5 ай бұрын

@proosee ​because node isn't a framework, it's an engine to run JS outside of the browser.

I just want to point out, when watching your video in slow motion, at 5:52 when you close the image it is possible to read your X-Uploadthing-Api-Key. Thought you might want to fix that and reupload (or change the key).

@t3dotgg

5 ай бұрын

Ty for heads up, thankfully that key hasn't been valid for over 2 months lol

@ninjaasmoke

5 ай бұрын

why were you watching it in slow motion? 😂

@espendennis

5 ай бұрын

@@ninjaasmoke People who are into security look very closely whenever somebody streams code. That black box redacting something which than moves behind that block is just asking to be checked out frame by frame 😂

@wil-fri

5 ай бұрын

@@ninjaasmoke there have been cases of filtering of... fingerprints or other codes. Wikipedia was requested to remove the FBI badge at wikimedia

Problem is that web devs should learn fundamentals, and why we have CORS, and how to address these issues in non security threatening way. Most of devs solve it by allowing all origins, which intoduces many security risks.

@31redorange08

5 ай бұрын

The Twitter replies shown in this video are enough to conclude that people have no idea what they are doing.

@nikolaberovic2044

5 ай бұрын

@@31redorange08 what is worse is that many devs working in big companies do not know either. Since web dev became an industry, real knowledge has declined.

@phillipgilligan8168

5 ай бұрын

Agreed allowing all in prod is NOT a solution.

@vintagewander

5 ай бұрын

the entire video itself is just web dev skill issues

@mwcavanagh

5 ай бұрын

Productive devs vs senior devs problem right there. @@phillipgilligan8168

This is why cors in laravel is global or per route or both. It's awesome. Makes cors easy

@GamePlayByFaks

5 ай бұрын

Laravel has built in package to handle that but if you have outer api for spa or whatever then that solves only one way not the other from node.js

@SanderCokart

5 ай бұрын

@@GamePlayByFaks i meant cors.php in config folder

@GamePlayByFaks

5 ай бұрын

@@SanderCokart okay.

I disagree wholeheartedly with this. CORS is not flawed, next.js is flawed. The only time I've ever been caught out by CORS is when I forgot to configure CORS middleware. One commit later and there are no more issues. Use proper tooling for APIs and you won't run into half these issues.

@user72974

5 ай бұрын

Agree. CORS is basically a way for you to opt into which domains are allowed to interact with your server. How is that a bad thing? Complaining about CORS existing is like complaining about passwords existing. Would you be angry that passwords exist to allow you to opt in to who is able to access your accounts (if you even choose to allow this)? I doubt it. And from the other perspective, for those front end apps running in the browser on various domains out there, it was a backwards compatible way to make sure sensitive data wasn't being transmitted to 3rd party domains. Security by default is a good thing. The fact they added cross-domain AJAX support in a backwards compatible way like this is impressive. I do realize it can feel complex to people who've never worked with it before. And that complexity can be magnified when you're working with a 3rd party thing (like this video creator is) who is also doing something complex, like running things meant to be run on servers in the browser. Now you're at the mercy of how that 3rd party works. But you've always got the freedom to choose to simply not use that service. Anyone new to CORS who is frustrated with it should use the same solution they've probably found successful so far when dealing with new things. If it's too complex, provide feedback to its creators so they can simplify it (CORS probably cannot be simplified any further) and then try as hard as you can to learn it. MDN has great resources for learning how CORS works. One more tip I'll leave for people... embrace proxying if you need it. It's not the evil, dirty workaround it might seem to be. Browsers have no way to know that two domains are owned by the same party, so they have no way to trust a different domain when a request is being made to it. If you proxy the requests you want your app to make, hosting the proxy on your domain, the browser doesn't have to worry about this. You're vouching for that service to the browser. It simply makes another call to your domain, like it's doing for every other call to your backend. This doesn't even have to be a separate application. It can just be another route in your back end application if you want.

CORS is handled by the browser, the client needs the OPTIONS request to know whether or not the POST request is allowed, you're inflicting this pain upon yourself by hardcoding cors rules in javascript on different method calls, cors is supposed to be handled by the web server itself

@frydegz

5 ай бұрын

web people don’t actually understand how the web works

@Mooooov0815

5 ай бұрын

Except for that not every request does need an option preflight request. As long as your request qualifies as a „simple request“ (specific content types and no non standard headers, etc) your browser will not issue a preflight request, but the response still needs the proper cord headers present

@jimbolino

5 ай бұрын

@@Mooooov0815 the "simple" requests are there for backwards compatibility reasons. GET calls with no additional headers (same as embedding an IMG tag in your document) or POST requests that do a simple application/x-www-form-urlencoded plain old form stuff.

@itsfolf

5 ай бұрын

@@Mooooov0815 If the request does not cause a modification on the server (i.e. GET), then it does not need a preflight, because you can simply filter when the response comes. But for a request that causes a modification on the server (i.e. POST), filtering on the response would be too late, so you need to check first.

Dam there are like 3 rules to support CORS its really not that hard. Second thing dont support CORS in your app, but in your infrastructure

@renatolovato

5 ай бұрын

Yes, you're absolutely correct. Unless the application needs to dynamically set the allowed source based, for example, on the user authenticated, you should deal with CORDS on Nginx, Apache, etc.

This video would've been better by mentioning *why* the OPTIONS request exists and why websockets don't use CORS. If the OPTIONS pre-flight request wasn't there then the browser would still have to execute the request against the actual endpoint, and the endpoint would still do 'the thing it is supposed to do' (e.g. delete all your files). The OPTIONS call is an 'innocent' call that has 'no' risk of having any side effects. Whether the required confirmation on the actual resource is or isn't beneficial enough in the grand scheme of things I agree can be debated, but frankly in no project I ever did different resources have different CORS responses, so I always just threw it in as some type of quick middleware on all routes which took me all of 5 minutes. Obviously the more complex your architecture is, the less true the 5 minute statement becomes (e.g. in one architecture setup I 'helped out with' (just giving advice) they had to dynamically sent the list of allowed servers to the API server which then had to add them to the CORS list, but that was a pretty crazy setup). As to why websockets don't require CORS: The argument goes that if the web was invented today we wouldn't have CORS nor the same origin policy and instead checking the Origin header would simply be left to the server. As websockets were invented 'late enough' in the web's development the argument goes that there is no risk of legacy servers to be concerned with, so leaving the check to webservers directly is simply more efficient.

@RaZziaN1

5 ай бұрын

" instead checking the Origin header would simply be left to the server." - im pretty sure that's how it is anyway.

@DavidMulderOne

5 ай бұрын

@@RaZziaN1 The point is that for normal HTTP calls that's *not* the case right now, just for websockets as those are new.

@monishbiswas1966

5 ай бұрын

⁠@@RaZziaN1 not quite - most properly written websites would have CSRF protection jest originated from the same request, but as the Origin header is recent and not sent on all requests it would probably not be checked at all

@TheNewton

5 ай бұрын

...because backwards compatibility minutiae is piling up saddling modern web development with past bad decisions.

@pawelparadysz

5 ай бұрын

@@DavidMulderOne but I can just extract the origin, validate it, and set the cors to allow it? or am i missing something?

This is pain. But you know what's even more painful? The fact that you don't have canary deployments for stuff that you know might fail due to a developer's mistake

I think devs who hate CORS are devs who still didn't fully understand what CORS are for and how they work. I mean, what is there to hate, once you get them ? Security ? Isn't it a GOOD thing ?

@Rust_Rust_Rust

5 ай бұрын

You can hate something that is difficult to work with even if that added difficulty is a net good.

@renatolovato

5 ай бұрын

wow did you say it? I agree! Also, you should never set Access-Control-Allow-Origin = *, unless your API is meant to accept requests from unknown sources.

@Hexalyse

5 ай бұрын

@@Rust_Rust_Rust Ok, I can agree. But CORS couldn't be more simpler. I'd even argue its failure is to be too simple : for example being able to only declare one domain as an allowed origin. They could have allowed you to just send back a coma separated list. But I don't see how CORS is "difficult to work with". It's a bunch of headers that tells a browser what methods it can use and from what domain, for a certain URL. Nothing more.

@TheNewton

5 ай бұрын

@@Hexalyse lol lol arguing it's too simple while pointing out a main cause of why it's not simple. LOL 🤡🤸

@codewithwings

5 ай бұрын

@@TheNewtonI'd like to see him hook up a front end to an API he hasn't worked with before on a live stream. If you think CORS couldn't be "more simpler", either you're amazing, or don't code very much.

I'm currently building my first real full stack app and I'm currently facing exactly this problem lol, thank you Theo for hearing out my soul always

This video convinced me CORS should stay the same. They guard you from this messy approach

Before CORS it was common to see the session or CSRF token in the URL for pages with potentially sensitive content that was server-rendered. It was a much bigger pain both as a developer and a user (couldn't just copy URL to send to a friend or colleague since it was unique to your session and sometimes to that specific page-access). Perhaps there's a 3rd option that would be better, but comparing to the way websockets did it for example: I think it's simpler for web servers to set one (sometimes you need the others, but in my experience it's rare) headers on the endpoints, where cross-origin is OK, than to check the origin header on every endpoint that may have sensitive data. The header can be set by the edge server, whereas the origin checks usually have to live in the application code.

I work on a legacy system, and someone was trying to add a more modern API (the new code is somehow worse than the old, but that is a tale for another day) on a separate domain, and strugled for days with CORS, I was like "come on, we are behind a reverse proxy, just put the API on the same domain with a url prefix" and everybody was happy ever after... except when someone needs to touch the new code

I love watching real world debugging. I think getting a peek into the mindset of somewhen when fighting issues is so important. So much of this work is about solving the right problem and checking the right things and not digging yourself deeper. Its also an extremely personal process. Thanks as always for sharing.

I can't understand where the issue is here? CORS is well dcoumented and super important. The preflight request happens because of the way http works, which means the browser doesn't want to send the actual request before asking the server, hey is this okay. And then it makes total sense it RE-verifies it on the actual request. This makes sure a clien't cant request a server if the server is limited to a specific origin. Regarding the sockets thing, http works over tcp sockets? So cors is only concerned with the content of the http request and doesnt care about anything below it. Further the argument: i had to write the headers twice, have people forgot something called middleware exists? I can understand it can be frustrating, but it seams this is more because the concept of cors wasn't understood rather then cors actually being wrong.

@monishbiswas1966

5 ай бұрын

I think when he said sockets he meant websockets, which does not need CORS to go cross domain - instead the server is supposed to validate the Origin header. The reason CORS has a preflight request is because some web endpoints may predate CORS and not know to check the Origin header, and would be vulnerable.

There are two kinds of webdevs, those who hate CORS and those who can read a full MDN page to understand something.

Honestly stuff like this is where having an API gateway and a proper deployment process where you can set rules like CORS and authentication as part of your infrastructure code instead of putting it in your javascript like you were doing in this video.

Consider writing a server that, after recieving a request, queries a database and then serves html

@pairofrooks

5 ай бұрын

😂😂omfg

In my recent battle with CORS, I just slapped some "no cors" in there and called it a day

CORS or and TLS specific code shouldn't be written in node. That is the only problem here.

I still will not forget the time i was learning laravel in my internship. For some reason, failed user validation in the backend would result in a CORS error. I had to figure out everything on my own. A fucking hellhole that was.

@jimbolino

5 ай бұрын

error pages usually dont emit the correct cors headers

its improperly named, it should be called CORB: Cross-Origin Resource Blocking because thats all it seems able to do

@31redorange08

5 ай бұрын

No, you apparently don't understand CORS.

I made a cross origin POST request to my own custom HTTP server. I got the request and parsed it correctly, but the browser refused to hand over the response because of CORS. What does that help? I have already processed the request on the server and sent a response knowing the source of the request. I know I can add some headers to allow access to the browser, but why? The server has decided to not reject the request, shouldn't that be enough?

I always hated CORS, it seems like reinventing cookies would be a smarter move… Anyway, thanks for the video! Letting you know that the screen is flickering on darker tones like in 4:50. I thought there was a problem with my tv hahah

@RaZziaN1

5 ай бұрын

no issue with flickering for me

@rflsms

5 ай бұрын

​@@RaZziaN1its very subtle, I can see it in my tv and phone very well, but it is harder to spot on my monitor (I can still see it though, but it is definitely not as annoying as on my tv, probably due to local dimming)

Let's talk solutions. When you're stuck on a CORS issue and need a quick fix, there are tools out there to help. Beeceptor, for example, is a lifesaver. It's this cool HTTP proxy that handles CORS smoothly, adding required headers to the original API response. Frontend/Javascript devs looking to get past those annoying CORS blockers, a time saver!"

@himanshuvora1980

5 ай бұрын

Let us connet, I would like to test my online voting solution API .

They don't want some website making requests to another website because cookies are sent by default, so by default, those requests could be authenticated. The solution was to list all websites that are allowed to make such requests. In my opinion, an easier solution would be to just not send the cookies in those cases instead of blocking the request. Sometimes you just want to make an unauthenticated request to a different domain and with the protocol we have now, you need to proxy the request to work around CORS. If you are just writing some html to run from the file system. You also don't get to do requests so you always have to spin a small web server. But it is too late to change how this works now. Maybe in the future with new protocols we won't have this problem anymore. I'd rather start from scratch than patch this in a way that won't break older pages.

@monishbiswas1966

5 ай бұрын

The issue with this approach is that if the victim is on an internal network it would allow access to internal services through a malicious websites. The localhost restriction is probably there for a good security reason as well

Partytown with GTM has this issue. I don't control GTM backend so how to solve it even 😂?

Skill issue

@matthewvanderwesthuizen162

5 ай бұрын

I was just about to say. This is no more than a skill issue. Dont't be hating on stuff that increases security and safety on the net.

@31redorange08

5 ай бұрын

The only reasonable comment here.

yea that "prefab" OPTION calls took us few hours too :D, and fixed only because we tried normal ajax and not fetch where you see "prefab" request in network ...

At 5:36 you leak a few character from the key, definitely not enough to access something but maybe still a good reason to recreate it

I've literally never had an issue with CORS. I actually love that cors exists so I can deny malicious attackers. :D CSRF was so much pain to integrate and handle than cors, which I still have to do sometimes and make things work.

CORS is complicated & confusing, BUT PRETTY MUCH ESSENTIAL to prevent malicious websites doing bad things! I'm convinced that it needs to be what it is and work pretty much how it does. Use a good library (such as django-cors-headers) and just enable what needs to be allowed. I think what is confusing about CORS is it the browser restricting what the client can do, whereas normally it's the server restricting what the client can do.

My service just returns the exact same cors headers on every single request. Does Next not have a middleware setup like Express?

Is Theo saying that Chrome Extensions have the ability to bypass CORS? How? I feel like I've run into CORS errors plenty of times and had to resort to proxying even with extensions? Maybe its because I didn't do the pre flight first or are you supposed to do some trickery and make the calls from injected scripts?

@randomgeocacher

5 ай бұрын

StackOverflow says you add it to the permissions part of your chrome extension manifest. Hopefully this is still a correct answer, it’s 11 years old :) See “CORS Chrome Extension with manifest version 2 Is it possible to use CORS when writing a google chrome extension?”

Cors is pretty straightforward, clear lack of skill by junior devs, been there

"I FIXED IT" "I did not fix it." Yeah, sounds like cors.

If you don't use cookies Leave cors open

Currently smashing my head into my keyboard because of CORS, surprised the keys still work well enough for me to type this.

It’s more about lot of the framework don’t have custom cors setting by deployment profile by default or it’s not flexible enough it’s so rigid nothing can be customized. It’s make developer need to setup cors header and OPTION manually in hacky way like demonstrated on this video. The easiest way to solve it in production is by using proxy server or api gateway to make all the cors setup centralized on one place.

So let's fix it. How would we start doing that?

I’d love to hear about conceptual alternatives

@npc-drew

5 ай бұрын

At the time, I thought since running Node JS could circumvent CORS, I found StackBlitz, to run WebContainers with NodeJS, maybe this could get away too, but this always stayed a theory.

@DarrenJohn10X

5 ай бұрын

MeToo

@jimbolino

5 ай бұрын

csrf token that rotates after every request

damm, i was dying fixing cors errors for 2 hours just 30 min ago

@renodremson1189

5 ай бұрын

How did you fix it?

Couldn't you write a rule implemented as a function or class that encapsulates all of this in one place?

Can we get a vid about prisma accelerate? Its amazing

I gave up trying to get CORS working while having my entire app in docker containers in development.

I thought the OPTIONS call was the only one that needs the CORS headers as it's the pre-flight request. Then all subsequent requests that were allowed can just be made without any CORS headers at all. Guess not?

@amcsi

5 ай бұрын

No, you always needed the subsequent requests to also respond with the appropriate CORS headers, otherwise the browser would not allow you to access the response.

@jonkoops

5 ай бұрын

Wow, that seems a bit excessive, I wonder why that was designed in such a manner.

I would just whitelist origins that needs resource access includes localhost dev environments and everything's fine, I had issues back then ngl It turned out I had to configure cors on my nodejs app.

I remember the OPTIONS headache - and different implementations in different browsers.

I work at a billion+ dollar company and we had some CORS related problems last week. It wasnt that CORS was blocking anything its just that our logs in datadog went from a few hundred thousand to over 2million overnight when we launched a new product because the new product had a new service that talked with our core service and every request was hitting a CORS check. So I figured out we should just set Max-Age on the requests so CORS can effectively f-off for at least for some time. And then I learned that the max-age DIFFERS FROM BROWSER TO BROWSER. I hate CORS.

@DimkaTsv

5 ай бұрын

Does it differ in between different versions of same browser though? Just wondering, because knowing world of developers it could very well be so.

I feel like I've just been to a successful support group meeting :)

Not sure if you noticed but your (duplicated) cors headers code is out of sync ;) in options your settings are different than in post ;) Just like you said in the video (different methods listed ;) )

from time to time i get asked to integrate apps never designed for sso into enterprise sso infrastructure. trivial without asking the app devs to make major changes to their code using loadbalancers and oauth.... unless the app uses cors... then its best to forget the need for the app and the app. its just a pain and a curse

Only calling it Cross Origin Request Stuff from now on

To make it more fun, it's ultimately just a client side measure that can be disabled by a user (browser).

@RemcoPeggeman

5 ай бұрын

Its there to protect that user, not other users, so if a user jumps through the hoops (its surprisingly hard to do this on Chrome without an extension) then they’re at most screwing thenselves.

actually the biggest problem with cors in my opinion is that i've read countless explanations and still not sure why the fuck do we need this in the first place

It was definitely written by those esoteric programmers who are like 'read the manual' instead of making it good. I wonder how many millions of dollars they have cost in lost time. Almost as bad as certificates, just recently the windows 22H2 update made some sites use TLS1.3 ... which broke. good times.

Listening is already so complicated, could you imagine dealing with these?

It's frustrating when I am a junior developer who is trying to learn fullstack and suddenly you get CORS-policy violation. You have no clue what it means, what causes it and how to fix it. All you know is suddenly your app isn't working anymore. Good luck!

LOL I ran into the OPTIONS issue when trying to make an OpenAI Compatible Endpoint... the things you learn trying to make a server...

Great video, more of this!

The funny part of this is you can just put the API calls behind a server and bypass CORS all together. In other words, the only nefarious actors thwarted by CORS are the lazy ones who want to just use a cross origin resource by copy/pasting a URL into their source.

CORS: an ordeal every time

My most popular stackoverflow question and answer are about CORS

I actually had a cors issue today. Found an easy fix though, thankfully.

I feel like this is a CORS + BROWSER issue

BFF is your best f****** friend. Pre-flights add significant extra latency, particularly if paying the Cloud Flare latency tax, and it's particularly bad for some users; like international. Serve your FE from the same origin as your API.

senior engineer and don't know how to deal with CORS?

It gets even worse when the headers get cached during development. Oh boy does it get worse…

The reason why cors is not enforced on websockets is because websockets requests results in a 101 and have no body. CORS is not an attempt to protect the origin site but the foreign resource itself, like images and what not. This enable backends to protect against malicious websites running on genuine user browser. Its pain because the server software you use is bad, but hating on cors is like hating on tls.

I never had those kinds of issues with CORS. It always worked with me. When the headers are not there, I just add them to the middleware the way I want. Then it just works 🤷. I don't get how do you get so many issues. Maybe it's a javascript thing? I've made servers in php, Java, python, C, and Go. I haven't in javascript yet.

isnt this a reupload? or am i not remember right

That CORS frustration you got there is pretty cool. It would be a shame if someone MADE A SERVER-SIDE PARTNER TO IT CALLED XSRF-CSRF 🤬🤬🤬🤬

Why do you include Access-Control-Request-Method in the server code? That's just a header sent by the client during the OPTIONS pre-flight. I would remove that in cases it causes problems with some clients. Some clients are really picky about stuff (like Access-Control-Allow-Methods did not allow wildcards in the past). There's a lot of subtleties as you get into edge cases with credentials and allowed request headers. Even re-reading through my implementation for work just now, I realized my own implementation is not quite correct because for my OPTIONS response, I send back the origin requested in "Access-Control-Allow-Origin", but because I do that, I should add a "Vary" header specifying that so that any intervening proxies do not cache the "Access-Control-Allow-Origin" response just for that particular asked for origin.

CORS is a true nightmare, lol! A labyrinth within a maze!

argh, I feel this pain, I wouldn't piss on cors' burning body...it's always a pain in the neck

I hate to take this stance, and sound like Prime, but this seems like a skills issue. Setting up an endpoint to respond with the same CORS headers for OPTIONS or POST/GET without copy-pasting the code isn't hard. I understand that backend code running in the browser needs work to adhere to CORS, and I totally get how "wait my requests are running in the browser now" wouldn't necessarily occur to a dev immediately. But I feel like if you sit down and understand CORS these things become apparent and reasonable pretty quickly. The OPTIONS preflight is an effort to avoid server-side actions that the client can't read the result of. But the CORS checks still need to pass on the actual request for the browser JS to get access to the response (but you'll see the request did actually happen if you look at the server).

"WE SHOULD NOT BE HERE, CATCH YOUR FAILURES EARLIER" xddd

My favourite „solution“ for Development landed in Chrome a couple of months ago. Overwriting response headers like setting Access-Control-Allow-Origin to * kzread.info/dash/bejne/l2yozsGyoJiogco.html

@nikolaberovic2044

5 ай бұрын

So many answers on stack overflow do the same... Which is a pity.. always try to understand why things happen

Honestly, I'd rather deal with CORS, than trying to wrestle wth nx, typescript, babel and webpack.

I as a user should be able to disable cors as easily as i can disable "Enhanced tracking protection" Not being a "webdev" my foray into dealing with js and cors has been complete hell (mainly getting data from apis i do not own like weather data that don't provide a way to deal with cors) The only good thing cors has done is to push me to just do all of that garbage on a local server and simply serve the data that way instead of having the "application" run within the browser

You also "have do deal with" seatbelts if you drive anywhere :)

Man, you gotta take a break when you're stuck on a bug that long. It's always easier to fix with a clear head the next day.

In my 20 years of coding, for the backend, I have used Sping (JAVA), Laravel (PHP), Symfony (PHP), .NET, Django (Python), Flask (Python), Gin (Go). CORS has never been an issue and I have dealt with it more times than I can count. CORS was well designed and thought out and all the frameworks I have mentioned deal with it nicely. This video is nothing but a NEXTJS problem!! And the bigger picture is that javascript should have stayed in the browser!

Cors are easy, I have been able to learn about them perfectly after dealing with errors related to them for few days, after that it's easy.

You shouldn't write cors in your request handler. Cors should probably be in a filter somewhere

I suggest we call it kors as in causing korsakov

As an API developer never had to actually deal with CORS, mostly because framework handled it for me. All I had to do is to setup one middleware, and that's all.

CORS is a pretty good standard, I don't think it's a problem because of CORS, it's more about how the browser implements it and also does it allow you to pass your own preflight info or an API call. One of reasons why I don't like front-end development because it's mostly your browser and also some browsers gives stuff like blocking these kind of cases. If you deal with them you will hate CORS more than anything. Sometimes same happens with cookies too.

CORS is painful but a necessary evil. Otherwise the browser would trust the current page to connect to any server. Better to have an opt-in system like CORS, or better yet, serve everything from the same origin (same domain). HTTP proxying makes sense for most projects, and makes sense for StackBlitz.

I wonder how many people run their own little nodejs request relay to solve this.

CORS should be a turn on feature rather than a turn off feature

It's definitely a CORS for concern

CORS is way better than the hacks we used to have to do (like JSONP). The issue is your framework.

This seems like a Next issue and not really a CORS issue.. I do not have any problems dealing with it in python, java or rust backends ive tried

Yeah then you get the DB person for some reason assigned to create your API endpoint, saying it works in postman so it must be my front end problem... 😶😶