Private pages in Next, even when you don't have a server #49

[eric-burel]

Crosspost from VulcanJS/vulcan-next#49, where we provide the full code

Goal

Easy, intuitive, way of creating private pages visible only by logged in users.
Should work with and without SSR.
Should also work in client-only context, like any other "JAMstack"-friendly framework.

Previous art

• Question "How to redirect in getStaticProps" in Next repo. This is the most insightful ressource on the question, as it raises the broader question of redirect in a static page. The page being private is a special case of this, where you not only want the user to be redirected if not logged in, but you also want the static version of the page to never exist in the first place.

• Stack overflow question

• Example that works in dynamic mode, but does not talk at all about static render

• My unanswered question in spectrum regarding redirection Dead link...

• RFC about custom route, don't seem to adresse the issue

• Hosting on github pages => leads to a dead wiki link

• What about Gatsby? The key difference between Gatsby and Next is the Next's ability to do dynamic server side rendering, which is necessary to create real "private" pages with SSR. In Gatsby, private pages are client-side only. That defeats the purpose of dynamic SSR.

What we need

• During dynamic server render, use an HTTP redirection.
• During client side rendering, use the Router
• During static rendering, disable the route altogether. Private pages should become "client-only" pages, like in a normal SPA. Spoiler alert: this is the use case that bothers me the most here

Private pages only make sense either client-side, or during dynamic server-render, because they depend on whether the user is logged in or not.
Static render happens on your dev machine, once, like the application build itself, so it does not know the end user. Private page of a statically rendered Next app should be rendered client-side only.

First attempt, with getInitialProps in custom _app

Intuitively, if you are used to react-router or alike, you'll want to setup a global redirection at the top level, so basically adding auth checking and redirection in _app getInitialProps

TL;DR: this is wrong. This is intuitively what you'll do when used to React router or alike. You'll define an array of public routes, and let the user pass when the route match. That's wrong. You'll redirect to the login page if the user is trying to open a private route while not being connected. Wrong wrong wrong.

In Next, the router is the page. Everything must happen at the page level. Defining the layout, defining redirections, checking auth, etc., etc.
I've never met yet a page with only private pages, if only the login page.

My takeaways:

• getInitialProps is called client-side too when you click a link. Beware of this scenario, in this case, you can call Router.push to redirect.
• appContext.ctx.res is available both during STATIC server-render and DYNAMIC server-render.You need to check for res.writeHead to be available if you want to redirect during server render.
• Do not change _app render based on props status computed during getInitialProps. I've had a weird behaviour breaking apollo SSR of private pages. Basically the app props were not directly enhanced with currentUser, computed during this call. So the Apollo queries were not collected as expected during getDataFromTree, resulting in an app in loading state.

Code looks like this and you should not do that because this is wrong:

// Various helpers
export const redirectServer = (ctx: NextPageContext) => (pathname: string) => {
  ctx.res.writeHead(302, { Location: pathname });
  ctx.res.end();
};

const isServerSideRenderCtx = (ctx?: NextPageContext) => {
  return !!(ctx && ctx.res && ctx.res.writeHead);
};
const isStaticRenderCtx = (ctx?: NextPageContext) => {
  return !!(ctx && ctx.res && !ctx.res.writeHead);
};
const isClientRender = () => {
  return typeof window !== undefined;
};

// The page
...
// getInitialProps
PrivatePage.getInitialProps = async (ctx?: NextPageContext) => {
  // We simulate private connexion
  const isAllowed = !!ctx.query.allowed; // just for the demo, replace with a check that the user is logged in
  const pageProps = {  isAllowed };
  if (isAllowed) {
    return { ...pageProps, isAllowed };
  }
  if (isStaticRenderCtx(ctx)) {
    debugNext("Detected static render, not doing anything");
    // TODO: this is bad...
  } else if (isServerSideRenderCtx(ctx)) {
    // Scenario 2: we are in a server-side render
    debugNext("Detected dynamic server-side rendering");
    redirectServer(ctx)("/vns/debug/public"); // redirect server
  } else if (isClientRender()) {
    // Scenario 3: we are client-side
    debugNext("Detected client render");
    debugNext("Redirecting (client-side)");

    Router.push("/vns/debug/public");
  }
  return pageProps;
};

