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

Denial of service and source code exposure in React Server Components

react.dev

Post reply on HN
Print view View original

161–170 of 232 posts

Re: Denial of service and source code exposure in React Server Components

#161

Post by pjmlp »

brazukadev wrote: post #54
sangeeth96 wrote: post #41

Earlier quoted context omitted.

> Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks. I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.

We are having this discussion because at some point, the people behind React decided it should be profitable and made it become the drug gateway for NextJS/Vercel

Worse, because Vercel then started its marketing wave, thus many SaaS products only support React/Next.js as extensions points.

Using anything else requires yak shaving instead of coding the application code.

That is the only reason I get to use them.

Re: Denial of service and source code exposure in React Server Components

#162

Post by nathants »

Just exchange json.

Backend in python/ruby/go/rust.

Frontend in javascript/typescript.

Scripts in bash/zsh/nushell.

One upon a time there was a low amount of friction and boilerplate with this approach, but with Claude and Codex it’s changed from low to none.

Re: Denial of service and source code exposure in React Server Components

#163

Post by qingcharles »

JeremyNT wrote: post #131
_jzlw wrote: post #81

Earlier quoted context omitted.

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.

Well, maybe it isn't so insane? Server side rendering has been with us since the beginning, and it still works great. Client side page manipulation has its place in the world, but there's nothing wrong with the server sending page fragments, especially when you can work with a nice tech stack on the backend to generate it.

Sure. The problem with some frameworks is that they attached server events to things that should be handled on the front-end without a roundtrip.

For instance, I've seen pages with a server-linked HTML button that would open a details panel. That button should open the panel without resorting to sending the event and waiting for a response from the server, unless there is a very, very specific reason for it.

Re: Denial of service and source code exposure in React Server Components

#164

Post by IceDane »

hitekker wrote: post #42
tagraves wrote: post #13

It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.

There are a lot of careers riding on the optics here.

No, there aren't. The react team isn't going to axe half the team because there's a high severity CVE.

Re: Denial of service and source code exposure in React Server Components

#165

Post by IceDane »

LittleOtter wrote: post #156

Our team is working to fix our Next.js project.It's so painful. Now I'm doubting RSC is a good engineering technology or a good practice.The real world is tradeoffs: RSC really help us improve our develop speed as we have good teamates that has good understanding of fullstack. Do hope such things won't happen again.

How is it painful? You need to bump a minor version? It took me less than 5 minutes 90% of which was waiting for CI. There's even a tool you can run to do it for you.

Re: Denial of service and source code exposure in React Server Components

#166

Post by firtoz »

WatchDog wrote: post #109

When 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 br…

People did complain about next exposing "react, not ready for production" things as "the latest and greatest thing from nextjs" for quite a while now

I had moved off nextjs for reasons like these, the mind load was getting too heavy for not too much benefit

Re: Denial of service and source code exposure in React Server Components

#167

Post by qingcharles »

theogravity wrote: post #45
rikafurude21 wrote: post #4

Im confused, did the update from last week for the RCE bug also include fixes for these new CVEs or will I need to update again? npm audit says theres no issues

You need to update again.

My Umami stats box got "pwned" about 15 mins after the last CVE was published and I spent an hour or so cleaning up that mess and upgrading everything. Not looking forward to doing it again today.

Re: Denial of service and source code exposure in React Server Components

#168

Post by locallost »

dizlexic wrote: post #126

I'm not going to let go my argument with Dan Abramov on x 3 years ago where he held up rsc as an amazing feature and i told him over and over he was making a foot gun. tahdah! I'm a nobody PHP dev. He's a brilliant developer. I can't understand why he couldn't see this coming.

I'm not defending React and this feature, and I also don't use it, but when making a statement like that the odds are stacked in your favor. It's much more likely that something's a bad idea than a good idea, just as a baseball player will at best fail just 65-70% of the time at the plate. Saying for every little thing that it's a bad idea will make you right most of the time.

But sometimes, occasionally, a moonshot idea becomes a home run. That's why I dislike cynicism and grizzled veterans for whom nothing will ever work.

Re: Denial of service and source code exposure in React Server Components

#169

Post by ManuelKiessling »

I really wonder why the swarm intelligence of software developers still hasn’t decided on a single best clearly defined architecture for serving web applications, decades after the building blocks have been in place.

Let the server render everything. Let JS render everything, server is only providing the initial div and serves only JSON from then on. Actually let JS render partial HTML rendered on the server! Websockets anyone?

Imagine SQL server architecture or iOS development had this kind of ADHS syndrome.

Re: Denial of service and source code exposure in React Server Components

#170

Post by dirkc »

simonw wrote: post #16

React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server. It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we…

I 100% agree. I didn't even bother to think about the security implications - why worry about security implications if the whole things seems like a bad idea?

In retrospect I should have given it more thought since React Server Components are punted in many places!

Post reply on HN