Role-based access

Each user has roles, each route or operation requires one, and a check in one place enforces it. Keep the rule next to the operation it protects, and deny by default.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain roles, permissions and deny by default
Protect a route with a role check in one place
Spot the role check without an ownership check

In practice

A few lines that show Role-based access doing its job.

JavaScript

function requireRole(...roles) {
  return async (req, reply) => {
    if (!req.user) return reply.code(401).send({ error: "sign in" });
    if (!roles.includes(req.user.role)) return reply.code(403).send({ error: "not allowed" });
  };
}

app.delete("/users/:id", { preHandler: requireRole("admin") }, deleteUser);
app.get("/orders/:id", { preHandler: requireOwnerOrRole("admin") }, getOrder);

The common mistake

Watch for

Checking the role but not ownership. A logged-in customer who can GET /orders/:id for any id can read every other customer's orders. Most resources need both checks.

What to know first

Your roadmap puts these before Role-based access, unless you already know them.

How it stays learned

Once a session shows you understand Role-based access, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Next in the moduleInput sanitisation →