WeWeb User Roles and Permissions: RBAC Setup Guide

The Supabase Auth plugin in WeWeb requires two specific tables to power role-based access: a `roles` table and a `users_roles` join table. WeWeb generates these automatically. In the WeWeb editor: Plugins → Authentication → Supabase Auth → click the 'Generate' button. This creates: `public.roles` (columns: id UUID, name TEXT, label TEXT, created_at TIMESTAMPTZ) and `public.users_roles` (columns: id UUID, user_id UUID references auth.users, role_id UUID references roles). After generation, verify the tables exist: open Supabase Dashboard → Table Editor → confirm both tables are present. If you already had these tables from a previous project, the Generate button skips creation and links to existing ones. Now add your roles: in Supabase Dashboard → Table Editor → roles → + Insert row → add rows for each role your app needs (e.g., name: 'admin', label: 'Administrator'; name: 'member', label: 'Member'; name: 'editor', label: 'Editor').

To assign a role to a user, insert a row in the users_roles table linking the user's ID to the role's ID. In Supabase Dashboard → Table Editor → users_roles → + Insert row → user_id: paste the user's UUID (find it in Authentication → Users), role_id: paste the role's UUID (from the roles table). For assigning roles programmatically (e.g., assigning 'member' role on signup): create a Supabase Edge Function or a database trigger. The trigger approach runs entirely in Supabase without any WeWeb configuration: SQL editor → create function → create trigger on auth.users INSERT. Alternatively, in the WeWeb signup workflow, after the Sign up action, add a Supabase Database Insert action → table: users_roles → data: `{user_id: the-new-user-id, role_id: member-role-uuid}`. You can also assign roles through the WeWeb editor's user management interface if it appears in the Supabase Auth plugin settings — some plugin versions show a user list with role assignment controls.

1-- Injection point: Supabase SQL editor (run OUTSIDE WeWeb)
2-- Auto-assign 'member' role when a new user signs up
3-- This trigger runs in Supabase, not in WeWeb
4
5-- First, get the member role ID:
6-- SELECT id FROM public.roles WHERE name = 'member';
7-- Replace the UUID below with the actual member role ID
8
9CREATE OR REPLACE FUNCTION public.assign_default_role()
10RETURNS TRIGGER AS $$
11DECLARE
12  member_role_id UUID;
13BEGIN
14  SELECT id INTO member_role_id
15  FROM public.roles
16  WHERE name = 'member'
17  LIMIT 1;
18
19  IF member_role_id IS NOT NULL THEN
20    INSERT INTO public.users_roles (user_id, role_id)
21    VALUES (NEW.id, member_role_id);
22  END IF;
23
24  RETURN NEW;
25END;
26$$ LANGUAGE plpgsql SECURITY DEFINER;
27
28-- Attach trigger to auth.users table
29CREATE TRIGGER on_auth_user_created
30  AFTER INSERT ON auth.users
31  FOR EACH ROW
32  EXECUTE FUNCTION public.assign_default_role();

WeWeb's User Groups translate backend roles into page-level access conditions. In the WeWeb editor: Plugins → Authentication → Supabase Auth → scroll to the User Groups section → + Add User Group. Name the group (e.g., 'Admins', 'Members', 'Editors'). In the group configuration, select which roles a user must have. IMPORTANT: User Groups use AND logic — a user must have ALL roles in the group to qualify. If your 'Super Admin' group requires both 'admin' AND 'editor' roles, only users with both roles qualify. For OR logic (admin OR editor can access), create separate groups for each role and assign both groups to the page. Create a group for each role combination you need for page access. Common setup: Group 'Admins' → requires role 'admin'. Group 'Members' → requires role 'member'. Group 'All Authenticated' → leave roles empty (any logged-in user qualifies). After creating groups, they appear in Page settings → Access control as options for page restriction.

WARNING: Page-level access restriction in WeWeb requires the Scale plan. On lower plans, this setting is available in the UI but does not enforce access — all pages remain accessible. With a Scale plan: select the page you want to restrict in the Pages panel → Page settings panel (right sidebar) → Access control section. Change 'Everybody' to the User Group(s) that should have access. Users not in any of the selected groups are automatically redirected to the page you set as 'Default page for unauthenticated users' in the Supabase Auth plugin settings. For multi-role scenarios: you can select multiple User Groups for a page — users in ANY of the selected groups can access it (OR logic at the page level). The AND logic applies within a single group. Also set the login redirect: if a non-authenticated user tries to access a protected page, they should land on the login page, not a 404. Verify the 'Default redirect for unauthenticated users' in the plugin settings points to your login page.

