Was mit localhost-URLs in der Vorschau einer Coding-Aufgabe passiert

Das Frontend eines Projekts ruft seine API oft unter http://localhost:4000 auf, aus einer Env-Datei wie NEXT_PUBLIC_API_URL oder fest im Code verdrahtet. In einer Kendor-Vorschau läuft die Seite im Browser des Betrachters, wo localhost sein eigener Rechner ist, nicht die Sandbox. Kendor leitet diese Aufrufe an den richtigen Port in der Sandbox um, sodass die meisten Projekte ohne Änderungen funktionieren. Dieser Artikel behandelt, was umgeleitet wird, was nicht, und den expliziten Weg, URLs zu bauen, wenn du dich lieber nicht darauf verlassen möchtest.

Was Kendor umleitet

Jede URL, deren Host localhost, 127.0.0.1, 0.0.0.0 oder [::1] ist, auf jedem Port, aufgerufen von der Vorschau-Seite oder ihren Web Workern:

• Requests mit fetch und XMLHttpRequest (und damit axios und die meisten anderen HTTP-Bibliotheken)
• WebSockets, einschließlich socket.io und Hot Reload, sowie Server-Sent Events (EventSource)
• Bilder, Skripte, Stylesheets, Videos, iframes, Links und Formulare, ob sie im ausgelieferten HTML stehen, per JavaScript gesetzt oder als Markup eingefügt werden
• Weiterleitungen deines Servers auf http://localhost:…

Es spielt keine Rolle, woher die URL stammt: eine in das Bundle eingebackene Env-Variable, ein fest eingetragener String oder einer, der zur Laufzeit gebaut wird.

Wohin eine umgeleitete URL führt

• Wenn das routing der Aufgabe diesen Pfad an diesen Port schickt, geht die URL an die Vorschau-Adresse selbst. Zum Beispiel geht http://localhost:4000/api/users an https://<preview-address>/api/users, wenn /api zum Dienst auf Port 4000 geroutet wird. Frontend und API teilen sich dann eine Adresse, es gibt also gar kein CORS.
• Andernfalls geht sie an die eigene Adresse dieses Ports, https://4000-<preview-address>/api/users, dieselbe Adresse, die die Ansicht Prozesse für diesen Port öffnet.

Beim ersten Umleiten eines Ports meldet das die Browser-Konsole:

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

CORS, Weiterleitungen und Cookies

Ein Aufruf von der Vorschau an die Adresse eines anderen Ports ist Cross-Origin, daher lässt Kendor ihn so aussehen, wie er auf deinem Rechner aussah:

• CORS. Deine API erhält Origin: http://localhost:3000 (der Port, von dem die Seite kam), eine für die lokale Entwicklung geschriebene Allow-List greift also. Ihre Antwort wird auf die Vorschau-Adresse zurückgemappt. Das gilt nur für Aufrufe aus der eigenen Vorschau der Aufgabe; Requests anderer Websites bleiben unverändert.
• Weiterleitungen. Ein Header Location: http://localhost:3000/dashboard wird auf die Vorschau-Adresse umgeschrieben.
• Cookies. Die Vorschau erscheint im Editor, also auf einer anderen Website, wo Browser gewöhnliche Cookies verwerfen. Kendor markiert die Cookies deiner App als partitioniert (SameSite=None; Secure; Partitioned), sodass auch ein Cookie-Login dort funktioniert. Bei einem Cookie mit Domain=localhost wird diese Domain entfernt.

Serverseitiger Code braucht nichts davon. In der Sandbox erreicht localhost bereits den richtigen Prozess, eine Next.js-Server-Komponente oder eine API, die einen anderen Dienst unter http://localhost:4000 aufruft, funktioniert also wie auf deinem Rechner.

Was nicht umgeleitet wird

• Ein CSS-url(), das auf localhost zeigt, etwa background: url(http://localhost:4000/bg.png).
• Worker, die aus einer Blob- oder Data-URL erstellt wurden, statt aus einer Skriptdatei.
• Im Code gesetzte Seitennavigation, etwa location.href = 'http://localhost:3000/login', in Firefox. Chrome, Edge und Safari sind abgedeckt.
• OAuth-Callback-URLs, die bei einem Anbieter wie Google oder GitHub als localhost registriert sind. Aktualisiere sie beim Anbieter oder melde dich auf andere Weise mit einem Testkonto an.
• Ein Server, der nur auf 127.0.0.1 lauscht. Die Vorschau kann ihn überhaupt nicht erreichen. Lausche stattdessen auf $HOST (0.0.0.0).

Wenn die Seite dennoch etwas von localhost lädt, nennt die Browser-Konsole die betroffene 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 fragt den Betrachter eventuell auch nach der Erlaubnis, auf sein lokales Netzwerk zuzugreifen. Beides bedeutet dasselbe: Ändere diese URL wie unten beschrieben.

Der explizite Weg

Statt dich auf die Umleitung zu verlassen, kannst du dem Browser die richtige Adresse selbst geben. Beide Wege funktionieren in der Sandbox und auf deinem Rechner.

• Ein relativer Pfad. Wenn routing /api an deine API schickt, rufe fetch('/api/users') auf. Frontend und API teilen sich die Vorschau-Adresse. Siehe Multi-Service-Apps.
• Eine Referenz in dev.env.vars. Setze die API-Variable deines Frontends auf die öffentliche URL der API:

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

routing.api.url wird zur Vorschau-Adresse plus der Route der API aufgelöst, bevor ein Dienst startet.

Jeder Dev-Befehl erhält außerdem KENDOR_PUBLIC_HOST, den Hostnamen der Vorschau, für Code, der URLs selbst baut. Die eigene Adresse eines Ports ist dieser Host mit vorangestelltem <port>-.

Ausschalten

Wenn deine App ihre eigenen URLs abbildet und du ihre Seiten exakt wie geschrieben ausgeliefert haben möchtest, sende den Header x-kendor-no-rewrite in ihren HTML-Antworten. Kendor lässt diese Seiten dann unverändert.