Second attempt, with getServerSideProps and getStaticProps, in the page

• the function is not called client side, but is reruns server side

// So beautiful
export const getServerSideProps = async (ctx: NextPageContext) => {
  const isAllowed = !!ctx.query.allowed; // demo
  if (!isAllowed) {
    debugNext("Redirecting (dynamic server render)", ctx.req.url);
    redirectServer(ctx)("/vns/debug/public");
  }
  return { props: { isAllowed } };
};

Issues I struggle to solve

• I can't tell from the doc and all articles and answer what's the best course of actions to create a private page in Next.

• As far as I understand, next export is the only way to have an application that do not rely on the server. Something I could host on GitHub pages.
  From the doc:

Next.js automatically determines that a page is static (can be prerendered) if it has no blocking data requirements. This determination is made by the absence of getServerSideProps and getInitialProps in the page.

Agree with that. However, it's not because a page cannot be prerendered, that you don't want the whole app not to be statically exported.

next build WON'T create such an app, as far as I understand. Or at least, I found no doc about this.

If you define a page with getServerSideProps, which you need to in order to have server-side redirect, Next considers that you opt out from static export. This feels wrong, I could still want to have a simple client-side redirect in scenarios where

• More broadly, it seems that Next doesn't like the scenario where your app could both be deployed as a static app, and using SSR. However I often encounter the scenario where the app as a canonical SaaS version, but could also be deployed on-premise. In this case, having a client-only version is nice, even when it includes private pages.

[eric-burel]

To be very concrete, I do not expect to get this error during next export, just because I have defined getServerSideProps:

Error: Export encountered errors on following paths:
	/vns/debug/private
    at exportApp (/code/vulcan-next-starter/node_modules/next/dist/export/index.js:22:1166)
    at process._tickCallback (internal/process/next_tick.js:68:7)

The pages should simply not be rendered, but be kept available in the app client-side.

[eric-burel]

3rd attempt, working ok

I think I've figured out, see code here

Basically:

• I use getInitialProps, to bypass error thrown when getServerSideProps is defined when you run next export. This is hackish, the presence of getServerSideProps should not be failing export (see long text above)
• I use next/router both in the component (to handle static mode) and in getInitialProps (this function is not only run during SSR, but also when you use next/router client side => the Router.push avoid a flash of the private page)
• I detect server-side rendering to do the HTTP redirect (mimicks getServerSideProps).
• I detect static export, and render nothing in this case.
• I need a bit of client-side logic to avoid flashing the page while using hooks

Now, all tests are passing: SSR, client side, shallow routing, and static mode.

What I did not test at this point, is Apollo data fetching.

Cases I needed to handle

• server side rendering (we render the page if allowed, HTTP redirect if not)
• static rendering (we render nothing, but we still include the page into the build)
• client side rendering, after a static export (we check client side if the user is auth, and redirect or not. we display nothing during this check or if we are redirecting)
• client side rendering after a client redirect using next/router (same)
• client side rendering after SSR (we use props passed by getInitialProps to tell if the user is allowed, directly at first render)

I think the client side rendering after redirect/in static mode is inelegant. We use a useEffect not to fail server side, but client-side it should be synchronous. Instead we probably should write a condition? Can we call "router.push" directly in the render or is it an anti-pattern?

[eric-burel]

I made it an HOC available here, I think the ssr/static part is ok but I'd like to have feedback on the client-side redirections, which are triggered when running the app after next export. I try to avoid flashes (especially of the private page) as much as possible.

I also lack an elegant pattern to handle the case where you use a hook to check auth, like Apollo useQuery or SWR or alike.

[ricardo-rp]

The linked repo is no longer available.
I'm trying to do server-side redirection for static pages, but sadly I'm stuck with client-side redirection and a flash of content. Did you ever find a solution for this?

[eric-burel]

New link, but this is kind of an experimental mess. See this Stack Overflow answer.

Basically, I would not recommend redirection from getServerSideProps, I'd rather do only client-side redirection, and then incrementally improve with server-side redirection based on headers, from next.config.js: https://nextjs.org/docs/api-reference/next.config.js/redirects

[ricardo-rp]

Thank you for the reply.
Client-side will have to do while we wait for next.config.js to support redirects on the abscence of a header/cookie.