How to Add User Roles and Permissions

Overview

Roles decide what a signed-in user is allowed to do. Where you store them determines whether they can be faked.

Beginner explanation: If a user can edit their own profile, and their role lives on their profile, they can make themselves an admin. That is the whole problem.

Technical explanation: Store roles in a dedicated table keyed by user, and check them through a security-definer function used inside your access rules. Never read a role from client-side storage.

Steps

1. Create a roles table with a user reference and a role value.
2. Create a function that checks whether a user has a role.
3. Use that function inside your access rules.
4. Add an admin-only area that calls the same check server-side.
5. Test with a non-admin account.

:::tip Check the role again inside every privileged server action. A hidden menu item is not a permission system. :::

What to check afterwards

• A normal user cannot reach admin pages or admin data
• Role changes take effect on the next request
• Privileged actions fail cleanly for non-admins

Common problems

• A role column on the profiles table. Users can usually edit their own profile.
• Role stored in browser storage. Trivially edited.
• UI-only checks. The endpoint stays open.

Where people get stuck

If you have followed the steps and the result still is not right, the fastest path is usually to describe the exact behaviour you expected, the behaviour you got, and any error text, then ask for a fix in one focused follow-up prompt. If that loop is not converging, hand it over.