Two different routers?

[thekaganugur]

Hi,
I have a case where I need a few public pages like: /login, login/otp, /refer and maybe a few more. These paths will be seen in the URL. They can be accessed via a link. For this part browserrouter works perfectly.

Other than everything will be behind the authentication wall. I want to hide the URL from the address bar on all of the things here and for these pages, there is no need to read the address bar too. These pages can be only accessed via in-app.

In summary

• I need a few pages like /login, login/otp, /refer to read and write to the address bar

• I need other pages to not read and write to the address bar. They can be accessed via only in-app navigation.

I'm not sure how to achieve this. This seems a bit different need than #10050 or #9601 and wasn't able to find a discussion that matches my needs.

[jamesmarrs]

Hey @thekaganugur!

You are definitely right, the links you provided are focused more on very complex components being built on the react-router infrastructure within one browser router, i dont think this is what you need!

Hopefully I can help though ~

Going off some assumptions here, but i think i understand what you are trying to do:

Assumptions:
You have an API that handles your authentication ~
You have are able to catch 401 unauthorized API calls ~

Even though certain pages will only be accessed by an authenticated user, its still okay if they write to the URL.

Here are a few tips on handling this:

If you have access to the users authenticated session at the time of the web request you can 301 redirect the user to a different URL if they are unauthorized.

Since your distribution is just a public javascript file (asuming your using webpack or something similar to bundle your javascript),
It should be okay to have authenticated routes in it... for example, maybe when the user logs in, you use the namespace /app/ for authenticated users. You would ideally catch any 401 unauthorized ajax requests and redirect the user elsewhere, like the /login page.

I wrote this using older react-router JSX because i think its easier to read, but can be adapted to any of the implementation methodologies in react-router ~

adding props to help get the point across, but ultimately its highly dependent on how you handle and process your authorized user!

<Routes>
  <Route path="" element={<Layout userLoggedIn={false} />}>
    <Route path="login" element={<Login />} />
    <Route path="refer" element={<Refer />} />
  </Route>
  <Route path="app" element={<Layout userLoggedIn={true} />}>
    <Route path="dashboard" element={<Dashboard />} />
  </Route>
</Routes>

Ultimately I think the problem is based less on how you would setup react-router and more handling authorized / unauthorized user sessions via web requests! Hopefully that helps!

[thekaganugur]

Hey, thank you for the reply. The flow you mentioned is okay. But, I have a constraint by business:

I need a few pages like /login, login/otp, /refer to read and write to the address bar.
I need other pages to NOT read and write to the address bar. They can be accessed via only in-app navigation.

Your suggestion, "Even though certain pages will only be accessed by an authenticated user, it's still okay if they write to the URL." doesn't fit the business needs sadly. They want to not write to the URL after the authentication. (it's weird but seems to me like the banking industry favors this way.)

So what I thought initially was to have both MemoryRouter(after auth), and BrowserRouter(for public unauth pages) adjacent to each other. Of course, this does not work.

Hope it's clear and waiting for your further support, thanks!

[jamesmarrs]

gotcha, since the actual hard constraint is NOT writing to the address bar, I would create a new entry point using a memory router (and code split it in webpack, or whatever bundle tooling you are using).

So you have your public site using a browser router, then your protected app using a memory router, not exposing state to the address bar ~ app.example.com or example.com/app that loads the different distribution ~ would be easiest to use a page reload to boot the 'other' application, if that makes sense!