Resultado visible
Seguirás una solicitud desde el navegador hasta Postgres y distinguirás validación, red, permisos y política. No usarás una clave con bypass de RLS para «hacer que funcione».
Estado roto
En un proyecto de prueba habilita RLS en contact_requests sin crear política de inserción para el rol que usa el formulario. Envía datos ficticios y registra status HTTP, respuesta segura y filas existentes desde un entorno administrativo.
Diagnóstico por capas
- ¿El navegador envió la solicitud una sola vez?
- ¿La ruta de servidor recibió y validó el cuerpo?
- ¿Qué rol o usuario llega a la base?
- ¿RLS está activa y existe
INSERT ... WITH CHECKpara ese rol? - ¿La aplicación transforma el error en un mensaje recuperable?
Prompt de corrección
Diagnostica el formulario sin desactivar RLS y sin usar service_role como
atajo. Traza navegador, route handler, cliente Supabase, rol y policy.
Propón la política mínima para insertar los campos permitidos y ninguna
política pública de lectura. Valida en servidor y limita frecuencia.
Prueba: inserción válida, inválida, lectura anónima, update y delete.
La inserción debe funcionar; las otras operaciones deben denegarse.
Una clave administrativa que evita RLS se reserva para tareas administrativas de servidor, con alcance explícito; nunca aparece en el navegador. Un array vacío al seleccionar puede ser precisamente el resultado correcto de una política que no permite ver filas.
Verificación y restauración
Confirma una fila de prueba, ausencia de lectura pública y mensajes claros. Bórrala mediante el procedimiento administrativo documentado. Revierte la policy rota, no la protección.
Fuentes oficiales
Si has guardado la evidencia de esta lección, continúa con «Laboratorio: mide y optimiza una política RLS». Si no, repite la comprobación antes de avanzar.