Best practice around authentication checks in nested routes

[discoverlance-com]

I am working on an application that requires authentication. I am using the cookie session storage to store the auth cookie with secrets.

In my authenticated pages and layouts, I am using a requireUser function in my loader to verify or require an authenticated user session which validates the session cookie and also retrieves the user information from the database so I can do something like const user = await requireUser(request) when I need to access the logged in user details and also do auth checks.

My main concerns are:

1. Do I need to call the requireUser function in every authenticated layout? For example, I have the nested route structure, /dashboard/events and /dashboard/events/create. Do I need to call the requireUser function in the parent layouts and all child routes or do I only need to add it in the parent layout? Are there any gotchas for when I only add it in the layout? I know react router will load the data in parallel and revalidate so I should be covered if I only load it in the dashboard.tsx layout file right?
2. Should I consider another function, say, requireAuthentication which only checks the authentication and redirects if user is not logged in just like the requireUser function but does not fetch the user details from the database? Is this a good practice especially if I need to add authentication calls to all my loaders in nested routes and layouts at least to ensure that on pages where I want to require authentication but I don't want to get the user details, I am not making that extra database call?

In general, what is the best practice around authentication checks? Do I do it in my layouts only, will that suffice for all authenticated nested routes or do I need to do it in all layouts and nested authenticated routes?

Of course, for my actions, I am also making the check once more to make sure it's an authenticated request.

[harel-tussi]

Hey,
I'm also facing the same issue. Did you manage to get an answer for it?

[sergiodxa]

Do I need to call the requireUser function in every authenticated layout? For example, I have the nested route structure, /dashboard/events and /dashboard/events/create. Do I need to call the requireUser function in the parent layouts and all child routes or do I only need to add it in the parent layout? Are there any gotchas for when I only add it in the layout? I know react router will load the data in parallel and revalidate so I should be covered if I only load it in the dashboard.tsx layout file right?

You need to check for auth in every loader and actions that needs to be protected (it's not public), every loader/action can be fetched individually so not adding your auth check will leave them unprotected.

Imagine every loader as an API route, you have /api/events and /api/events/:eventId, you can't trust the client to always call both so one of them protected the other one, you need to protect both.

Should I consider another function, say, requireAuthentication which only checks the authentication and redirects if user is not logged in just like the requireUser function but does not fetch the user details from the database? Is this a good practice especially if I need to add authentication calls to all my loaders in nested routes and layouts at least to ensure that on pages where I want to require authentication but I don't want to get the user details, I am not making that extra database call?

This can work, but it will depend on how strict your auth needs to be, if you're ok with only checking for the cookie to exists then it's ok to do that, but some apps also check if the user has the correct role and if it's still active, imagine the user is banned, you want to ensure it can't keep using the app until it's logged out.

[sergiodxa]

Middlewares will be added in the future, the team already said they plan to do it.

But remember that middlewares will only prevent code duplication, if two loaders run in different request the middleware will run twice too.

And you can build your own middleware using high order functions.

function withAuth(loader: LoaderFunction) {
  return async (args) => {
    // do auth check here
    return loader(args)
  }
}

export const loader = withAuth(async ({ request }) => {
  // write code here
})

[discoverlance-com]

Thanks, yes I wanted to write this but then what about the module side effects due to high order functions? I know it's only documented on remix and not react router v7, but I think it also applies right? (https://remix.run/docs/en/main/guides/constraints#higher-order-functions)

Unless react router v7 approached it differently and it does not affect it. If module side effects with HOFS are still an issue, I am not sure how to circumvent it. It's a bit confusing how HOFs also lead to module side effects. Or can I still do it if I place my other auth checks in functions as below?

import { authorizeUser, requireUser, validateAccess } from '@/auth/checks.server'

function withAuth(loader: LoaderFunction) {
  return async (args) => {
     // do auth check here
    await requireUser(); 

    await authorizeUser();

    await validateAccess();
    
    return loader(args)
  }
}

export const loader = withAuth(async ({ request }) => {
  // write code here
})

[sergiodxa]

That was a thing in Remix with the Classic Compiler, with Vite it's not an issue anymore, and RR also uses Vite so it's safe there.

It's a bit confusing how HOFs also lead to module side effects

The problem is that a HOF is executing a function at runtime, the compiler didn't have a way to know that function didn't caused a side effect that other part of the module depended on, so the only safe thing to do was to leave the code there just in case

Imagine you have this HOF

let authenticated = false

function withAuth(loader) {
  return (args) => {
    authenticated ||= await authenticate(args)
    return loader(args)
  }
}

export const loader = withAuth(async (args) => {
  console.log(authenticated)
})

export default function Component() {
  if (authenticated) return <h1>Authenticated</h1>
  return <h1>Not authenticated</h1>
}

The HOF cause a side effect there by updating that module-level variable, because the compiler had no way to know if the HOF caused a side effect or not it keep the HOF call.

But Vite instead just remove the whole export from the client bundle, this means that it's safe to use a HOF that doesn't cause a side effect because Vite will just remove it regardless if it cause a side effect or not.

[discoverlance-com]

This is brilliant. Thanks very much for your explanation. Looks like I will go for HOFs where I have to do multiple checks.

[michaeljblum]

Thanks greatly for your so helpful responses here and elsewhere @sergiodxa - I recently moved from Next to RRv7 framework mode - been meaning to switch to Remix for closer integration with some Cloudflare stuff for a project, and thought why not use the latest.

Been really enjoying RRv7 but the docs are very undercooked relative to more mature frameworks. I found your blog through your replies here - super helpful stuff!