Best way to secure /admin routes

[GriffinSauce]

Hi, so I'm slowly getting my head around sessions and auth with Next.js (deployed on Now). What I'm running into now is that I have a HOC ensureAdmin that I can wrap a page with to check that a user is authenticated and actually an admin. (the API routes are secured ofc so it's mostly a UX/visibility thing). The downside is that you need to repeat this for every page.

Is there a way to do this globally for everything under this path /admin? It would be nice to for instance have a custom _app.js that applies to this folder+children or something.

How do you solve this?
Should I just not try to limit access to the page and use a fetch hook to check client side after rendering the skeleton?

[janus-reith]

At which point do you have access to the authentication state?
You could create an api route with the catchall segment, e.g. api/authRoutes/[..slug].js

Then you could use the new redirect feature like this:

experimental: {
    redirects() {
      return [
        {
          source: "/admin/:authRoute*",
          destination: "/api/checkAuth/admin/:authRoute*",
          permanent: true
        }
      ];
    }
  }

checkAuth would be an API Endpoint with res and req and you could use headers/cookies/whatever from the request there to determine if authenticated and redirect to the actual route based on that.
In that function you could do something like this const { query: { slug } } = req and slug would then be an array of all sub-paths, in this case ["admin", "yourRouteName"] which you could join again to get the original route the client requested and redirect to it.

This way you have no added loading time and don't need to redirect clientside.

[timneutkens]

Instead of having the client fetch the data on that page while authenticating that call with the cookie/token/header/, and thereby needing to have that first-time query for data happening on the client, I might want to just have that page available statically, with all necessary but potentially sensitive data included. The server would parse necessary auth data from the request, and decide if that user is allowed to view the page.

This would always mean the static page is accessible by knowing the path, meaning it can be guessed and accessed. API routes can't prevent access to static pages, only redirect to them, otherwise the page wouldn't be static.

[janus-reith]

@timneutkens, oh ok, this really was a missing piece for me. I get that this is the case for static/serverless deployments, but didn't think that it would always be this way.

[trusheim]

When building dashboards we found the approach we use for zeit.co/dashboard to hold the best performance and scaling characteristics, so I'd definitely use this approach in all cases of deployment.

I just wanted to add a +1 to this discussion: it would be great to add some sort of support for static pre-rendering mixed with SSR. My use-case is similar to those in this thread: I'm generating an internal dashboard. Access is controlled via server-side authentication. However, the data in the internal dashboards are expensive to generate (20-30s). I'd prefer to pre-render all of the dashboard pages (e.g. hourly via a cron job, etc) and have server-side control over, basically, whether they're served.

The second-best solution (currently implemented) is to have the recurring process cache results and use SWR to pull down the cached results, but that's one more tool to manage, vs. just calling the build step hourly via deploy hooks.

[cdock1029]

@timneutkens Hi Tim, on Full Stack Radio podcast you described how with getServerSideProps being able to directly access database because it is excluded at build, this opened up clean usage of backend data access without needing a middle api layer, and that you guys might leverage this on vercel website.

Any heuristics as to when you think this is a better choice than loading skeleton shell and fetching data client side.. or what use cases your team is choosing getServerSideProps over swr?

[smblee]

Bumping an old thread but...

So each time my api route is invoked, it completely "boots" from scratch or where does it add time?

Not each time, serverless functions boot up and wind down though.

I get the CDN part, but apart from that I thought this is still way better than a client redirect or using initialprops for the whole page. I wonder how to handle this logic else?

Client-side handling allows for preloading the API url and a bunch of other optimizations like showing a spinner while data is being loaded.

Could to elaborate further on that? I mean, basically thats the same functionality I would expect the described API route to do. Where does the part sit that does this fetch and redirects? Outside of nextjs at all as some kind of router?

We have a custom hook that looks something like this (removed a bunch of business logic to make it easier to understand):

import { useEffect } from 'react'
import Router from 'next/router'
import useSWR from 'swr'

import { getUser } from '@lib/authenticate'
import { API_USER } from '@lib/api-endpoints'

export default function useUser() {
  const swr = useSWR(API_USER, () => getUser())

  useEffect(() => {
    if (swr.data && !swr.data.user && redirect) {
      // redirect to login
      Router.replace(
        `/login`
      )
    }
  }, [swr.data])

  swr.isLoggedOut = swr.data && !swr.data.user
  swr.user = swr.data?.user

  return swr
}

It just uses basic Next.js features + SWR basically

Also, are these considerations only necesary for serverless deployments or in general with api routes?

When building dashboards we found the approach we use for zeit.co/dashboard to hold the best performance and scaling characteristics, so I'd definitely use this approach in all cases of deployment.

How would you scale this for sub-routes? (e.g. if all routes under /dashboard (/dashboard/*) need to be protected).

[vvo]

Hey there, following the best practices from Zeit in @timneutkens comment here: #10724 (reply in thread)

I created an example that follows those practices, see it here: https://github.com/zeit/next.js/tree/canary/examples/with-iron-session

let me know what you think

[vvo]

can't tell exactly, apollo example is using JWT, I am using https://github.com/vvo/next-iron-session and https://github.com/vvo/iron-store behind the scenes. JWT is signed but not encrypted, I think we are diverging from the original question here though :D

[felixmosh]

@vvo Thank you for sharing this example.
There is one issue with the fact that the Layout component is part of the page, it get's re-render every page navigation.

[vvo]

@felixmosh indeed, since then I have been using techniques of "persistent layout" as shown here: https://adamwathan.me/2019/10/17/persistent-layout-patterns-in-nextjs/. I will update next-iron-session with it.

[lww]

Hey @vvo, thanks for the example.
How would you make additional API requests on the profile page only if user is logged in?
I want to prevent sending the requests, if there is no user.

[vvo]

Hey there, the best way to do it is to redirect people when they try to access pages that requires to be logged in.

You can find it in the example here: https://github.com/vvo/next-iron-session/blob/25032de07dc932396337427d43c9fc9a316b897c/examples/next.js/pages/profile-sg.jsx#L6-L10

Open an issue in next-iron-session if you need more information

[sandys]

@timneutkens how would you do oauth in this situation ? i saw the solution you posted with SWR, but im now confused how would oauth based authentication work in this case - e.g. google auth kind of thing.

others have asked this question in other places, IdentityModel/oidc-client-js#809

My whole site is SSR.

[bamofah]

@balazsorban44 Question. When u say used your own custom provider do you mean you where able to make use of the oauth0 package put configure it (urls etc) to point to your custom oauth server??

[balazsorban44]

@bamofah sorry for the late response, yes! we have IdentityServer 4, and it works well!

[bamofah]

@balazsorban44 thanks for the reply
so in that case did you use the package nextjs-auth0 but pointed it to our IdentServer 4? asking as I got an spring auth-server so was trying to figure how best to handle two specific oauth-flows using next js.

[balazsorban44]

Yes, using IDS4 with @auth0/nextjs-auth0

[bamofah]

@balazsorban44 nice will have to try and see if I can get it to talk to my spring-server

[balazsorban44]

Used the example they have given here: https://github.com/auth0/nextjs-auth0/blob/master/examples/basic-example/pages/api/me.js to create an API endpoint, to retrieve the user info with a single fetch call to /api/me. It can nicely be wrapped with https://github.com/auth0/nextjs-auth0/blob/master/examples/basic-example/lib/user.js for convenience. I made some modifications to the code, but the principle is the same.

…

On Thu, May 28, 2020 at 8:48 PM Kinbaum ***@***.***> wrote: @balazsorban44 <https://github.com/balazsorban44> Can you explain how you actually go about retrieving the user session object? I am able to see the user session information in the callback handler, but what approach did you take to actually get that user information displayed on the page? All i see from my cookies panel is an a0:state cookie. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10724 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMEVMLMKLTHNF4RMUE3KCLRT2WW3ANCNFSM4K5DEDDA> .

[irving-caamal]

https://github.com/nextauthjs highly recommended library which allows you to consume both popular(OAuth, google) and custom providers. with best OWASP practices

[vhakulinen]

One way you can do this is to create a layout which you use in all your admin pages and then in that layout do the permission checking.

[andremarcondesteixeira]

I would like to understand the "downvotes". This looks like a solution.

[guitheengineer]

Can be because this solution has the same problem below, which OP tried to solve:

The downside is that you need to repeat this for every page. [...] Is there a way to do this globally for everything under this path