Authenticated loaders

[barbinbrad]

It's my understanding that all matched loaders are fetched in parallel. Is there a best practice for solving the problem that we only want to execute certain loaders if a user is authenticated?

[chadams]

would really like to kknow the answer to this as well., Looked over the documents and see no mention of this. Basically need to make sure config and auth is ran BEFORE any sub routes. right now they are run in parallel and its making fetch calls with-out having the bearer tokens

[pgsandstrom]

Its not a problem exposing API endpoints to unauthenticated user. They could just scrape them from the js bundle either way. For me this is more a question of tidyness. Its confusing to see a bunch of failed requests in the logs, both on the frontend and on the backend.

[barbinbrad]

I had an idea I wanted to run past you guys. It's not at all my own. But in other frameworks (.NET, for example) -- we often use decorators to "protect" a function.

What do you think about using JavaScript decorators to do the job here (in lieu of adding the same check and redirect code to each loader)?

@authenticated
export const loader = () => {}

I don't have experience with JavaScript decorators yet, but I'm thinking they are just function wrappers.

[chadams]

what we really need is a third argument to loader that passes in the parent loaders result, this way you can await those responses before proceeding. TanStack router does this

[supersnager]

const router = createBrowserRouter([
  {
   path: "/users"
   element: <UsersPage />
   loader: () => {
     return fetchUsers();
   }
  }
]);

ReactDOM.createRoot(document.getElementById("root")).render(
<AuthProvider>
  <SecondProvider>
    <ThirdProvider>
      <RouterProvider  router="router" />
    </ThirdProvider>
  </SecondProvider>
</AuthProvider>);

I have a similar problem.
My AuthProvider doesn't render children when authState is false (or when the token is fetching), however, due to React reconciliation algorithm the router loader is called first (before the AuthProvider renders).
I'm not sure but this is probably caused by the use of the following code:

react-router/packages/react-router/lib/components.tsx

Line 60 in a1ad764

let state: RouterState = useSyncExternalStoreShim(

After digging in the react-router docs and source I haven't found a better solution than checking auth state in the loader.
However, the problem is even worst when you have your router definition outside of the React tree because in the loader function there is no direct access to the state from the AuthProvider.

I'm trying to resolve this by wrapping the AuthProvider with the redux Provider and using the redux state directly (outside of the react tree) in the loader.

Another solution (without redux) is to save an auth state in the simple store object, set its value in the AuthProvider imperatively, and use it in the loader.
Something like this:

export const AuthStore = {
 loggedIn: false
}

It is possible that my way is good, but I am not sure.
I would really appreciate if someone from the react-router team could explain what is the recommended way to secure the route without downloading data through the loader.
I don't believe that this was not thought through when designing v6.4 because after all, it is one of the basic things in applications that use routing.

The new solutions used in v6.4 combined with React Relay will be awesome if this problem is solved.

[supersnager]

Here is my simple pattern: #9424 (reply in thread)

[chadams]

Adding this here for those stumbling onto this conversation
#9188

Might be worth nothing how other frameworks do it:
https://react-location.tanstack.com/guides/route-loaders#parallelized-execution-vs-serial-execution

[brophdawg11]

Hey folks! At the moment, just like Remix, all loaders are called in parallel and you should be checking stuff like auth state in all of your loaders. This is also important because with nested routing, re-used routes will not have their loaders re-executed. So if you only check in the /parent loader, then going from /parent/child-1 to /parent/child-2 will not re-check.

We have some ideas floating around internally on ways to solve this, so we'll update this discussion as soon as we start to solidify our ideas there.

[lzm0x219]

mark🙀

[ryanflorence]

We're designing the middleware API right now that will meet this use case and will be publishing an RFC soon.

You can see its progress on the roadmap here: https://github.com/orgs/remix-run/projects/5/views/1

[danielpza]

Something like this can work:

let resolveAuthenticatedPromise: (result: unknown) => void;

let authenticatedPromise = new Promise((resolve) => {
	resolveAuthenticatedPromise = resolve;
});

/** Call this function when the user is authenticated */
export function authenticateUser() {
	resolveAuthenticatedPromise(undefined);
}

/**
 * Makes sure the user is authenticated, useful to avoid 401 calls to the api
 *
 * @example
 * 	const loader = async () => {
 * 		return defer({ data: ensureAuthenticated().then(() => fetchData()) });
 * 	};
 */
export async function ensureAuthenticated() {
	return authenticatedPromise;
}

[danielpza]

I thought it could work without the defer but for me it just got stuck waiting for the promise to be resolved but the parent react tree never got rendered? idk

[phoneticallySAARTHaK]

I just tried something similar (using an external resolver), and it doesn't work for me.
When the promise is resolved, the loader is executed but nothing is rendered.

However, using an Updatable Promise, it works just fine. Either it's some javascript/promise quirk that I'm missing, or maybe it's due to way the RR handles promises in loaders.

Snippet

let promiseResolver: (v: boolean | Promise<boolean>) => void;
const _prom = new Promise<boolean>((r) => void (promiseResolver = r));

const userChoicePromise = new UpdatablePromise(_prom, promiseResolver);

const router = createBrowserRouter(...
// root route loader:
async loader() {
  await userChoicePromise;

  //... this code gets executed once promise resolves, and element is rendered, but doesn't happen with a normal promise

  return redirect("/user-choice")
})

Note: The resolver/userChoicePromise is passed as prop to a react component (fallbackElement in my case)

@brophdawg11, Can you provide some insights?

[brophdawg11]

I'm not sure what you're running into but using a raw promise behaves as it should: https://codesandbox.io/s/admiring-dust-gjcg54?file=/src/index.js

You do not want to hinge your authentication on a single promise though - as they can only be fulfilled once and what happens if the user logs in and then logs back out? Or their session times out and they need to be downgraded to an anonymous user? Once your authenticatedPromise is resolved it's resolved forever. Instead, you should be checking some source of truth each time in each of your authenticated loaders. And eventually, middleware will provide a much simpler API for this to reduce the duplication across loaders.

[phoneticallySAARTHaK]

My bad, I should have tested on a minimal example before posting the issue.
I did test it worked as expected.
Most probably there was some unupdated loader (awaiting a promise that would never resolve) which was stalling the whole render.

Using a helper function is more convenient

export const createAuthenticatedLoader = (loader) => {
  if (await ensureSession()) return loader();
  else throw redirect('/login');
};

[knownasilya]

Took the idea above and fleshed it out

export const authenticatedLoader = <T extends LoaderFunction<any>>(
  load: T
): LoaderFunction<T> => {
  return async (args: LoaderFunctionArgs) => {
    const authenticated = await authenticate();

    if (authenticated) {
      return await load(args);
    } else {
      throw redirect('/login');
    }
  };
};

Used like so:

export const loader = authenticatedLoader(async ({params}) => {
  const users = await api.getUsers(params.companyId);

  return {users};
});

Thinking of even passing a second argument with the current user to the provided function..

export const loader = authenticatedLoader(async ({params}, {currentUser}) => {
  const posts = await api.getUserPosts(currentUser.id);

  return {posts};
});

[vaynevayne]

How does everyone do the permissions module?
Here's what I'm thinking. I'd like you to comment on it.

export const routers= [
  { path: '/', element: <Navigate to="/realtime" replace /> },
  { path: '/login', element: <Login /> },
{
  element: <BasicLayout />,
children:[]
},
  { path: '*', element: <NotFound /> },
]

const BasicLayout =()=> {
const {userInfo, isLoading,fetchUserInfo} =  useStore() // zustand 
let location = useLocation();
 useEffect(() => {
    if (!localStorage.getItem('token')) {
      navigate('/login')
    }
   if(!userInfo){
     fetchUserInfo()
   }
   //... also fetch other global data

  }, [location.key])

if (isLoading  || otherGlobalDataLoading) {
    return <LoadingOverlay  />
  }

return  <MyErrorBoundary>
          <Suspense fallback={<Loader />}>
            <Outlet  />
          </Suspense>
        </MyErrorBoundary>

}

const App = ()=> {
return  <Suspense>
                <RouterProvider router={_router} />
              </Suspense>
}



// axios.ts 
import { router } from './App'
 router.navigate('/login') // token 401
localstorage.delete('token') //  option

// Login.tsx
//  Refresh the page directly, this is the easiest way, otherwise you have to reset all the state, e.g. userInfo globalData
  const doLogin =>     window.location.replace('/') 

[brophdawg11]

It depends on whether the user is logged in and whether the page requires authentication.

• Not logged in, accessing / - no redirect, root's useLoaderData().user will be null
• Not logged in, accessing /protected - redirects to /login
• Logged in, accessing / - no redirect, root's useLoaderData().user will be populated
• Logged in, accessing /protected - no redirect, root's useLoaderData().user will be populated

Because all loaders run in parallel, you should be checking authorization in every protected loader and redirecting if not logged in. Most of the time this means just a one line utility function:

function requireLoggedIn() {
  if (!isLoggedIn()) {
    throw redirect('/login');
  }
}

Then you can do this in every protected loader:

function loader() {
  requireLoggedIn();
  // If it didn't throw the redirect we know at this point we're logge din
}

[vaynevayne]

https://codesandbox.io/p/github/vaynevayne/react-auth
I have made a project that can be used in production environment according to your idea, please help me to check whether my design is reasonable, in addition, clicking logout will cause an error, can you help me to solve it? thank you

[mhmdjaw]

@brophdawg11 What if the isLoggedIn() contains an API call to check for authentication status? That would be too expensive to run in every loader. What I would want is to make that call once initially when the app opens and before all loaders run, and save that user object, and then in every loader I can check for authorization by checking the saved object. If the user was not logged in, and logs in at a later point, I can just reassign the new user through an action (same thing for log out).

My point is, the initial call before all loaders run is a separate matter from the middlewares that check the saved user object. I don't want all loaders to make API calls in parallel initially, hence the importance of something like beforeLoader.

[brophdawg11]

What I would want is to make that call once initially when the app opens and before all loaders run, and save that user object, and then in every loader I can check for authorization by checking the saved object

There's nothing stopping you from executing code before the initial loaders run - just handle your user initialization before calling createBrowserRouter:

import { initUser } from './user';

initUser().then(()=> {
  let router = createBrowserRouter(routes);
  let root = ReactDOM.createRoot(document.getElementById("root"))
  root.render(<RouterProvider router={router} />);
});

Then you can hold the user in a module scoped var in user.js and export utils like getUser/destroyUser/etc. to manage it from actions.

[AsuraKev]

its 2024 and i just got this situation as well. The thing is I am using Auth0 for authentication and i cant even verify that if a user is logged in or is authenticating when the loader runs ..... I felt like the loader only needs to run before mounting that page component rather than run as soon as is mounted