Bird
Raised Fist0
Supabasecloud~3 mins

Why Protected routes in frontend in Supabase? - Purpose & Use Cases

Choose your learning style10 modes available
The Big Idea

What if your website could guard its secret rooms all by itself, without you lifting a finger?

The Scenario

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.

The Problem

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.

The Solution

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.

Before vs After
✗ Before
if (userIsLoggedIn) { showPage(); } else { redirectToLogin(); } // repeated everywhere
✓ After
useProtectedRoute(() => { showPage(); }); // centralized and automatic
What It Enables

It makes your website smart and safe, only letting the right people see the right pages without extra hassle.

Real Life Example

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.

Key Takeaways

Manual checks are slow and risky.

Protected routes automate access control.

This keeps private pages safe and user-friendly.

Practice

(1/5)
1. What is the main purpose of protected routes in a frontend application using Supabase?
easy
A. To allow only logged-in users to access certain pages
B. To speed up page loading times
C. To store user data permanently
D. To change the app's theme automatically

Solution

  1. Step 1: Understand what protected routes do

    Protected routes restrict access to certain pages so only authorized users can see them.
  2. Step 2: Connect with Supabase session usage

    Supabase sessions help check if a user is logged in, enabling route protection.
  3. Final Answer:

    To allow only logged-in users to access certain pages -> Option A
  4. Quick Check:

    Protected routes = restrict access to logged-in users [OK]
Hint: Protected routes block access unless user is logged in [OK]
Common Mistakes:
  • Thinking protected routes speed up loading
  • Confusing route protection with data storage
  • Assuming protected routes change app appearance
2. Which of the following is the correct way to check if a user is logged in using Supabase in frontend code?
easy
A. const user = supabase.auth.getUser()
B. const user = supabase.session()
C. const user = supabase.auth.session()
D. const user = supabase.auth.getSession()

Solution

  1. Step 1: Identify Supabase method for session retrieval

    Supabase's current method to get session info is auth.getSession(), which returns user session data.
  2. Step 2: Compare options with official API

    Options A, B, and C are outdated or incorrect method names; only getSession() is valid.
  3. Final Answer:

    const user = supabase.auth.getSession() -> Option D
  4. Quick Check:

    Use auth.getSession() to check login [OK]
Hint: Use supabase.auth.getSession() to get current user session [OK]
Common Mistakes:
  • Using deprecated methods like auth.session()
  • Calling supabase.session() which does not exist
  • Confusing getUser() with getSession()
3. Given this React snippet using Supabase, what will happen if the user is not logged in?
const session = supabase.auth.getSession();
if (!session) {
  navigate('/login');
} else {
  showDashboard();
}
medium
A. The dashboard is shown regardless
B. An error is thrown because getSession() is async
C. The user is redirected to the login page
D. Nothing happens; the page stays the same

Solution

  1. 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.
  2. Step 2: Analyze the code flow

    A Promise object is truthy, so if (!session) evaluates to false, and showDashboard() executes regardless of login status.
  3. Final Answer:

    The dashboard is shown regardless -> Option A
  4. Quick Check:

    Async getSession() without await returns truthy Promise [OK]
Hint: Remember to await async getSession() calls [OK]
Common Mistakes:
  • Treating async getSession() as synchronous
  • Assuming session is null if user not logged in
  • Ignoring Promise returned by getSession()
4. You wrote this code to protect a route but it redirects even logged-in users to login:
const { data: session } = supabase.auth.getSession();
if (!session) {
  window.location.href = '/login';
}

What is the main issue?
medium
A. session is always truthy even if user is logged out
B. window.location.href cannot redirect pages
C. getSession() is asynchronous and must be awaited
D. You must use supabase.auth.getUser() instead

Solution

  1. Step 1: Check getSession() usage

    supabase.auth.getSession() returns a Promise and must be awaited or handled asynchronously to get session data.
  2. 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.
  3. Final Answer:

    getSession() is asynchronous and must be awaited -> Option C
  4. Quick Check:

    Always await async getSession() calls [OK]
Hint: Always await async Supabase calls to get real data [OK]
Common Mistakes:
  • Not awaiting async functions
  • Thinking window.location.href can't redirect
  • Using getUser() instead of getSession() incorrectly
5. You want to protect a React page so only logged-in users can see it. Which approach correctly implements this using Supabase's session and React hooks?
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>;
}
hard
A. The navigate call should be outside the async function
B. This code correctly protects the page by redirecting unauthenticated users
C. The code should call supabase.auth.getUser() instead of getSession()
D. The session state should be initialized with supabase.auth.getSession() synchronously

Solution

  1. Step 1: Analyze async session retrieval in useEffect

    The code correctly uses an async function inside useEffect to get the session and update state.
  2. Step 2: Check redirect logic for unauthenticated users

    If no session exists, the code calls navigate('/login') to redirect users, protecting the page.
  3. Step 3: Confirm loading state handling

    While session is null, it shows a loading message, preventing content flash before redirect.
  4. Final Answer:

    This code correctly protects the page by redirecting unauthenticated users -> Option B
  5. Quick Check:

    Async session check + redirect = protected route [OK]
Hint: Use async useEffect with redirect on no session [OK]
Common Mistakes:
  • Using getUser() instead of getSession() for session check
  • Calling navigate outside async context incorrectly
  • Initializing session state synchronously causing errors
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard