Qué ocurre con las URL de localhost en la vista previa de un reto de código

El frontend de un proyecto suele llamar a su API en http://localhost:4000, desde un archivo de entorno como NEXT_PUBLIC_API_URL o escrito directamente en el código. En una vista previa de Kendor, la página se ejecuta en el navegador de quien la ve, donde localhost es su propio ordenador, no el sandbox. Kendor redirige esas llamadas al puerto correcto del sandbox, así que la mayoría de los proyectos funcionan sin cambios. Este artículo explica qué se redirige, qué no, y la forma explícita de construir URL cuando prefieres no depender de ello.

Qué redirige Kendor

Cualquier URL cuyo host sea localhost, 127.0.0.1, 0.0.0.0 o [::1], en cualquier puerto, hecha desde la página de la vista previa o desde sus web workers:

• peticiones con fetch y XMLHttpRequest (y, por tanto, axios y la mayoría de las demás librerías HTTP)
• WebSockets, incluidos socket.io y la recarga en caliente, y eventos enviados por el servidor (EventSource)
• imágenes, scripts, hojas de estilo, vídeo, iframes, enlaces y formularios, ya estén en el HTML servido, se definan desde JavaScript o se inserten como marcado
• redirecciones de tu servidor a http://localhost:…

Da igual de dónde venga la URL: una variable de entorno incluida en el bundle, una cadena escrita directamente o una construida en tiempo de ejecución.

Adónde va una URL redirigida

• Si el routing del reto envía esa ruta a ese puerto, la URL va a la propia dirección de la vista previa. Por ejemplo, http://localhost:4000/api/users va a https://<preview-address>/api/users cuando /api enruta al servicio del puerto 4000. Así, el frontend y la API comparten una sola dirección y no hay CORS en absoluto.
• En caso contrario, va a la dirección propia de ese puerto, https://4000-<preview-address>/api/users, la misma dirección que abre la vista Procesos para ese puerto.

La primera vez que se redirige un puerto, la consola del navegador lo indica:

[kendor] localhost:4000 is the sandbox's port 4000 here, reached at https://4000-<preview-address>.

CORS, redirecciones y cookies

Una llamada desde la vista previa a la dirección de otro puerto es de origen cruzado, así que Kendor hace que se vea como en tu máquina:

• CORS. Tu API recibe Origin: http://localhost:3000 (el puerto desde el que vino la página), de modo que una lista de permitidos escrita para el desarrollo local pasa. Su respuesta se traduce de vuelta a la dirección de la vista previa. Solo las llamadas desde la propia vista previa del reto reciben este trato; las peticiones de cualquier otro sitio se dejan tal cual.
• Redirecciones. Una cabecera Location: http://localhost:3000/dashboard se reescribe a la dirección de la vista previa.
• Cookies. La vista previa se muestra dentro del editor, en otro sitio, donde los navegadores descartan las cookies normales. Kendor marca las cookies de tu aplicación como particionadas (SameSite=None; Secure; Partitioned), así que un inicio de sesión con cookie también funciona ahí. A una cookie con Domain=localhost se le quita ese dominio.

El código del lado del servidor no necesita nada de esto. Dentro del sandbox, localhost ya llega al proceso correcto, así que un componente de servidor de Next.js o una API que llama a otro servicio en http://localhost:4000 funciona igual que en tu máquina.

Qué no se redirige

• Un url() de CSS que apunta a localhost, como background: url(http://localhost:4000/bg.png).
• Workers creados desde un blob o una URL de datos, en lugar de desde un archivo de script.
• La navegación de página establecida en el código, como location.href = 'http://localhost:3000/login', en Firefox. Chrome, Edge y Safari sí están cubiertos.
• URL de callback de OAuth registradas con un proveedor como Google o GitHub como localhost. Actualízalas en el proveedor o inicia sesión de otra forma con una cuenta de prueba.
• Un servidor que escucha solo en 127.0.0.1. La vista previa no puede alcanzarlo en absoluto. Haz que escuche en $HOST (0.0.0.0).

Cuando la página sigue cargando algo desde localhost, la consola del navegador indica qué URL:

[kendor] This page loaded http://localhost:4000/bg.png (css). That address is the viewer's own
computer, not the sandbox, and Kendor couldn't redirect this one.

Chrome también puede pedir a quien ve la página permiso para acceder a su red local. Ambos avisos significan lo mismo: cambia esa URL como se describe a continuación.

La forma explícita

En lugar de depender de la redirección, puedes darle tú mismo al navegador la dirección correcta. Ambas formas funcionan en el sandbox y en tu máquina.

• Una ruta relativa. Con routing enviando /api a tu API, llama a fetch('/api/users'). El frontend y la API comparten la dirección de la vista previa. Consulta aplicaciones con varios servicios.
• Una referencia en dev.env.vars. Define la variable de API de tu frontend con la URL pública de la API:

services:
  web:
    dev:
      command: npm run dev -- --port $PORT
      port: 5173
      env:
        vars:
          VITE_API_URL: routing.api.url

routing.api.url se resuelve en la dirección de la vista previa más la ruta de la API, antes de que arranque ningún servicio.

Cada comando de desarrollo también recibe KENDOR_PUBLIC_HOST, el nombre de host de la vista previa, para el código que construye URL por su cuenta. La dirección propia de un puerto es ese host con <port>- delante.

Cómo desactivarlo

Si tu aplicación asigna sus propias URL y quieres que sus páginas se sirvan exactamente como están escritas, envía la cabecera x-kendor-no-rewrite en sus respuestas HTML. Kendor dejará esas páginas como están.