Admin vs user route protection in Express - Visual Side-by-Side Comparison

Concept Flow - Admin vs user route protection

Request comes in

↓

Check if user is logged in

Yes↓

Check user role

↓

Allow admin

↓

Access route

↓

Response

↓

End

When a request arrives, the server checks if the user is logged in, then checks their role. Depending on role (admin or user), access to routes is allowed or denied.

Execution Sample

Express

app.get('/admin', checkAuth, checkAdmin, (req, res) => {
  res.send('Welcome Admin');
});

This code protects the '/admin' route so only logged-in admins can access it.

Execution Table

Step	Request URL	User Logged In?	User Role	Middleware Action	Route Access	Response
1	/admin	No	-	checkAuth blocks	No	Redirect to login
2	/admin	Yes	user	checkAdmin blocks	No	403 Forbidden
3	/admin	Yes	admin	Passes all checks	Yes	Welcome Admin
4	/user	No	-	checkAuth blocks	No	Redirect to login
5	/user	Yes	user	Passes all checks	Yes	Welcome User
6	/user	Yes	admin	Passes all checks	Yes	Welcome User
7	/admin	Yes	guest	checkAdmin blocks	No	403 Forbidden

💡 Execution stops when middleware blocks access or route handler sends response.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7
User Logged In	false	false	true	true	false	true	true	true
User Role	undefined	undefined	user	admin	undefined	user	admin	guest
Route Access	none	no	no	yes	no	yes	yes	no
Response	none	redirect	403	Welcome Admin	redirect	Welcome User	Welcome User	403

Key Moments - 3 Insights

Why does the admin route block access for a logged-in user with role 'user'?

Because the checkAdmin middleware specifically checks for 'admin' role and blocks others, as shown in execution_table row 2.

Why can an admin access the user route?

User route only requires login, not specific role, so admin passes checks and accesses route (execution_table row 6).

What happens if a user is not logged in?

The checkAuth middleware blocks access and redirects to login, as seen in rows 1 and 4.

Visual Quiz - 3 Questions

Look at the execution table, what is the response at step 3 when an admin accesses '/admin'?

A Welcome Admin

B 403 Forbidden

C Redirect to login

D Welcome User

💡 Hint

Check the 'Response' column at step 3 in the execution_table.

At which step does the middleware block a logged-in user with role 'user' from accessing '/admin'?

A Step 1

B Step 2

C Step 5

D Step 6

💡 Hint

Look for 'User Role' = 'user' and 'Route Access' = 'No' in execution_table.

If the checkAdmin middleware was removed, what would happen at step 2?

A User would be redirected to login

B User would get 403 Forbidden

C User would access the admin route

D User would get a server error

💡 Hint

Without checkAdmin, only checkAuth runs, so role is not checked (see execution_table logic).

Concept Snapshot

Protect routes by checking if user is logged in and their role.
Use middleware functions: checkAuth for login, checkAdmin for admin role.
If checks fail, block access with redirect or 403.
Admin routes require admin role; user routes require login only.
Middleware runs before route handler to control access.

Full Transcript

When a request arrives at the server, it first checks if the user is logged in using checkAuth middleware. If not logged in, the user is redirected to login. If logged in, the server checks the user's role. For admin routes, checkAdmin middleware ensures the user has the admin role. If the user is not an admin, access is blocked with a 403 Forbidden response. For user routes, only login is required, so any logged-in user can access. This layered check protects routes based on user roles. The execution table shows different scenarios: not logged in users get redirected, logged-in users with wrong roles get blocked, and correct roles get access. Variables like user login status and role change as requests are processed. This method keeps admin routes secure and user routes accessible to all logged-in users.