Confused on Next.js middleware recommendation
Setting up authentication for an internal tool and want to set up the middleware to perform authentication checks on pretty much every route. I'm wondering if anyone can help me understand the reasoning behind this recommendation in the docs (https://www.better-auth.com/docs/integrations/next#middleware)
"In Next.js middleware, it's recommended to only check for the existence of a session cookie to handle redirection. To avoid blocking requests by making API or database calls."
Couple of other questions:
"In Next.js middleware, it's recommended to only check for the existence of a session cookie to handle redirection. To avoid blocking requests by making API or database calls."
Couple of other questions:
- Am I right to assume that solely checking for the existence of a session cookie is not secure?
- In addition to checking for the existence of a session cookie, I should also be checking the session using getSession right?
- I'm wondering whether I should be doing the getSession check in the middleware, at the beginning of every protected route, or both.
- Is it possible to test using secure cookies locally? LLM noted that setting up a local HTTPS environment with a self-signed certificate is the best practice, any recommendations for doing so?
Solution
Yea the best practice is to optimistically check for the presence of cookie in the middleware, then check getSession on a route if you need to protect that route server side. Using getSession on a page requires headers which will opt your page out of static rendering and turn it into a serverless invocation instead of serving it from edge cache. For this reason, some projects may just use Cookie check in middleware and then a client side auth check using useSession instead of getSession server side. I personally do this to reduce cost, since serving a static page from edge cache is much faster and cheaper.
Middleware is not meant for blocking network requests, it slows down your site. Next.js suggests using non-blocking optimistic checks in middleware. The optimistic check pretty much says - if there isn't a cookie, then we can skip loading that route altogether. If there is a cookie, render the route. Then the route is a serverless invocation where you can check for getSession and use Suspense to render a loading state. Or you can have a static page with a client side check for isPending on useSession to render your loading state
Middleware is not meant for blocking network requests, it slows down your site. Next.js suggests using non-blocking optimistic checks in middleware. The optimistic check pretty much says - if there isn't a cookie, then we can skip loading that route altogether. If there is a cookie, render the route. Then the route is a serverless invocation where you can check for getSession and use Suspense to render a loading state. Or you can have a static page with a client side check for isPending on useSession to render your loading state
