31–40 of 276 posts
till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.
Earlier quoted context omitted.
This is not related to ”use server”. That’s used to mark Server Actions / Server Functions, and it is not necessarily used in files with Server Components.
It sounds related to me. The react.dev blog post [1] says that the vulnerability is > a flaw in how React decodes payloads sent to React Server Function endpoints and the react.dev docs for React Server Functions [2] say that > Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive So it certainly…
The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property).
return moduleExports[metadata.name]
My guess is this won't be the last time we see security fallout from that design choice. Not because React is sloppy, but because it’s trying to solve a problem category that traditionally requires explicitness, not magic.
This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…
Building a private, out of date repo doesn't seem great either.
CVE 10.0 is bonkers for a project this widely used
till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.
It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the developer with more grounded flexibility than RSCs. I wrote a blog post about this[0].
To answer your question, htmx solves this by leaning on the server immensely. It doesn't provide a complete client-side framework when you need it. RSCs allow both the server and the client to co-exist, simply composing between the two while maintaining the full power of each.
[0] https://saewitz.com/server-components-give-you-optionality
till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.
easier/more reactivity, doesnt require your api responses to be text parsable to html
till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.
What do you like to work with now?