Cursor prompt to add role-based access control
Retrofit role checks onto an API you already have instead of rebuilding auth from scratch. This prompt tells Cursor's agent to read your existing middleware before writing anything, so the guard reuses your session parsing. You finish with a roles module, a migration defaulting old users to viewer, and 403 tests for every role.
Last updated
Add role-based access control to the existing API in this repo. Read the current auth middleware first and reuse its session or token parsing, do not build a second auth path. Define three roles, admin, editor, and viewer, in a single roles module, and add a requireRole guard that returns 403 with a JSON error body when the check fails and never reveals whether the {{resource}} exists. Apply the guard so viewers get read-only access, editors can write, and only admins reach delete and user management routes. Store the role on the user record in {{database}} with a migration that defaults existing users to viewer. Write tests covering each role against one read, one write, and one delete route, run the full suite in the terminal, and show me the diff per file before I accept.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Add role-based access control to the existing API in this repo. Read the current auth middleware first and reuse its session or token parsing, do not build a second auth path. Define three roles, admin, editor, and viewer, in a single roles module, and add a requireRole guard that returns 403 with a JSON error body when the check fails and never reveals whether the users exists. Apply the guard so viewers get read-only access, editors can write, and only admins reach delete and user management routes. Store the role on the user record in PostgreSQL with a migration that defaults existing users to viewer. Write tests covering each role against one read, one write, and one delete route, run the full suite in the terminal, and show me the diff per file before I accept.
Questions about this prompt
Will the agent find my existing auth middleware on its own?
Usually, but not reliably in larger repos. @-mention the middleware file directly in the prompt so the guard reuses your token parsing instead of a stale helper that codebase search happened to surface first.
How do I extend this beyond three roles?
Because roles are centralized in one module, ask for a follow-up edit there rather than starting a new prompt. If you need per-action granularity, have the agent replace requireRole with requirePermission and map each role to a permission set in the same file.
What is the most common gap after the agent finishes?
Routes that never received the guard. Ask the agent to grep the route registrations and print a table of route versus required role, then spot check the delete and admin rows before accepting the diffs.