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

151–160 of 232 posts

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

#151

Post by thewtf »

stack_framer wrote: post #123
sangeeth96 wrote: post #37

Earlier quoted context omitted.

This is what I asked my small dev team after I recently joined and saw that we were using Next for the product — do we know how this works? Do we have even a partial mental model of what's happening? The answers were sadly, pretty obvious. It was hard enough to get people to understand how hooks worked when they were introduced, but the newer Next versions seem even more difficult to grok. I do respect the things Rea…

I feel the same. In fact, I'll soon be preparing a lunch and learn on trying out Solid.js. I'm hoping to convince the team that we should at least try a different mental model and see if we like it.

Should just use Vue.

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

#152

Post by awestroke »

Uehreka wrote: post #55
tom1337 wrote: post #26

Earlier quoted context omitted.

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 a…

We're migrating away from both Next and Vercel post-haste

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

#153

Post by reissbaker »

robertoandred wrote: post #138
reissbaker wrote: post #120

Earlier quoted context omitted.

Personally, I love App Router: it reminds me of the Meta monorepos, where everything related to a certain domain is kept in the same directory. For example, anything related to user login/creation/deletion might be kept in the /app/users directory, etc. But I really, really do not like React Server Components as they work today. I think it's probably better to strip them out in favor of just a route.ts file in the di…

Route files are still RSCs. Actions/“use server” are unrelated.

Route files are no different than the pages router that preceded them, except they sit in a different filepath. They're not React components, and definitely not React Server Components. They're not even tsx/jsx files, which should hint at the fact that they're not components! They just declare ordinary HTTP endpoints.

RSCs are React components that call server side code. https://react.dev/reference/rsc/server-components

Actions/"use server" functions are part of RSC: https://react.dev/reference/rsc/server-functions They're the RPC system used by client components to call server functions.

And they're what everyone here is talking about: the vulnerabilities were all in the action/use server codepaths. I suppose the clearest thing I could have said is that I like App Router + route files, but I dislike the magic RPC system: IMO React should simplify to JSON+HTTP and forms+HTTP, rather than a novel RPC system that doesn't interoperate with anything else and is much more difficult to secure.

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

#154

Post by cjonas »

hmcdona1 wrote: post #65
Uehreka wrote: post #55

Earlier 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 would highly recommend just checking out TanStack Router/Start instead. It fills a different niche, with a slightly different approach, that the Next.js app router just hasn't prioritized enabling anymore. What app router has become has its ideal uses, but if you explicitly preferred the DX of the pages router, you might enjoy TanStack Router/Start even more.

Last time I tried tanstack router, I spent half a day trying to get breadcrumbs to work. Nit: I also can't stand their docs site.

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

#155

Post by Seattle3503 »

awestroke wrote: post #152
Uehreka wrote: post #55

Earlier 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…

We're migrating away from both Next and Vercel post-haste

What are you migrating to? Vanilla React?

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

#156

Post by LittleOtter »

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.

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

#157

Post by danabramov »

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.

For what it’s worth, I’ve just built an app for myself with RSC, and I’m still a huge fan of this way of building and structuring web software.

I agree I underestimated the likelihood of bugs like this in the protocol, though that’s different from most discussions I’ve had about RSC (where concerns were about user code). The protocol itself has a fairly limited surface area (the serializer and deserializer are a few kloc each), and that’s where all of the exploits so far have concentrated.

Vulnerabilities are frustrating, and this seems to be the first time the protocol is getting a very close look from the security community. I wish this was something the team had done proactively. We’ll probably hear more from the team after things stabilize a bit.

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

#158

Post by phplovesong »

SSR is just dumb. Its very rare that you would benefit much from this approach, the only thing you get an complexity bomb exploding in your face.

How about either just return html (maybe with htmx), or have a "now classic" SPA.

The frontend must be the most over engineered shitshow we as devs have ever created. Its where hype meets the metal.

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

#159

Post by sakesun »

jaredklewis wrote: post #122
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 do think RSC and server side rendering in general was over adopted. Have a Landing/marketing page? Then, yes, by all means render on the server (or better yet statically render to html files) so you squeeze every last millisecond you can out of that FCP. Also easy to see the appeal for ecommerce or social media sites like facebook, medium, and so on. Though these are also use cases that probably benefit the least f…

Deeply agree.

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

#160

Post by pjmlp »

sangeeth96 wrote: post #41
pjmlp wrote: 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.

They weren't the new shinny to pump up the CV, and fill the Github repo for HR applications.
Post reply on HN