I remember when my greatest fear was sql injection. It’s great to see we have become more secure with our technology.
Denial of service and source code exposure in React Server Components
51–60 of 232 posts
Re: Denial of service and source code exposure in React Server Components
#52It'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.
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.
an insecure software will have multiple CVEs, not necessarily related to each other. Those 3 are probably not the only ones.
Re: Denial of service and source code exposure in React Server Components
#53It'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.
Welcome to the React, Next, Vercel ecosystem. Our tech may be shite but we look fancy.
The Vercel CEO post congratulating his team for how they managed the vulnerability was funny
Re: Denial of service and source code exposure in React Server Components
#54Earlier 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.
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
Re: Denial of service and source code exposure in React Server Components
#55React 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 was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusio…
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 anyone say they like the App Router (and this is a pretty contrarian site, so if they existed I’d expect to see them here).
Re: Denial of service and source code exposure in React Server Components
#56Wouldn't make more sense keeping React smaller and left those features to frameworks? I liked it more when it was marketed as the View in MVC. Surely can still be used like that today but it still feels bloated
git checkout v15.0.0
There we go.
Re: Denial of service and source code exposure in React Server Components
#57Earlier 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.
[deleted]
Re: Denial of service and source code exposure in React Server Components
#58I 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."
I think people just never understood SPA.
Like with almost everything people then shit on something they don’t understand.
Re: Denial of service and source code exposure in React Server Components
#59Earlier quoted context omitted.
Does Facebook actually use RSC? I thought it was mainly pushed by the Nextjs/Vercel side of the React team.
No, but it's primarily because Meta has their own server infrastructure already. RSCs are essentially the React team trying to generalize the data fetching patterns from Meta's infrastructure into React itself so they can be used more broadly. I wrote an extensive post and did a conference talk earlier this year recapping the overall development history and intent of RSCs, as best as I understand it from a mostly-ext…
So contrary to all other changes, this one was not done for Facebook to use. What was the reason behind RSC then?
Re: Denial of service and source code exposure in React Server Components
#60LOL. I must have divination powers. I am currently working on a UI framework and opened an issue just 3 weeks ago that says: *** Seems that server functions are all the rage. We are unlikely to have them. The main reason is that it ties the frontend and the backend together in undesirable ways. It forces a js backend upon people (what if I want to use Go for instance). The api is not client agnostic anymore. How to s…
I'm curious about your UI framework, is it public?