Replies: 13 comments 50 replies
-
|
And will a middleware for fetch requests be possible? Because currently the middleware is only for nextjs routes and not for fetch requests. A typical use case could be to automatically add an authorization token to request headers, detect when a fetch request gives a 401 error and do something about it, etc. This could apply to fetch requests made from the server or client component. |
Beta Was this translation helpful? Give feedback.
-
|
I would recommend a separate discussion for this, as it is separate from the Middleware convention in Next.js (and is talking more broadly about generic "middleware" in your app). |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if this is exactly what @sawa-ko is looking for but there is a WIP PR (#70961) introducing request interceptors. |
Beta Was this translation helpful? Give feedback.
-
|
@KBeDevel Unfortunately not, since it is also oriented to next path requests, and not to the use of fetch and make a request to an external api In theory it can be achieved, since next does something similar to implement the cache to the fetches. |
Beta Was this translation helpful? Give feedback.
-
|
Dumb question here: Where will it run? in the edge network (close to the client) or in the server (close to the DB)?? |
Beta Was this translation helpful? Give feedback.
-
|
You are typically hosting your Next.js application on a server in a single region. Middleware would run on the Node.js server, possibly before every request, depending on your configuration. There's nothing in Next.js that requires the use of a CDN/Edge Network. You can optionally configure and use a CDN with Next.js for caching static assets, but you don't need to. To run Middleware at the Edge Network layer, it requires deeper integration of the framework and infrastructure, which isn't something we can as easily accommodate (as it depends on the provider). With that being said, we're working with some of the community providers who do have Edge Networks to figure out what kind of contract it could look like for taking the Next.js output (like Middleware) and running it at the Edge Network layer. This is not something that is required to use Middleware, but an optimization (for serving a global audience) that those providers can handle. Hopefully this helps explain 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Is there a current RFC (draft or finalized) for this work? |
Beta Was this translation helpful? Give feedback.
-
|
I opened this under RFC to mark it as more of an "official" discussion, but I don't believe there's actually anything left to get feedback on from the original discussion. There won't be any API changes, or Middleware changes, other than just the ability to change runtimes from the default of Edge to Node.js. e.g. |
Beta Was this translation helpful? Give feedback.
-
|
I've been eagerly awaiting this feature in Next.js that would simplify authentication on every route for my app. Unfortunately, Version 15 didn't include this. Currently, my production app requires authentication on each route. However, due to the middleware edge runtime limitations, I'm forced to fetch an additional endpoint, Considering this limitation, I've begun exploring other React frameworks. Interestingly, the official React documentation now recommends Next.js App Router. I'm torn between migrating to a different framework or patiently waiting for this essential feature. I believe many developers face similar challenges. |
Beta Was this translation helpful? Give feedback.
-
|
@leerob Technically, yes, but it should not be triggered directly by the user. The session extension should be a background task automatically handled by the app. You could do it with a Server Action using a Client Component that either calls the action periodically (e.g. every 10 minutes or so) or when navigating to a different route (using I'd love to hear what you and other people here think about this. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah maybe another thing that fits into these "automatic request-time database queries" is also this:
(I guess this is semantically the same pattern as extending the session) |
Beta Was this translation helpful? Give feedback.
-
So... "everything" but that... "Redirecting" is technically also blocking data fetching when dealing with pages. Then I ask... why not also enable people for blocking API calls in general? I understand the push towards Server Actions but there are security concerns with them and everyone shouldn't be obligated/pushed to use a feature because it's "the new thing".
If not in Middleware, putting aside the "client component" chicanery to re-validate and update sessions, what is the proposed solution? Puting a server action in every page to be called at first render doing that check? Do I need to create a unit test or lint rule to check if each protected page is calling that function? |
Beta Was this translation helpful? Give feedback.
-
Are you using Next.js 15? https://nextjs.org/blog/next-15#enhanced-security-for-server-actions. Server Actions have been around for some time now, I wouldn't classify them as new. |
Beta Was this translation helpful? Give feedback.
-
They are new in a wider, corporate application side of things... and while the improvements made are in the right direction, security through obscurity is not enough, when dealing with private data that needs authentication and authorization, without a middleware you still need to call functions to intercept and perform the task of checking who the user is and if that user can perform that action in every single server action. I'm using Next 14 until React 19 is stable or the ecosystem of packages I need to use becomes compatible with Next 15 and React 19RC. Yes yes I heard about features being stable, but in applications for corporate customers there's a need for stable versions and I'm tired of discussing it at this point. It's like the push towards all things cached, time showed that it was not a good idea to force it. |
Beta Was this translation helpful? Give feedback.
-
|
@leerob thanks for sparking this up! 🔥 Enabling nodejs runtime in the middleware, self-hosted, would allow everyone to use libraries such as Looking forward to it! |
Beta Was this translation helpful? Give feedback.
-
|
@leerob Node.js runtime in the middleware would be awesome! My challenge with middleware is that certain APIs, like The workaround I had to use was creating a new API endpoint just for decryption. Decrypting my cookie value directly from middleware would be wonderful and simple. |
Beta Was this translation helpful? Give feedback.
-
|
I don't see that what people use middleware for should be a framework level concern. Querying db for eg. session is some milliseconds in local network, even less on same machine. Of course one can do stupid things and block loading for 25seconds but that's always a possibility everywhere. I hope the implementation will not have any sandboxes or other significant performance overhead. Also it would be nice to manage to push data to asynclocalstorage from middleware and access it in components then. So for example pulling user info during auth check in mw and saving it to "request context" |
Beta Was this translation helpful? Give feedback.
-
You can try this -> https://www.npmjs.com/package/iron-webcrypto |
Beta Was this translation helpful? Give feedback.
-
|
I'm using NextAuth with Next.js 15 and the app router. After a user signs in (via an OAuth identity provider), I need to fetch some additional user information from a 3rd-party-system, which I'd like to add to the JWT in the cookie (because the information is used on every page). Unfortunately, the library necessary for the data fetching is not edge-compatible and during a Next build I get errors complaining about using Node.js-specific calls in my middleware (which uses NextAuth to protect the whole app from being accessed unauthorized). I worked around this by splitting my NextAuth config into two variants: a basic one which can be used in the middleware and a full-fledged one which does the additional fetching of user information. This does the job, but it's a nasty workaround IMHO. The application is supposed to be stateless (no additional database, Redis cache, etc.) and deployed on Kubernetes. @leerob Do you think in that case, running the middleware with the (aforementioned) Node.js runtime would be a feasible solution? Or is there some other (better?) approach which I might be missing? Fetching the data in a page and then utilizing |
Beta Was this translation helpful? Give feedback.
-
Yeah, agreed that's a frustrating limitation. When support for using the Node.js runtime lands, this should be much easier since you won't need to break it out.
Yeah, that approach seems okay – you're not doing blocking data fetching in Middleware, which is the thing to watch out for. I'm not use |
Beta Was this translation helpful? Give feedback.
-
This was something that came up in the authentication chapter of nextjs.org/learn that had me scratching my head: The course doesn't explain why the NextAuth config had to be broken up into two variants. You basically have to fiddle with it to realize why they did it that way. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I agree that it's clunky and splitting those in two is not an ideal solution. I took a more simple approach on my latest project. |
Beta Was this translation helpful? Give feedback.
-
|
@leerob I really like this setup, it's clean. I wish the nextjs.org/learn tutorial gets upgraded to follow that instead of next-auth :-). Thanks for sharing! |
Beta Was this translation helpful? Give feedback.
-
|
I think currently Next.js just isn't good for applications that need authentication, unless you don't know how to handle auth and use Clerk. Next.js middleware doesn't have the ability to set context in the actual app. Even when I check the user session in middleware, I still have to check it again in the actual app to get the user because I can't pass the user from middleware to the application. Not to mention that to check the session in middleware, I have to do it through an HTTP request to the API, because currently middleware is limited to running only on the edge, supposed vercel infra. I'm supposed to use vercel serverless postgresql db to call db inside middleware or what? You're supposedly working on adding Node.js runtime support to middleware (one if statement, maybe more because it needs to be compatible with vercel infra), but at this pace I don't know if you'll manage to announce it at Next.js conf 2026. An alternative, if you ever manage to add it, will be the mentioned request interceptors, but it still won't be a 100% good alternative for handling auth because you won't be able to modify cookies/headers there. Pilcrow (lucia-auth creator) gave you a good idea on how to solve this problem #70961 (comment), but you wrote that it's an intentional limitation because that's what middleware is for. How we are supposed to handle auth then? Seriously, does nobody at vercel know how to do auth and they just use sponsored auth saas solutions like Clerk, that they don't see any problem here? Or do you just want clients to pay you double for checking user sessions? |
Beta Was this translation helpful? Give feedback.
-
If you want to de-dupe for a given request, you can use the React
I'm sorry it hasn't been fixed yet. It is something we're actively working on, which is why I created this discussion so people can be notified when it's ready.
Could you put the |
Beta Was this translation helpful? Give feedback.
-
|
In the original RFC for middleware, there was a spec to allow for nested middleware - that would have been very useful for the express-like chaining. Looks like request interceptors will fill that role. @OreQr @soulchild when you guys say "auth", do you mean authentication or authorization? You could apply authentication via cookies in middleware, eg if path starts w/ I would argue authorization at the api layer (checking before making an admin-level db update) is more secure than punting it to a middleware up the chain. |
Beta Was this translation helpful? Give feedback.
-
I know, but React cache() doesn't work in middleware. Are you planning to make it work with Node.js runtime?
Yes, but what I mean is that I have to add extra code on every page/layout of the admin dashboard and make page dynamic at the same time. |
Beta Was this translation helpful? Give feedback.
-
|
I'm talking about ssr/react server components, not api. I wouldn't use Next.js Middleware for api/server actions. |
Beta Was this translation helpful? Give feedback.
-
|
I protect authentication via JWT cookies in middleware, any additional context that I need, I make in the nextauth callback and add it to the JWT token. Any serious |
Beta Was this translation helpful? Give feedback.
-
|
1 with OreQr, this is still my single biggest gripe with NextJS. As a beginner/intermediate developer, NextJS not having a proper and safe way to handle authentication (and authorization!) within middleware (or anything at all) completely throws me off. I'm working on a large project now using auth.js with dozens of pages requiring different authorizations and it blows my mind how messy and unsafe it is right now. Even though I cache everything in JWT and only do a database pull once on login, NextJS won't allow me to use it in middleware because it imports an "unsafe library" (never used in middleware anyways).
export async function validate(route){
user = auth();
if(!user.validated) {redirect("/login")};
const favColor = await myDB.get( user.id ).color;
return ( route( {favcolor:favColor} ) );
}
import { validate } from './requesthandler.ts';
@validate
export default function MyPage( params ){
return ( <p>My favorite color is {params.favcolor}</p> )
}
I know it couldn't look exactly like this because of how finicky ts/js decorators are but surely there's a way to accomplish something similar, at least. Again, I'm by no means an expert, but this is how I intuitively expect a system like this to work from prior experience with other frameworks. In my mind this fixes both the problems with redundant code for the developer and my personal problem with middleware now regardless of runtime, which is that it feels very non-nextjs/typescripty to have only a single middleware "program" that runs on everything and the need to hack together solutions for each page with regex and parsing request strings manually. I feel like a much more deterministic approach where you apply your own cookie-cutter "mini-middlewares" to each page just feels much more confident. |
Beta Was this translation helpful? Give feedback.
-
|
I don't quite understand your example. Why not just call your |
Beta Was this translation helpful? Give feedback.
-
|
The "get color" part is just to demonstrate passing data to a route, I know that's not how you would actually use something like that. The more important part is the redirect authentication, which would mean you could set different levels of validation for different routes non-repetitively and also make sure that if the user isn't authenticated no data from the hidden page is shown. |
Beta Was this translation helpful? Give feedback.
-
|
1 for "mini-middlewares" -- It was exactly what I looked for in the docs (and sadly found out they weren't a thing). |
Beta Was this translation helpful? Give feedback.
-
|
Here's one example of "mini-middlewares" today: https://github.com/vercel/server-components-notes-demo/blob/main/middleware.ts |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @leerob , I appreciate it! |
Beta Was this translation helpful? Give feedback.
-
|
Typically we'd make an auth check for every non-public route. Just checking if there is some bearer token, cookie or whatever form of identification. And then save the user data ( or that it's anonymous) to be available for later handlers. For some routes/route groups you might redirect instantly, for some not, it depends. Some have additional middleware etc. One of the points of this is to have a standard interface for accessing the user data later. So whatever authentication methods, services and libraries are used, after auth middleware the user model is the same. So basically authentication is entirely separated from the rest of the application which means there are less dependencies for the "web" part. Which means less code to bundle, faster build, faster apps. So any opportunity to move logic to the "server layer" that runs separate from "React layer" is a welcome addition. Maybe there are just very different views about this. Also there's a question about how much sense it makes to use Edge middleware when the data is in one location anyway. Might as well run the middleware there |
Beta Was this translation helpful? Give feedback.
-
|
Hello, do you have any ETA for this feature? Could you also explain why config flag for this feature was removed before? |
Beta Was this translation helpful? Give feedback.
-
|
Using the Node.js runtime for Middleware has never been supported – it was not removed. We're actively working on this! |
Beta Was this translation helpful? Give feedback.
-
Thank you for your time and great job. About the flag in experimental config I must miss reading it from some source |
Beta Was this translation helpful? Give feedback.
-
|
Currently, neither pino nor winston work out of the box for middleware logging. So we have to create two spererate instances of a logger for middleware files and server side code. See this discussion |
Beta Was this translation helpful? Give feedback.
-
|
Will we be able to use the Data Cache inside of middleware when using the nodejs runtime? |
Beta Was this translation helpful? Give feedback.
and others
-
We are actively working on supporting the use of the Node.js runtime for Next.js Middleware.
This discussion is a follow up from #46722 to allow folks to get notified as progress is made.
Beta Was this translation helpful? Give feedback.
All reactions