Skip to content

⚠️ Issue - On demand rendering for protected page #6884

@eric-burel

Description

@eric-burel

Hi folks,

I am checking out the rendering modes documentation, and I've noticed that they on-demand rendering is recommended for protected pages. I've studied this topic a lot, and I think this recommendation is not correct.
On-demand rendering is necessary when your render depends on the specific content of an HTTP request. However, when protecting a route, you don't really use the request specificity, but rather a derived value shared by many users : "is the current user authorized", creating two groups, authorized users and the others.

In this situation, static rendering is actually the optimal choice. You simply have to couple it with an upstream access check. In Next.js this is done via an Edge middleware or a custom server. In Remix you'd do that with a custom entrypoint, or whatever proxy you use upstream if you can't use a custom entrypoint. Edit : I see you have middlewares out-of-the-box too, so they can be used already for the same goal. I am however not totally yet confident with how it would work on Vercel according to this doc, but that's besides the point.

If people prefer on-demand rendering for protected pages, it's mostly because this kind of protected static rendering is not easy to setup. But that's because the current generation of frameworks bases static rendering upon the URL only, which is not totally optimal, this idiosyncracy doesn't make them right.

I suggest reviewing this page of the documentation

  • "The same HTML document is sent to the browser for every visitor" => maybe just give a hint that with a more complex setup, it can be done for groups of users too
  • "Protected pages: Restrict access to a page based on user privileges, by handling user access on the server." => maybe also give a hint that in certain scenarios, if the protected content is the same for multiple users, static rendering can be used
  • And finally add a section about static rendering with protected content => basically you have to verify authorization before the user hits the URL, and redirect them accordingly. Works great if your app is behind a proxy or whatever upstream security check you may have.

A few resources:

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions