Live data from Hacker News

Denial of service and source code exposure in React Server Components

react.dev

41–50 of 232 posts

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

#41
post #12

I 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."

Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.

> 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.

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

#42

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.

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

#43
post #39

Were there not enough eyes on React Server Components before the patches from last week?

have you seen the code of next.js? its completely impenetrable, and the packages have legacy versions of the same files coexisting, it's like huge hairball

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

#44

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.

Thanks for the feedback, I adjusted it here so the first note is related to the impacted versions: https://github.com/reactjs/react.dev/pull/8195

I appreciate the follow up! I think it looks great now and doesn’t read as defensively anymore!

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

#46
post #12

I 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."

Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.

I sometimes feel like I go on and on about this... but there is a difference between application and pages (even if blurry at times), and Next is a result of people doing pages adopting React that was designed for applications when they shouldn't have.

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

#47
post #27

Earlier quoted context omitted.

What’s concerning about it? The first thing I thought when I read the headline was “wow, another react CVE?” It’s not a justification, it’s an explanation to the most obvious immediate question.

It's definitely a defensive statement, proactively covering the situation as "normal". Normal it may be, but emphasizing that in the limited space of a tweet thread definitely indicates where their mind is on this, I'd think.

Are you reading a different link? This statement is on a React blog post, not a Twitter thread.

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

#48

After Log4Shell, additional CVEs were reported as well. It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.

[deleted]

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

#49
post #12

Earlier quoted context omitted.

Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.

> 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.

Blazor? Razor pages?
Post reply on HN