Documentation Index
Fetch the complete documentation index at: https://mintlify.com/danielpose1996-stack/ruedadeproyectos/llms.txt
Use this file to discover all available pages before exploring further.
Overview
RuedaPro UNIPAZ implements Row-Level Security (RLS) using Supabase’s PostgreSQL policies to control data access at the row level. This ensures that users can only access data appropriate to their role and authentication status.Authentication Roles
Supabase uses two built-in PostgreSQL roles for RLS policies:| Role | Description | Use Case |
|---|---|---|
anon | Unauthenticated users (public access) | Public ranking pages, guest browsing |
authenticated | Logged-in users | Admin, docente, and estudiante dashboards |
perfiles.rol column:
admin- System administratorsdocente- Faculty evaluatorsestudiante- Students
perfiles Table Policies
Theperfiles table contains user profile information. Access is controlled to balance functionality with privacy.
Policy 1: Authenticated Read Access
Policy Name:Authenticated read perfiles
Purpose: Allow logged-in users to view profile information for assignments and project management.
SQL Definition:
- Operation:
SELECTonly - Who: All authenticated users
- Access: Can read all profile records
- Rationale: Necessary for admins to manage users, docentes to see evaluator names, and students to view project team members
adminDashboardView.js:620-624:
Policy 2: Public Read for Evaluated Projects
Policy Name:Public read evaluated estudiantes
Purpose: Allow unauthenticated users to see student names only for projects that have been fully evaluated. This enables the public ranking page.
SQL Definition:
- Operation:
SELECTonly - Who: Unauthenticated users (
anon) - Access: Can only read profiles of students whose projects have
estado = 'Evaluado' - Privacy Protection: Students working on pending projects remain private until evaluation is complete
resultsView.js:79-91:
Security Implications
User Enumeration Protection
Public users cannot enumerate all student names or discover students with pending projects. Only completed evaluation results are publicly visible.
Role Verification
Always verify user roles server-side. The
perfiles.rol column is read-only for clients and must be set via Edge Functions or admin operations.evaluaciones Table Policies
Theevaluaciones table stores sensitive evaluation scores and feedback. Access must be carefully controlled.
Policy 3: Authenticated Read Access
Policy Name:Authenticated read evaluaciones
Purpose: Allow authenticated users (docentes, estudiantes, admins) to view evaluation records relevant to their role.
SQL Definition:
- Operation:
SELECTonly - Who: All authenticated users
- Access: Full read access to evaluation records
- Rationale:
- Docentes need to see their submitted evaluations
- Estudiantes need to view their project feedback
- Admins need oversight of the evaluation process
docenteDashboardView.js:156-171:
estudianteDashboardView.js:32-45:
Policy 4: Public Read for Evaluated Projects
Policy Name:Public read evaluated evaluaciones
Purpose: Allow unauthenticated users to view evaluation scores only for projects with estado = 'Evaluado'. Enables public ranking functionality.
SQL Definition:
- Operation:
SELECTonly - Who: Unauthenticated users (
anon) - Access: Can only read evaluations for projects marked as
'Evaluado' - Privacy Protection: In-progress evaluations and feedback remain hidden until all evaluators complete their work
resultsView.js:79-100:
Security Implications
Evaluator Independence
Evaluations remain hidden until all assigned evaluators submit their scores, preventing bias and maintaining independence of evaluation.
Feedback Privacy
Individual evaluator feedback (
observaciones) is visible to authenticated students but not to the public, maintaining appropriate privacy boundaries.proyectos Table Policies
The source SQL file (
rls_security_hardening.sql) does not explicitly define policies for the proyectos table. This suggests either:- Default public read access is allowed
- Policies are defined elsewhere in the Supabase configuration
- Access is controlled through related table policies
proyectos table.Recommended Policy: Public Read for Evaluated Projects
Junction Table Policies
The junction tables (proyecto_evaluadores and proyecto_estudiantes) should also implement RLS policies.
Recommended Policies
Write Operation Policies
Recommended Write Policies
Testing Security Policies
Test 1: Public Access to Pending Projects
Test 2: Authenticated Access to All Projects
Test 3: Public Access to Evaluated Projects
Test 4: Evaluator Cannot See Other Evaluators’ Details
Best Practices
Enable RLS on All Tables
Always enable RLS on all tables containing sensitive data. A table without RLS is accessible to anyone with the anon key.
Test Policies with Different Roles
Test RLS policies by switching between authenticated and anonymous contexts:
Use Service Role for Admin Operations
For admin operations (user creation, project deletion), use the service role key which bypasses RLS. Never expose the service role key to clients.From
adminDashboardView.js:372-379:Audit Policy Changes
Document all RLS policy changes and test thoroughly before deploying to production. Use version control for SQL migration files.
Minimize Public Data Exposure
Only expose the minimum data necessary for public features. Always default to restrictive policies and open up access as needed.
Common Pitfalls
Policy Audit Checklist
Pre-Deployment Security Checklist
Pre-Deployment Security Checklist
Before deploying RLS changes, verify:
- RLS is enabled on all tables with sensitive data
- All tables have explicit SELECT policies for both
anonandauthenticatedroles - Write operations (INSERT, UPDATE, DELETE) are restricted to appropriate roles
- Public access is limited to
estado = 'Evaluado'projects only - Junction table policies align with main table policies
- Service role operations are isolated to Edge Functions
- Policies have been tested with different user roles
- Policy changes are documented and version controlled
- No direct access to
perfilestable for role escalation - Evaluation submissions verify evaluator assignment before allowing INSERT
Additional Resources
For questions about implementing additional security policies or modifying existing ones, consult the Supabase documentation or contact your database administrator.