socorrist.app
Errores comunes y cómo se arreglan
Cada uno explicado en cristiano: qué significa, por qué te pasa, qué no significa y cómo arreglarlo tú mismo. Sin registrarte y sin pagar nada.
Tu app no funciona
Algo se ha roto y lo estás viendo. Suelen tener arreglo en minutos.
- supabaseUrl is requiredTu app está intentando conectarse a Supabase, pero no sabe a qué proyecto. La dirección llega vacía, y la librería de Supabase se para antes de intentarlo siquiera.
- Failed to fetchTu app ha intentado pedir datos a algún sitio y la petición no ha llegado a completarse. El navegador no te dice por qué a propósito: este mensaje es deliberadamente vago por motivos de seguridad, y por eso desespera tanto.
- new row violates row-level security policySupabase ha rechazado guardar una fila. La tabla tiene activada la seguridad por filas, que es lo correcto, pero no hay ninguna regla que diga quién puede escribir en ella. Cuando no hay regla, la respuesta por defecto es que no.
- Pantalla en blanco en producciónTu app se ha publicado, el servidor responde, pero el navegador pinta una página vacía. Casi siempre significa que el JavaScript ha fallado nada más arrancar y se ha parado antes de dibujar nada.
- Missing Supabase environment variablesAlguien puso en tu app una comprobación al arrancar: si no están la dirección y la clave de Supabase, para y avisa. Eso es lo que ha pasado. Y es buena noticia, porque este mensaje es mucho más claro que el que saldría sin esa comprobación.
- Invalid API keyLa petición ha llegado a Supabase, que la ha mirado y ha dicho que no. A diferencia de otros errores, aquí la conexión funciona: lo que no le vale es la credencial que le estás enseñando.
- 403 (Forbidden) en /rest/v1/Supabase ha entendido la petición y sabe quién la hace. Simplemente ha decidido que quien la hace no tiene permiso para ver eso. Si además ves un mensaje que dice permission denied for table, es exactamente lo mismo dicho con otras palabras.
- Auth session missing!Tu app le ha pedido a Supabase los datos del usuario que ha iniciado sesión, y en ese momento no había ninguna sesión abierta. Ojo al matiz: dice que no la hay ahora, no que el usuario no haya entrado nunca.
- La IA no arregla el bug y da vueltas en círculoLe pides que lo arregle, dice que ya está, pruebas y falla igual. Le pasas el error nuevo, cambia otra cosa, y aparece un tercer fallo que antes no existía. No es que lo estés pidiendo mal ni que la herramienta sea mala: es que el agente ya no está resolviendo tu problema, está persiguiendo mensajes de error.
- Environment variable not foundTu app necesita un dato de configuración (una dirección, una clave, un identificador) y ha ido a buscarlo donde debería estar guardado. No estaba. Se para ahí, antes de intentar nada más.
- Deploy failedTu app no ha llegado a publicarse. El servidor intentó construirla, algo se torció por el camino y abortó. La buena noticia inmediata: la versión anterior sigue publicada y funcionando, porque estas plataformas no tiran lo que hay hasta que lo nuevo está listo.
- 500 Internal Server ErrorEl servidor ha recibido la petición, ha intentado responder y se ha caído por el camino. El 500 es el navegador diciéndote que el fallo está del lado del servidor, no en tu conexión ni en tu navegador. Lo que no te dice es cuál, y eso es deliberado: contar los detalles de un error de servidor al visitante sería un problema de seguridad.
- Cannot read properties of undefinedTu código ha intentado leer algo dentro de una caja y la caja no existe. El mensaje suele terminar con el nombre de lo que buscaba: si dice que no puede leer nombre de undefined, tu código pedía el nombre de algo que no había llegado.
- Something went wrongEsto no es el error: es la red de seguridad. Tu app tiene una pantalla preparada para cuando algo falla, para que el visitante no vea una página en blanco ni un mensaje técnico. Ha saltado, así que algo ha fallado por debajo. El mensaje de verdad sigue existiendo, solo que está tapado por esta pantalla.
- El login funciona en el preview pero no en mi dominioTu inicio de sesión no está roto: está protegido. Supabase, y cualquier proveedor de login, solo acepta devolver al usuario a direcciones que tú has declarado de antemano. Tu dominio nuevo no está en esa lista, así que el proceso se corta justo en el momento de volver.
- Stripe webhook 401Cuando alguien te paga, Stripe llama a tu app para avisarla. Tu app está contestando que no está autorizado a hablar, y Stripe se da por vencido. El dinero ha entrado y está en tu cuenta de Stripe; lo que no ha pasado es todo lo que tu app hacía después: dar de alta al cliente, activar su acceso, mandarle el correo.
Tu app funciona, y ese es el problema
Fugas de datos que no dan ningún error: solo se ven si alguien mira.
- La clave service_role de Supabase está en el código públicoSupabase te da dos llaves. Una es pública y va en el navegador a propósito. La otra, la service_role, se salta todas las reglas de seguridad de tu base de datos y solo debe vivir en un servidor. La segunda ha acabado dentro del código que se descarga cualquiera que visite tu web.
- Tengo tablas sin RLS: cualquiera puede leerlasEn Supabase, la clave pública de tu app va en el navegador a propósito, y cualquiera puede leerla. Lo que impide que esa clave sirva para descargarse tus tablas enteras son las políticas de seguridad por filas. Si una tabla no las tiene activadas, esa protección no existe y la tabla está abierta a quien pregunte.
- Política USING (true): acceso abierto a todoTu tabla tiene la seguridad por filas activada, así que el panel de Supabase la da por protegida. Pero la política que la gobierna dice, literalmente, que la condición para acceder es verdadera. O sea: que sí, siempre, a quien sea.
- Puse el prefijo VITE_ o NEXT_PUBLIC_ a un secreto y se publicóEsos prefijos no son un formalismo del nombre: son una instrucción. Le dicen a la herramienta que construye tu app que esa variable debe copiarse dentro del código que se descarga el navegador. Ponerle ese prefijo a un secreto es, literalmente, pedir que se publique.
- Mi clave de Stripe está en el código públicoStripe te da dos claves y solo una de ellas es un secreto. La publicable, que empieza por pk_, va en el navegador a propósito para que funcione el formulario de pago. La secreta, que empieza por sk_, permite cobrar, devolver dinero y leer los datos de tus clientes. Si la que está en tu código empieza por sk_, ese es el problema.
- Mi clave de OpenAI o de otro proveedor de IA está expuestaLa clave que usa tu app para hablar con OpenAI, Anthropic o el proveedor que sea está dentro del código que se descarga cualquiera que visite tu web. Esa clave no protege datos: autoriza gasto contra tu tarjeta.
- Mis source maps son públicos: se ve todo mi códigoAl construir tu app, el código se comprime hasta quedar ilegible. Los source maps son unos ficheros que deshacen esa compresión para poder depurar, y contienen tu código tal y como lo escribiste, con nombres y comentarios. Se han publicado junto a la app, así que cualquiera puede descargarlos y leerlo entero.
- La lógica de permisos deja entrar a quien no debeTu app decide quién puede ver o hacer cada cosa en el código que corre en el navegador del visitante. El problema es que ese código está en su ordenador, no en el tuyo: puede leerlo, cambiarlo y saltárselo. Ocultar un botón no impide la acción que había detrás.