I have created routes for page navigation in React JS, now I want to make some of them protected, like I want some them to be accessible only when user Logged In.
const [isLoggedIn, setIsLoggedIn] = useState(false);
useEffect(() => {
const token = localStorage.getItem("token");
setIsLoggedIn(!!token);
}, []);
<Route path='/login' element={<Login />} />
<Route path='/signup' element={<SignUp />} />
<Route path='/casting/calls/creation' element={isLoggedIn ? <CastingCallsCreation /> : <Navigate to='/login' />} />
<Route path='/user/film/booth' element={isLoggedIn ? <UserFilmPitchingBooth />: <Navigate to='/login' />} />
here is how I have tried, but cause problem like when I try to navigate
to /casting/calls/creation
after login successful in login API call, then navigation does not work, it gives successful message for login but does not navigate to that page.
4
Answers
You can achieve that functionality like this
then write refresh code after success the api call like this
You can create an AuthGuard component and wrap your protected layout or route with it:
You can try this
The existing answers are fine, as far as they go. But there’s a crucial thing they leave out, and this is too long for a comment:
Never Trust The Client
Anybody can open up the browser dev tools and modify anything. Somebody could conceivably run your code in something that isn’t even a browser (much like we do ourselves with RTL and JSDOM) where they have full control over the value of variables.
The code in the existing answers is fine to help you not make a mistake and communicate to somebody reading the code what routes require authentication/authorization, but do not add any actual security. You must pass authentication credentials with every request (typically tokens that you generate and verify on the server) and assume that any code or data sent to the page is visible to the user (don’t count on your client-side code to prevent unauthorized viewing of data)!
If you are working solely on the front end (e.g. you work at a big company with dedicated teams/devs for different parts of the stack), then it’s somebody else’s job to deal with this part and you should make sure that your implementation piggy-backs on whatever they already have in place.
If you’re just learning, then make sure you don’t fall into this extremely common pitfall! It might be a good chance to learn a little server-side development as well.