Row-Level Security (RLS) Policies
The Tuturuuu platform implements comprehensive Row-Level Security (RLS) policies to enforce workspace-based multi-tenancy and granular permission controls.Security Model Overview
Core Principles
- Workspace Isolation: All workspace-scoped resources are isolated via RLS policies
- Permission-Based Access: Actions require specific workspace role permissions
- User Ownership: Users can only access resources they own or have permission to view
- Fail-Secure Default: No access unless explicitly granted by policy
Architecture
Policy Patterns
Pattern 1: Workspace Membership Check
Use Case: User must be a member of the workspace to access resources. Example:workspace_tasks
SELECT policy
auth.uid()
: Gets the authenticated user’s ID- Subquery checks
workspace_members
table - Returns only rows matching user’s workspaces
Pattern 2: Permission-Based Access
Use Case: User needs specific workspace permission to perform action. Example: Task UPDATE policymanage_infrastructure_settings
manage_workspace_settings
manage_workspace_security
manage_users
manage_user_groups
manage_user_roles
manage_finance
manage_calendar
manage_documents
manage_inventory
ai_lab_assistant
view_disabled_users
disable_user
Pattern 3: User Ownership
Use Case: User can only access resources they created. Example:notes
policies
Pattern 4: Combined Workspace + Permission
Use Case: Workspace membership AND specific permission required. Example: Calendar event managementPattern 5: Public Read, Restricted Write
Use Case: All workspace members can view, only privileged users can modify. Example: Workspace settingsPattern 6: Cross-Table Permission Inheritance
Use Case: Permission check depends on related table’s policies. Example: Task project members inherit from project permissionsCommon RLS Helpers
Get User Workspaces
Check Workspace Permission
Policy Testing
Enable RLS (Always Required)
Test Policy as User
Verify Policy Coverage
Security Best Practices
1. Always Enable RLS
2. Use SECURITY DEFINER Carefully
Only useSECURITY DEFINER
for helper functions that need elevated privileges:
3. Test Policies Thoroughly
Always test:- ✅ Users can access their own data
- ✅ Users cannot access other workspaces’ data
- ✅ Permission checks work correctly
- ✅ Edge cases (pending invites, disabled users)
4. Avoid Policy Conflicts
5. Performance Considerations
Common Policy Patterns by Table Type
Workspace-Scoped Resources
User-Owned Resources
Public Read Resources
Debugging RLS Issues
Check Active Policies
Test as Specific User
Bypass RLS for Admin Operations
UsecreateAdminClient()
from @tuturuuu/supabase
in server-side code: