Static page authentication with iron-session

[OArnarsson]

Hello all

I'm wondering if there is a way to use next-session to lock down statically generated pages. I realize this may be quite a specific use case, but nonetheless one I would really like to solve.

To expand on the problem: Say I have website with around 200 pages of non-dynamic content (not saying static as I currently need to serve all content via SSR to gain access to the req.cookies etc.). Now if 100.000 users all decide to open up the same page, the server still needs to generate the page a 100.000 times.

So my question is this: Is there a way to use getStaticProps instead of getServerSideProps but still lock routes for users without ironCookie sessions? Can iron-session be used as a middleware with NextJs 12, right now the unseal function as well as reaching the session is unavailable as eval is not allowed in middlewares.

Sidebar: Maybe using serverless function cache could be of assistance here? If anyone has any experience using that with next-session all pointers are appreciated.

[vvo]

About your use case: you're trying to protect static webpages and only allow users with a valid session to access them? I guess the middleware option is a good one indeed but as you saw it might not be working as of now.

Can you give a bit more context on your usecase (i.e. why do you need this?). It will help understanding.

Can iron-session be used as a middleware with NextJs 12, right now the unseal function as well as reaching the session is unavailable as eval is not allowed in middleware.

This is interesting, could you create a separate issue and an example that demonstrates the problem? Start from the example here: https://github.com/vercel/next.js/tree/canary/examples/with-iron-session and build your middleware example that will fail.

I am not sure where's the eval usage in the code right now so it will help to have stacktraces/errors also.

[OArnarsson]

Thanks for the quick reply @vvo

So: I've set up a repo in which I try using a middleware to access the user cookie. The middleware file can be found here, the comments in the file contain the errors printed in the console when running the middleware.

So there are essentially two separate issues:

• Can we use middlewares to make sure a user is logged in and then serve the dynamic content server-side? I see you are using SWR hooks in the example project without middlewares and client-side rendering the content , that's a good solution as well, but it does enable content flashing on first render, which isn't a great fit for my current project as all the pages are really an all or nothing case.
• Can we somehow make sure a user is logged in while still using getStaticProps all rendered content is 100% static and identical for all users?

[GabenGar]

Can we use middlewares to make sure a user is logged in and then serve the dynamic content server-side?

No, but you can boot out the users without a cookie in the middleware. This will thin out the requests passing through for further auth. But the proper middleware auth requires a persistent server to fetch from or write an auth wrapper for SSR routes.

Can we somehow make sure a user is logged in while still using getStaticProps all rendered content is 100% static and identical for all users?

That's a pretty vague question and entirely depends on what you are doing with your 100% static page. Generally auth for those is realized client-side and thus you put the auth checks into API routes.

[itorz7]

now, can used it with middleware ???

[vvo]

You can now use iron-session in middleware.ts. I am not sure if that solves this issue, if not open a new one.