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

Next.js version 15.2.3 has been released to address a security vulnerability

nextjs.org

Post reply on HN
Print view View original

191–200 of 220 posts

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#191

Post by jazzypants »

mattmanser wrote: post #127
whoknowsidont wrote: post #40

Earlier quoted context omitted.

You said it was easy to refute yet you merely stated a mis-framed, contrarian perspective. If you're going to try to be pedantic, do it right? >Next.js would be a terrible choice for any app that has any non-trivial compute Most web apps only need trivial compute. If you're including back-office, source systems in the word "web app" well that's your sticking point, not mine.

How is it pedantic? What is your understanding of that word? Why do I have to laboriously explain a fairly simple concept? Here you go: Javascript is a non-compiled language. It is slow, orders of mangitufes slower than other languages such as Go, Rust, C#, Java, etc. Quick note, you might not understand orders of magnitude. It means 10^n times, so 1 order of magnitude slower is 10x slower, 2 orders of magnitude is 1…

Please, show me a single benchmark that shows any other language that is even a single "order of magnitude" faster than JavaScript at literally anything.

It's funny that you put in the effort to condescendingly define orders of magnitude, but you forgot to check to see if you were actually correct before writing out eight paragraphs that made you look like a pompous ass.

Hating JavaScript is just pointless and sad at this point.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#192

Post by whoknowsidont »

arandomusername wrote: post #184
whoknowsidont wrote: post #173

Earlier quoted context omitted.

>Isn't next.js the "source system" Absolutely not. You are pulling from something else. If you need authorization to view a page that means it's more than likely not going to be SSG or ISR, so both the Next.JS application and the source system should be doing authorization checks. >If you can't rely on your middleware then you are using the wrong tech. "If you can't rely on server less functions to run" I mean, I can…

> I mean, I can't help you there if that's your expectation that serverless functions will always run correctly. Crashing, failing I/O, are expected. What's not expected is logic code being ignored. I can't take you serious when you think it's acceptable to just skip past parts of your code. If you think bypassing middlewares is acceptable you are completely deluded. But I guess that's needed to pay $150/TB for bandw…

Did you even read the thread you're commenting on? What makes you think I think it's acceptable?

Some of you are truly insufferable, holy shit.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#193

Post by tasn »

kccqzy wrote: post #162
tasn wrote: post #145

Earlier quoted context omitted.

Same problem as using headers. That too is in-band, because the client can also create multipart requests.

That misses the point. The OP's original use case is for a middleware to wrap a client request. The middleware would reject such multipart requests from the client.

The same way that it can reject certain headers, like it could have done in this case. It's no different, still in-band.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#194

Post by WuxiFingerHold »

ramoz wrote: post #32

VC influence in the web space has been a fascinating thing. I hope Next's downfall sends a signal to the quality lib maintainers and changes direction (e.g. Remix and a f'd up router, TanStack w/ Start). SSR frameworks make me vomit.

The many false claims around those isomorphic frameworks (SSR and CSR after hydration) drive me crazy. But why should marketing fail at smart people?

"Drink this soda pop and see, you have pretty friends and look how happy you are!"

"Drive this car and be a successful business person and have a great house and family!"

"Use NextJS and be as successful and popular as those tech bros at X and YT".

Those frameworks have some small use cases (e-commerce, semi dynamic content delivered to low end devices with lots of JS later on for analytics), but most of the time old school SSR (RoR, Django, ASP.NET MVC, ...) or SPA (Vue with Vue router) are the more appropriate solutions.

Hype driven development is a very real thing.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#195

Post by andrewmcwatters »

dminik wrote: post #155

Tbh the entire middleware system in Next is awful and everyone would be better off if it was scrapped and reimplemented from scratch. For starters, there's no official way to chain multiple middlewares. If you want to do multiple things, you either stuff it all into a single function or you have to implement the chaining logic yourself. Worse, the main functions (next, redirect, rewrite, ...) are static members on an…

Wait, are you seriously saying the mechanism that has existed in Express for years is broken in Next.js?

What a joke.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#196

Post by amateurhour69 »

FINDarkside wrote: post #68
ashishb wrote: post #39

Next.js is based on a fundamentally flawed premise that one can write code that runs in the browser as well as the backend. The security posture for the code running in the browser is very different from the code running on a trusted backend. A separation of concerns allows one to have two codebases, one frontend (untrustworthy but limited access) and one backend (trustworthy but a lot of access).

This vuln doesn't really have anything to do with that premise. Middleware always run on the server.

[dead]

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#197

Post by DoesntMatter22 »

IceDane wrote: post #168
dminik wrote: post #155

Tbh the entire middleware system in Next is awful and everyone would be better off if it was scrapped and reimplemented from scratch. For starters, there's no official way to chain multiple middlewares. If you want to do multiple things, you either stuff it all into a single function or you have to implement the chaining logic yourself. Worse, the main functions (next, redirect, rewrite, ...) are static members on an…

I would argue if you're trying to chain middleware or communicate between middleware, you're already holding it wrong. In basically every other framework you would have similar issues, in that there is no good, safe way to achieve what you're describing except persisting some data on an object and then hoping for the best. It's brittle, not type safe and just generally poor design. With that said, I do agree that nex…

I can't think of too many popular frameworks that DONT support multiple middleware. Yes you persist data through all the middleware if needed, that's the whole point

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#198

Post by merb »

tasn wrote: post #145
kccqzy wrote: post #137

Earlier quoted context omitted.

Just use MIME multipart content-type to wrap an HTTP message inside another. This is commonly done for batching requests. Here is an example of how it might look like: https://cloud.google.com/storage/docs/batch#http

Same problem as using headers. That too is in-band, because the client can also create multipart requests.

It would work if all requests would be wrapped

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#199

Post by mgraczyk »

ashishb wrote: post #190
mgraczyk wrote: post #59

Earlier quoted context omitted.

I don't know, but I am just pointing out that the problems here are really about execution, not vision. There's no reason we can't properly enforce security boundaries in the browser, we already do it between the website's code and the local machine. These ideas have been around a long time and predate the internet. See for example Liskov's work on Thor: https://dl.acm.org/doi/pdf/10.1145/233269.233346

If a vision has not been executed despite so many people trying may be something is wrong with it?

No, many have executed this vision. Facebook was doing this since at least 2010

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#200

Post by foldr »

I find middleware annoying in general. It saves some typing, but it makes debugging much harder because you have to dig through layers of nested middleware to figure out why you’re seeing a 404, unexpected redirect, or whatever.

I’d rather just factor common logic into a function and call it in the handler for every route that needs it. Boring, repetitive - but easy to understand and debug.

It probably is a good idea to have some kind of thin middleware layer that adds an extra layer of auth protection, so that it’s more difficult to accidentally do something like allowing access to /api routes for users that aren’t logged in. But for reasons that are obvious in this context, you should never rely entirely on URL-based logic to protect access to resources.

Post reply on HN