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.

Practice

1. What is the main purpose of using middleware for admin vs user route protection in Express?

easy

A. To check user roles and allow or deny access accordingly

B. To speed up the server response time

C. To log every request made to the server

D. To change the URL of the route dynamically

Solution

1. Step 1: Understand middleware role

   Middleware runs before route handlers and can check conditions like user roles.

2. Step 2: Role-based access control

   Middleware can allow access only if the user has the right role, such as admin or user.

3. Final Answer:

   To check user roles and allow or deny access accordingly -> Option A

4. Quick Check:

   Middleware controls access = D [OK]

Hint: Middleware checks roles to protect routes [OK]

Common Mistakes:

• Thinking middleware speeds up server
• Confusing middleware with logging only
• Believing middleware changes URLs

2. Which of the following is the correct way to apply middleware for admin route protection in Express?

easy

A. app.get('/admin', (req, res) => adminMiddleware, res.send('Admin page'));

B. app.get('/admin', adminMiddleware, (req, res) => { res.send('Admin page'); });

C. app.use('/admin', (req, res) => { adminMiddleware(); res.send('Admin page'); });

D. app.get('/admin', (req, res) => { res.send('Admin page'); adminMiddleware(); });

Solution

1. Step 1: Understand middleware placement

   Middleware should be passed as a second argument before the route handler function.

2. Step 2: Check syntax correctness

   app.get('/admin', adminMiddleware, (req, res) => { res.send('Admin page'); }); correctly places adminMiddleware between route path and handler.

3. Final Answer:

   app.get('/admin', adminMiddleware, (req, res) => { res.send('Admin page'); }); -> Option B

4. Quick Check:

   Middleware before handler = A [OK]

Hint: Middleware goes between path and handler in route [OK]

Common Mistakes:

• Calling middleware inside handler instead of passing it
• Using middleware after sending response
• Passing middleware as a function call instead of reference

3. Given this middleware and route code, what will be the response if a user with role 'user' tries to access '/admin'?

function adminMiddleware(req, res, next) {
  if (req.user.role === 'admin') next();
  else res.status(403).send('Access denied');
}
app.get('/admin', adminMiddleware, (req, res) => {
  res.send('Welcome Admin');
});

medium

A. 'Access denied' with status 403

B. 'Welcome Admin'

C. Server error due to missing next()

D. Empty response with status 200

Solution

1. Step 1: Analyze middleware condition

   The middleware checks if req.user.role is 'admin'. If not, it sends 403 with 'Access denied'.

2. Step 2: User role is 'user'

   Since role is 'user', the else branch runs, sending 403 and 'Access denied'.

3. Final Answer:

   'Access denied' with status 403 -> Option A

4. Quick Check:

   Non-admin blocked with 403 = A [OK]

Hint: Check role condition in middleware to predict response [OK]

Common Mistakes:

• Assuming next() always runs
• Ignoring status code sent by middleware
• Thinking response is 'Welcome Admin' for all roles

4. Identify the error in this Express route protection code:

function adminMiddleware(req, res, next) {
  if (req.user.role === 'admin') next();
  else res.send('Access denied');
}
app.get('/admin', adminMiddleware, (req, res) => {
  res.send('Admin area');
});

medium

A. Route handler should be before middleware

B. Middleware should not call next()

C. Missing status code when sending 'Access denied'

D. req.user.role check is incorrect syntax

Solution

1. Step 1: Check middleware response

   When denying access, middleware sends a message but does not set HTTP status code.

2. Step 2: Importance of status code

   Without status 403, client gets status 200 which is misleading for access denial.

3. Final Answer:

   Missing status code when sending 'Access denied' -> Option C

4. Quick Check:

   Send 403 on denial = C [OK]

Hint: Always send status code with error messages [OK]

Common Mistakes:

• Not setting status code on error
• Calling next() after sending response
• Placing middleware after route handler

5. You want to protect two routes: '/admin' for admins only and '/profile' for logged-in users. Which Express setup correctly applies middleware for this scenario?

function authMiddleware(req, res, next) {
  if (req.user) next();
  else res.status(401).send('Login required');
}
function adminMiddleware(req, res, next) {
  if (req.user?.role === 'admin') next();
  else res.status(403).send('Admin only');
}
// Which setup is correct?

hard

A. app.get('/admin', adminMiddleware, authMiddleware, (req, res) => res.send('Admin')); app.get('/profile', adminMiddleware, (req, res) => res.send('Profile'));

B. app.get('/admin', (req, res) => res.send('Admin')); app.get('/profile', authMiddleware, (req, res) => res.send('Profile'));

C. app.get('/admin', authMiddleware, (req, res) => res.send('Admin')); app.get('/profile', adminMiddleware, (req, res) => res.send('Profile'));

D. app.get('/admin', authMiddleware, adminMiddleware, (req, res) => res.send('Admin')); app.get('/profile', authMiddleware, (req, res) => res.send('Profile'));

Solution

1. Step 1: Understand middleware order

   For '/admin', user must be logged in (authMiddleware) and have admin role (adminMiddleware).

2. Step 2: Apply correct middleware per route

   '/profile' only needs authMiddleware to check login. app.get('/admin', authMiddleware, adminMiddleware, (req, res) => res.send('Admin')); app.get('/profile', authMiddleware, (req, res) => res.send('Profile')); applies both correctly in order.

3. Final Answer:

   app.get('/admin', authMiddleware, adminMiddleware, (req, res) => res.send('Admin')); app.get('/profile', authMiddleware, (req, res) => res.send('Profile')); -> Option D

4. Quick Check:

   Auth then admin for admin route = B [OK]

Hint: Check middleware order: auth before admin [OK]

Common Mistakes:

• Reversing middleware order
• Using adminMiddleware alone for profile
• Not protecting admin route with authMiddleware