What if your website could guard its secret rooms all by itself, without you lifting a finger?
Why Protected routes in frontend in Supabase? - Purpose & Use Cases
Imagine you have a website where some pages should only be seen by friends who have a special key. Without a system, you have to check each time if they have the key by asking them again and again on every page.
Doing this by hand means you might forget to check on some pages, or accidentally let strangers see private info. It's slow and confusing because you have to write the same checks many times, and mistakes can let bad people in or block good friends.
Protected routes let your website automatically check if a visitor has the right key before showing secret pages. This way, you write the check once, and the system keeps your private pages safe without extra work or mistakes.
if (userIsLoggedIn) { showPage(); } else { redirectToLogin(); } // repeated everywhere
useProtectedRoute(() => { showPage(); }); // centralized and automaticIt makes your website smart and safe, only letting the right people see the right pages without extra hassle.
Think of a social app where only logged-in users can see their messages. Protected routes make sure strangers can't peek, keeping chats private and secure.
Manual checks are slow and risky.
Protected routes automate access control.
This keeps private pages safe and user-friendly.
Practice
Solution
Step 1: Understand what protected routes do
Protected routes restrict access to certain pages so only authorized users can see them.Step 2: Connect with Supabase session usage
Supabase sessions help check if a user is logged in, enabling route protection.Final Answer:
To allow only logged-in users to access certain pages -> Option AQuick Check:
Protected routes = restrict access to logged-in users [OK]
- Thinking protected routes speed up loading
- Confusing route protection with data storage
- Assuming protected routes change app appearance
Solution
Step 1: Identify Supabase method for session retrieval
Supabase's current method to get session info is auth.getSession(), which returns user session data.Step 2: Compare options with official API
Options A, B, and C are outdated or incorrect method names; only getSession() is valid.Final Answer:
const user = supabase.auth.getSession() -> Option DQuick Check:
Use auth.getSession() to check login [OK]
- Using deprecated methods like auth.session()
- Calling supabase.session() which does not exist
- Confusing getUser() with getSession()
const session = supabase.auth.getSession();
if (!session) {
navigate('/login');
} else {
showDashboard();
}Solution
Step 1: Understand getSession() behavior
supabase.auth.getSession() is an asynchronous function returning a Promise, so calling it without await assigns a Promise object to session, not session data.Step 2: Analyze the code flow
A Promise object is truthy, so if (!session) evaluates to false, and showDashboard() executes regardless of login status.Final Answer:
The dashboard is shown regardless -> Option AQuick Check:
Async getSession() without await returns truthy Promise [OK]
- Treating async getSession() as synchronous
- Assuming session is null if user not logged in
- Ignoring Promise returned by getSession()
const { data: session } = supabase.auth.getSession();
if (!session) {
window.location.href = '/login';
}What is the main issue?
Solution
Step 1: Check getSession() usage
supabase.auth.getSession() returns a Promise and must be awaited or handled asynchronously to get session data.Step 2: Understand destructuring without await
Destructuring data from a Promise without await results in undefined or incorrect values, so session is not properly checked.Final Answer:
getSession() is asynchronous and must be awaited -> Option CQuick Check:
Always await async getSession() calls [OK]
- Not awaiting async functions
- Thinking window.location.href can't redirect
- Using getUser() instead of getSession() incorrectly
function ProtectedPage() {
const [session, setSession] = React.useState(null);
React.useEffect(() => {
const getSession = async () => {
const { data } = await supabase.auth.getSession();
setSession(data.session);
if (!data.session) {
navigate('/login');
}
};
getSession();
}, []);
if (!session) return <p>Loading...</p>;
return <div>Welcome to protected content!</div>;
}Solution
Step 1: Analyze async session retrieval in useEffect
The code correctly uses an async function inside useEffect to get the session and update state.Step 2: Check redirect logic for unauthenticated users
If no session exists, the code calls navigate('/login') to redirect users, protecting the page.Step 3: Confirm loading state handling
While session is null, it shows a loading message, preventing content flash before redirect.Final Answer:
This code correctly protects the page by redirecting unauthenticated users -> Option BQuick Check:
Async session check + redirect = protected route [OK]
- Using getUser() instead of getSession() for session check
- Calling navigate outside async context incorrectly
- Initializing session state synchronously causing errors
Ready to prove it?
Pass the test and this pattern moves unknown
