Protected layout.ts vs middleware.ts in Next's App Router

[rwieruch]

Hi @pilcrowOnPaper Thanks for this amazing library <3

I found your following reply regarding the middleware.ts vs protected layout.ts debate on Reddit: https://www.reddit.com/r/nextjs/comments/18q7gyq/comment/keujdn0/

In the case of Prisma: There are efforts under way to make Prisma compatible with the Edge Runtime. In another project of mine, I already use a beta release of Prisma which works with PlanetScale in Vercel's Edge Runtime.

So in this scenario, where the ORM provides Edge Support (so that it works in the middleware.ts) and the serverless DB (or ORM) provides world wide read replicas (like PlanetScale or Prisma Accelerate), would you say that it would be better to put the route protection on the middleware level or would it still be okay to use it in a layout.ts file in Next?

Is there any difference at all (or from a security perspective)?

Thanks for your time and effort. Maybe someone else can answer this question as well :)

[rwieruch]

Related https://x.com/sebastienlorber/status/1765405011826098670?s=46&t=30xnDcG7zsVn_XhbNW0vlg

[pilcrowOnPaper]

I would personally avoid using middleware for protecting resources at all. For Next.js specifically, there still isn't a straightforward way to share data between middleware and pages. Even if the framework provided something similar to locals, I would put all the logic in each route since it's the most straightforward approach.

[osseonews]

"There still isn't a straightforward way to share data between middleware and pages."

With all due respect, this is not true. The straightforward way to do this in middleware in Nextjs, which is just a Cloudflare Edge function under the hood, is to pass a custom header from the middleware, which you then read in pages. Some sample pseudo code is below. Having worked on porting over some auth to Nextjs app router for a few months, and working with many libraries, the way to do auth is to use a combination of middleware, page RSC, and server actions. Using middleware is essential because you can't set or delete cookies in RSC and there are other limitations in RSC. The only downside of Middleware is that you need to use a data source that can use edge, but this is trivial nowadays, as all of Vercel's storage partners can be used in edge. And you can always slap something like Hasura on top of a database and then just use fetch to interact with the data source.

const newHeaders = new Headers(request.headers);
  if (!token) { //pseudo code
    newHeaders.set('x-custom-access', 'denied');
    return NextResponse.next({ //return the headers which can be read in RSC
      request: {
        // New request headers
        headers: newHeaders
      }
    });
  }
newHeaders.set('x-custom-access', 'allowed');
//you can now do next reponse.next or even redirect
....

[rwieruch]

@pilcrowOnPaper do you think it would be okay to add optimistic checks to the middleware? Meaning: Only check if there is a cookie with a session present. If not, do an early redirect. If yes, do not check it against the DB (to have suffer from performance impacts) but just continue? Essentially in the middleware only performing the following task:

const sessionId = cookies().get(lucia.sessionCookieName)?.value ?? null;

if (!sessionId) {
  return NextResponse.redirect(new URL('/login'));
}

return NextResponse.next()

Then in the page/layout do the normal auth check like it's described in Lucia docs.

Inspired by: https://nextjs.org/docs/app/building-your-application/authentication#optimistic-checks-with-middleware-optional

[coratype]

Did you manage to get Lucia working in your Planetscale + Prisma Edge project? I'm currently trying the same and I'm getting an error at the validateSession part

✘ [ERROR] Session validation error: PrismaClientUnknownRequestError:

Invalid prisma.user.findUnique() invocation:

Cannot select both '$scalars: true' and a specific scalar field 'session'.

[herkulano]

@pilcrowOnPaper there's also the problem of session expiration. You can't set cookies in pages. You need to rely on users using server actions or routes to update the session, but you might have an app that relies almost entirely on reads that come from pages. What are your thoughts on this?

[osseonews]

You can set and delete the cookies in middleware. This is the best approach. You just use RSC to read the cookies and the request headers.

[herkulano]

@osseonews how do you set the cookie with a new expiration date if you can't check it? Given the requirement in the initial post that you don't have a DB that runs on the edge. If you can check it in middleware then you could do the redirecting in the middleware, there would be no need to do it on the pages as well, given that this is not the most secure place.

[osseonews]

I am not sure I understand the question. But, yes, you can do everything in middleware, check, set new expiration, redirect etc. and do nothing in Pages. It's up to you. We do it that way, but also send headers to the page to check some things, just as a another "backup" of sorts.

[herkulano]

@osseonews yes, if your DB ORM supports edge. Anyway, I'm curious to know what's @pilcrowOnPaper given that the his recommendation is not to use the middleware.

Security wise, the recommendation here: https://x.com/sebastienlorber/status/1765405011826098670?s=46&t=30xnDcG7zsVn_XhbNW0vlg is to avoid RSC for auth, and put it at the front (middleware) and at the back (data layer).

[osseonews]

I have no idea why someone would say not to use middleware. I think it's just a misunderstanding of what middleware is and how to use it. Certainly for Auth, you want to use middleware for mostly everything. Based on my experience, however, I would mention that you should not wrap an Auth function around middleware, in the way that an Auth service like Clerk recommends to do out of the box (see their set up). It's not necessary to do this, even for Clerk, and it will cause problems for various reasons. It's best to keep Middleware simple with simple routing logic. At the end of the day, Vercel middleware is just a Cloudflare Edge Worker function under the hood with a few added features, so you can use the best practices and recommendations from Cloudflare.

As regards to DB's: You can make nearly all popular DB's edge capable by slapping Hasura on top of it, if needed. Then you communicate with Fetch on Nextjs to the Hasura instance, which then connects to your database. There are other benefits to doing it this way, also.