Che cosa succede agli URL localhost nell'anteprima di una sfida di codice

Il frontend di un progetto spesso chiama la propria API su http://localhost:4000, da un file env come NEXT_PUBLIC_API_URL o scritto direttamente nel codice. In un'anteprima Kendor la pagina gira nel browser di chi la guarda, dove localhost è il suo computer, non la sandbox. Kendor reindirizza quelle chiamate alla porta giusta nella sandbox, quindi la maggior parte dei progetti funziona senza modifiche. Questo articolo spiega che cosa viene reindirizzato, che cosa no, e il modo esplicito di costruire gli URL quando preferisci non fare affidamento su questo meccanismo.

Che cosa reindirizza Kendor

Qualsiasi URL il cui host sia localhost, 127.0.0.1, 0.0.0.0 o [::1], su qualsiasi porta, generato dalla pagina di anteprima o dai suoi web worker:

• richieste con fetch e XMLHttpRequest (e quindi axios e la maggior parte delle altre librerie HTTP)
• WebSocket, inclusi socket.io e l'hot reload, e server-sent events (EventSource)
• immagini, script, fogli di stile, video, iframe, link e form, sia che si trovino nell'HTML servito, sia che vengano impostati da JavaScript o inseriti come markup
• redirect dal tuo server verso http://localhost:…

Non importa da dove arrivi l'URL: una variabile env inclusa nel bundle, una stringa scritta nel codice o una costruita a runtime.

Dove va un URL reindirizzato

• Se il routing della sfida manda quel percorso a quella porta, l'URL va all'indirizzo dell'anteprima stesso. Ad esempio, http://localhost:4000/api/users va a https://<preview-address>/api/users quando /api è instradato verso il servizio sulla porta 4000. Frontend e API condividono così un unico indirizzo, quindi non c'è alcun CORS.
• Altrimenti va all'indirizzo proprio di quella porta, https://4000-<preview-address>/api/users, lo stesso indirizzo che la vista Processi apre per quella porta.

La prima volta che una porta viene reindirizzata, la console del browser lo segnala:

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

CORS, redirect e cookie

Una chiamata dall'anteprima all'indirizzo di un'altra porta è cross-origin, quindi Kendor la fa apparire come sul tuo computer:

• CORS. La tua API riceve Origin: http://localhost:3000 (la porta da cui proviene la pagina), quindi una allow-list scritta per lo sviluppo locale passa. La sua risposta viene rimappata sull'indirizzo dell'anteprima. Solo le chiamate provenienti dall'anteprima della sfida stessa ricevono questo trattamento; le richieste di qualsiasi altro sito restano invariate.
• Redirect. Un header Location: http://localhost:3000/dashboard viene riscritto sull'indirizzo dell'anteprima.
• Cookie. L'anteprima viene mostrata dentro l'editor, su un altro sito, dove i browser scartano i cookie ordinari. Kendor contrassegna i cookie della tua app come partizionati (SameSite=None; Secure; Partitioned), quindi funziona anche un login con cookie. Da un cookie con Domain=localhost viene rimosso quel dominio.

Il codice lato server non ha bisogno di nulla di tutto questo. Dentro la sandbox, localhost raggiunge già il processo giusto, quindi un server component di Next.js o un'API che chiama un altro servizio su http://localhost:4000 funziona come sul tuo computer.

Che cosa non viene reindirizzato

• Un url() CSS che punta a localhost, come background: url(http://localhost:4000/bg.png).
• Worker creati da un blob o da un data URL, invece che da un file di script.
• La navigazione della pagina impostata nel codice, come location.href = 'http://localhost:3000/login', in Firefox. Chrome, Edge e Safari sono coperti.
• Gli URL di callback OAuth registrati presso un provider come Google o GitHub come localhost. Aggiornali presso il provider, oppure accedi in altro modo con un account di prova.
• Un server in ascolto solo su 127.0.0.1. L'anteprima non riesce a raggiungerlo affatto. Metti invece il server in ascolto su $HOST (0.0.0.0).

Quando la pagina carica ancora qualcosa da localhost, la console del browser dice quale 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 può anche chiedere a chi guarda il permesso di accedere alla sua rete locale. Entrambi i segnali significano la stessa cosa: cambia quell'URL come descritto di seguito.

Il modo esplicito

Invece di affidarti al reindirizzamento, puoi dare tu stesso al browser l'indirizzo giusto. Entrambi i modi funzionano nella sandbox e sul tuo computer.

• Un percorso relativo. Con routing che manda /api alla tua API, chiama fetch('/api/users'). Frontend e API condividono l'indirizzo dell'anteprima. Vedi app con più servizi.
• Un riferimento in dev.env.vars. Imposta la variabile API del tuo frontend sull'URL pubblico dell'API:

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

routing.api.url si risolve nell'indirizzo dell'anteprima più la route dell'API, prima che parta qualsiasi servizio.

Ogni comando dev riceve anche KENDOR_PUBLIC_HOST, il nome host dell'anteprima, per il codice che costruisce gli URL da sé. L'indirizzo proprio di una porta è quell'host preceduto da <port>-.

Disattivarlo

Se la tua app mappa da sé i propri URL e vuoi che le sue pagine vengano servite esattamente come scritte, invia l'header x-kendor-no-rewrite sulle sue risposte HTML. Kendor lascerà quelle pagine così come sono.