dev: the Host check on /__nuxt_dev__/* ignores vite.server.allowedHosts, so the error overlay is silently 403'd on hosts-file aliases
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 40/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- nodejs, typescript
Direzione di ricerca
Start in the dev server's #syncAllowedHosts and isAllowedHost logic, plus #rejectDisallowedHost, to see how the host allow-set is built and why vite.server.allowedHosts is never read there. The overlay mount() fetch in the client is the other half: a non-OK response is silently dropped. Done means a Host listed in vite.server.allowedHosts gets a 200 on /__nuxt_dev__/progress, with the security trade-off for true settled first in the thread.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Environment
- @nuxt/cli 4.0.0 and 4.0.1 (same code path), nuxt 4.6.0 / 4.6.1, vite 8, node 24, macOS, Chrome 155
nuxt dev --https --host=0.0.0.0 --port=3000, app opened at a hosts-file alias (https://local.example.test:3000, 127.0.0.1)- nuxt.config:
vite: { server: { allowedHosts: true } }
What happens
- A client error is reported (
vue:error,app:error, windowerrororunhandledrejection->nuxt:dev:client-error). The server answers with the HMR eventnuxt:dev:errorcarrying/__nuxt_dev__/error-overlay/<id>. - The overlay plugin
fetch()es that URL withHost: local.example.test:3000. The CLI answers403 Forbidden: this host is not allowed. Pass it to--host, or--publicto allow any host.from#rejectDisallowedHost(host check, see #1484). mount()treats a non-OK response as 'no overlay' (res.ok ? res.text() : undefined) and.catch(() => {})s the rest, so nothing is logged. The developer sees a red 403 in the network tab and never sees the error. Onhttps://localhost:3000the overlay appears.
The same guard also rejects /__nuxt_dev__/error/{events,history,open}, /__nuxt_dev__/progress, and every path while the server is loading or a load failed (#serve), so an overlay injected into SSR HTML cannot subscribe to the channel either.
Why
#syncAllowedHosts only knows the --host value and listener.getURLs(), and isAllowedHost is an exact match on that set. vite.server.allowedHosts is never consulted, although the CLI already writes and merges it in #createListener. A project that declared its dev hostnames (or opted out of Vite's check with true) is still rejected by a second, independent allow-list. The only opt-out, --public, also sets devServer.cors = { origin: '*' }; --host=<alias> changes the bind interface and supports one name.
Proposal
- In
#syncAllowedHosts, also honornuxt.options.vite.server.allowedHosts:trueskips the check (the effect--publichas on the check, nothing else); an array is added to the allow-set, with Vite's leading-dot meaning (.example.com= domain + subdomains) inisAllowedHost. - Optional:
NUXT_DEV_ALLOWED_HOSTS(or a flag) so the list is also known before nuxt.config is loaded (the eager bind, the loading page and the load-failure page). - Overlay client:
console.warnwith the status when the overlay fetch is not OK, so a blocked overlay is not silent. - Longer term: split
--publicinto 'allow any Host' and 'CORS *', or document thatallowedHostsdoes not reach the CLI endpoints.
Security note: the check exists for DNS rebinding. The channel is created with allowedHosts: true (useErrorChannel), so the CLI check is the only rebinding defense for POST /__nuxt_dev__/error/open. An explicit list is therefore the conservative form, true should stay an explicit opt-in, and default behaviour stays unchanged.
Reproduction
- Any Nuxt 4.6 app with
vite: { server: { allowedHosts: true } }innuxt.config, started withnuxt dev --https --host=0.0.0.0 --port=3000(--https.cert/--https.keyfor a certificate that covers the alias). curl -sk -o /dev/null -w '%{http_code}\n' -H 'Host: local.example.test:3000' https://127.0.0.1:3000/__nuxt_dev__/progressreturns403, with the bodyForbidden: this host is not allowed. Pass it to `--host`, or `--public` to allow any host.- The same request with
-H 'Host: localhost:3000'returns200(the progress stream). - In a browser on a hosts-file alias (
127.0.0.1 local.example.test), trigger any client error. The network tab showsGET /__nuxt_dev__/error-overlay/<id>with 403, the console shows nothing, and no overlay appears. While the server is starting or restarting, document requests from the alias also get the plain-text 403 (no refresh), wherelocalhostgets the self-reloading loading screen.
Patch sketch (about 25 lines; applies to 4.0.0 and 4.0.1)
#syncAllowedHosts(options) {
const extra = resolveExtraAllowedHosts(this.#currentNuxt?.options.vite?.server?.allowedHosts, process.env.NUXT_DEV_ALLOWED_HOSTS);
this.#allowAnyHost = !!options.public || extra.any;
this.#allowedHosts.clear();
if (this.#allowAnyHost) return;
/* existing: --host value + listener URLs */
for (const host of extra.hosts) this.#allowedHosts.add(host);
}
isAllowedHost: after allowedHosts.has(hostname), also accept entries starting with . when hostname === entry.slice(1) || hostname.endsWith(entry).
Happy to send a PR if the direction is acceptable.
- Lingua principale
- TypeScript
- Stelle
- 401
- Fork
- 123
- Merge medio
- 1g 1h
- PR unite (30g)
- 71
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nuxt/cli
-
Difficoltà 3/5 Mezza giornata Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Support pause HMRForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
discussion
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
nuxt/cli#1166 · 7 commenti · 2 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Feature request: Ability to overload and customise the templatesForse già presa @oritwoen l’ha presa 63 giorni fa. Apertaenhancement good first issue
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
nuxt/cli#1136 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 75/100
siyuan-note/siyuan#20629 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Volume eject does not refuse system, root or /home mountsForse già presa @bernardopg l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
spacedriveapp/spacedrive#3159 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
melgarafael/DeskcommCRM#3000 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
callstackincubator/simlock#639 ·
I maintainer di solito rispondono entro 1 giorno