Y'all are so pessimistic. React Server Components are great. React is a complex piece of software. Bugs happen.
Denial of service and source code exposure in React Server Components
101–110 of 232 posts
Re: Denial of service and source code exposure in React Server Components
#102I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
> And we're all just supposed to act like this isn't absolutely insane.
This is insane to you only if you didn't experience the emergence of this technique 20-25 years ago. Almost all server-side templates were already partials of some sort in almost all the server-side environments, so why not just send the filled in partial?
Business logic belongs on the server, not the client. Never the client. The instant you start having to make the client smart enough to think about business logic, you are doomed.
Re: Denial of service and source code exposure in React Server Components
#103Y'all are so pessimistic. React Server Components are great. React is a complex piece of software. Bugs happen.
Personally I prefer simple software without bugs! This security vulnerability highlights a serious issue with React. It’s a SPA framework, a server side framework, and a functional component library all at the same time. And it’s apparently getting so complex that it’s introducing source code exposures.
I’m not interested in flame wars per se, but I can tell you there are better alternatives, and that the closer you stay towards targeting the browser itself the better, because browser APIs are at least an order of magnitude more secure and performant than equivalent JS operations.
Re: Denial of service and source code exposure in React Server Components
#104Earlier quoted context omitted.
> This isn't a Javascript problem, this is a React problem. It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106 > Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript. Yes. And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and fronten…
> It happened with Next.js as well It's the same vulnerabilities because Next uses the vulnerable parts of React. Your rational is quite poor as I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? Look, many of us also strongly dislike JavaScript but generally that distaste is based on its actual shortcomings and failures, you don't have to invent new ones plenty already exis…
> I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then?
If you have a single codebase for Go-based code running in an untrusted browser (the "toilet") and a trusted backend (the "kitchen"), then the same contamination is highly likely.
Re: Denial of service and source code exposure in React Server Components
#105I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
It's kinda nice.
Main downside is the hot reload is not nearly as nice as TS.
But the coding experience with a C# BE/stack is really nice for admin/internal tools.
Re: Denial of service and source code exposure in React Server Components
#106Earlier quoted context omitted.
Very standard in security, announcements always always always try to downplay their severity.
fwiw, the goal here wasn't to downplay the severity, but to explain the context to an audience who might not be familiar with CVEs and what's considered normal. I moved the note down so the more important information like severity, impacted versions, and upgrade instructions are first.
> an audience who might not be familiar with CVEs
If there are so many React developers out there using server side components while not familiar with the concept of CVEs, we’re in very serious trouble.
Re: Denial of service and source code exposure in React Server Components
#107The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like cooking food in your toilet, sooner or later, contamination is guaranteed" [1] 1 - https://ashishb.net/tech/javascript/
You can still have separate codebases for server and client in JS/TS...
Re: Denial of service and source code exposure in React Server Components
#108Earlier quoted context omitted.
I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear a…
I've been using React since its initial release; I think both RSC and App Router are great, and things are better than ever. It's the first stack that allows me to avoid REST or GraphQL endpoints by default, which was the main source of frontend overhead before RSC. Previously I had to make choices on how to organize API, which GraphQL client to choose (and none of them are perfect), how to optimize routes and waterf…
Can you describe how rsc allows you to avoid rest endpoints? Are you just putting your rsc server directly on top of your database?
Re: Denial of service and source code exposure in React Server Components
#109When I looked into RSC last week, I was struck by how complex it was, and how little documentation there seems to be on it.
In fairness react present it as an "experimental" library, although that didn't stop nextjs from widely deploying it.
I suspect there will be many more security issues found in it over the next few weeks.
Nextjs ups the complexity orders of magnitude, I couldn't even figure out how to set any breakpoints on the RSC code within next.
Next vendors most of their dependencies, and they have an enormously complex build system.
The benefits that next and RSC offer, really don't seem to be worth the cost.
Re: Denial of service and source code exposure in React Server Components
#110I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
I saw this kind of interactivity in Apache Wicket Java framework. It's very interesting approach.