Protected routes in frontend in Supabase - Step-by-Step Execution

Process Flow - Protected routes in frontend

User tries to access route

↓

Check if user is logged in

↓

User stays [User logs in

When a user tries to visit a protected page, the app checks if they are logged in. If yes, it shows the page. If not, it sends them to login.

Execution Sample

Supabase

const { data: { session } } = await supabase.auth.getSession();
if (!session) {
  redirect('/login');
} else {
  renderProtectedPage();
}

This code checks if the user session exists. If not, it redirects to login. Otherwise, it shows the protected page.

Process Table

Step	Action	Session Exists?	Branch Taken	Result
1	User tries to access /dashboard	Unknown	Check session	Proceed to check session
2	Check session with supabase.auth.getSession()	No	Redirect to /login	User sent to login page
3	User tries to access /dashboard again after login	Yes	Render protected page	Dashboard content shown
4	User logs out	No	Redirect to /login on next access	User must login again
5	User tries to access /dashboard after logout	No	Redirect to /login	User sent to login page

💡 Execution stops when user is either shown protected content or redirected to login.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5
session	undefined	null	object with user info	null	null

Key Moments - 3 Insights

Why does the app redirect to login even if the user was logged in before?

Because the session check (step 2) returned null, meaning no active session. The app must confirm session each time before showing protected content.

What happens if the user logs out but tries to access the protected route again?

At step 5, session is null, so the app redirects to login again, preventing access without login.

Why do we check session before rendering the protected page?

To ensure only authenticated users see protected content, avoiding unauthorized access (see step 2 and 3).

Visual Quiz - 3 Questions

Look at the execution table, what is the session value after step 2?

A null

B undefined

C object with user info

D false

💡 Hint

Check the 'session' variable in variable_tracker after step 2.

At which step does the app render the protected page?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Branch Taken' and 'Result' columns in execution_table.

If the user never logs out, what would happen at step 5?

A Redirect to login

B Render protected page

C Show error message

D Session becomes null

💡 Hint

Refer to variable_tracker and execution_table for session state after login.

Concept Snapshot

Protected routes check if a user is logged in before showing content.
Use supabase.auth.getSession() to get session info.
If no session, redirect to login page.
If session exists, render protected content.
Always verify session on route access to secure pages.

Full Transcript

Protected routes in frontend mean only logged-in users can see certain pages. When a user tries to open a protected page, the app checks if they have a valid session using supabase.auth.getSession(). If the session is missing, the app sends the user to the login page. After logging in, the user can access the protected page. If the user logs out, the session is cleared, and the app again redirects to login on next access. This flow ensures only authorized users see protected content.