Beyond page-level restrictions, you often need to conditionally show UI elements within a page based on role — an admin action button, a billing section visible only to plan owners, or a 'Delete' control only for moderators. Use Conditional Rendering for this. Select the element → Settings panel → Conditional Rendering → click the plug icon → write a role-check formula. With Supabase Auth: `wwContext.user?.roles?.some(r => r.name === 'admin')`. This shows the element only for users who have the 'admin' role in their roles array. For multiple roles: `wwContext.user?.roles?.some(r => ['admin', 'moderator'].includes(r.name))`. For the inverse (hide from admins): `!wwContext.user?.roles?.some(r => r.name === 'admin')`. The roles array on wwContext.user is populated from the users_roles join table — this is why running 'Generate' in the plugin settings is important. SECURITY REMINDER: Conditional rendering hides elements from view but does not prevent API calls. Never put sensitive data in the frontend that non-admin users should never see — enforce data access in RLS.

OUTSIDE WEWEB — in Supabase Dashboard: this is the critical security layer. Even if WeWeb restricts pages and hides elements, RLS policies ensure that database operations are authorized regardless of the client. Go to Supabase Dashboard → Table Editor → select a table → click 'RLS Policies' → + New Policy. For a table that admins can read all rows but regular users can only read their own: create two policies. Policy 1 (admin full access): `CREATE POLICY 'Admins can read all' ON public.your_table FOR SELECT USING (EXISTS (SELECT 1 FROM public.users_roles ur JOIN public.roles r ON ur.role_id = r.id WHERE ur.user_id = auth.uid() AND r.name = 'admin'))`. Policy 2 (users read own data): `CREATE POLICY 'Users read own' ON public.your_table FOR SELECT USING (user_id = auth.uid())`. Supabase applies both policies with OR logic — a row is returned if the user matches ANY policy. Run these in Supabase Dashboard → SQL editor. Test your policies using the Supabase Dashboard's Policy tester by simulating requests as different user IDs.

1-- Injection point: Supabase SQL editor (run OUTSIDE WeWeb)
2-- Example RLS policies for a 'posts' table with admin and author roles
3
4ALTER TABLE public.posts ENABLE ROW LEVEL SECURITY;
5
6-- All authenticated users can read published posts
7CREATE POLICY "Read published posts"
8  ON public.posts FOR SELECT
9  USING (
10    status = 'published'
11    OR user_id = auth.uid()
12    OR EXISTS (
13      SELECT 1 FROM public.users_roles ur
14      JOIN public.roles r ON ur.role_id = r.id
15      WHERE ur.user_id = auth.uid()
16      AND r.name IN ('admin', 'editor')
17    )
18  );
19
20-- Only the post author can insert their own posts
21CREATE POLICY "Authors can insert own posts"
22  ON public.posts FOR INSERT
23  WITH CHECK (user_id = auth.uid());
24
25-- Authors can update their own posts; admins can update any
26CREATE POLICY "Authors and admins can update"
27  ON public.posts FOR UPDATE
28  USING (
29    user_id = auth.uid()
30    OR EXISTS (
31      SELECT 1 FROM public.users_roles ur
32      JOIN public.roles r ON ur.role_id = r.id
33      WHERE ur.user_id = auth.uid()
34      AND r.name = 'admin'
35    )
36  );
37
38-- Only admins can delete any post
39CREATE POLICY "Only admins can delete"
40  ON public.posts FOR DELETE
41  USING (
42    EXISTS (
43      SELECT 1 FROM public.users_roles ur
44      JOIN public.roles r ON ur.role_id = r.id
45      WHERE ur.user_id = auth.uid()
46      AND r.name = 'admin'
47    )
48  );

Systematic testing prevents security gaps. Test each scenario explicitly: (1) Not logged in: navigate directly to each protected page URL — confirm you are redirected to login. (2) Logged in as 'member' role: navigate to admin-only pages — confirm redirect. Open browser dev tools → Network tab → look for Supabase API calls → confirm they return 0 rows or 403 errors for data you should not have access to. (3) Logged in as 'admin' role: navigate to admin pages — confirm access works. Confirm admin-only UI elements are visible. (4) Try a direct API call bypassing the UI: open browser dev tools → Console → run `fetch('https://your-project.supabase.co/rest/v1/your_table', {headers: {'apikey': 'your-anon-key', 'Authorization': 'Bearer your-non-admin-token'}}).then(r => r.json()).then(console.log)`. The response should only contain rows the non-admin user is authorized to see. If it returns all rows, your RLS policy has a gap. Also test role changes: assign a new role to a test user, log out, log back in, and verify the new access is reflected in wwContext.user.roles.