Adattamento del sito Web per le nuove restrizioni di accesso alla rete locale in Microsoft Edge

Ultimo aggiornamento: 1° ottobre 2025

Le restrizioni di accesso alla rete locale inizieranno la spedizione per impostazione predefinita in Microsoft Edge 143. Per altre informazioni sull'accesso alla rete locale e sulle motivazioni per richiedere l'autorizzazione utente per effettuare richieste di rete locale, vedere la specifica accesso alla rete locale.

Se si dispone di un sito Web che deve connettersi a un server che esegue localhost o da qualche parte nella rete locale dell'utente (possibilmente tramite una raccolta di terze parti), questo documento tenta di rispondere a domande comuni e fornire indicazioni su come adattare il sito Web in modo che funzioni con queste nuove restrizioni.

In molti casi, le richieste di rete locale devono continuare a funzionare come in precedenza, ma gli utenti visualizzano una richiesta di autorizzazione la prima volta che si verificano in un sito. In alcuni casi, è necessario modificare il sito in modo che queste richieste continuino a funzionare (e non vengano bloccate come contenuto misto). Ad esempio, se si eseguano richieste fetch() a un nome di dominio pubblico, che si risolve in un indirizzo di rete locale, è necessario contrassegnare in modo esplicito le chiamate fetch() come indirizzate a un indirizzo locale. In alternativa, se oggi devi ospitare il tuo sito Web su HTTP (invece di HTTPS) a causa del blocco di contenuti misti, vuoi iscriverti alla versione di valutazione di Origin per esentare temporaneamente il tuo sito dai requisiti HTTPS per richiedere l'autorizzazione LNA.

Qual è l'ambito corrente delle restrizioni LNA in Microsoft Edge?

Il prompt delle autorizzazioni viene attivato quando viene stabilita una connessione a una destinazione nella rete locale o localhost. A partire da Microsoft Edge 143, le restrizioni LNA si applicano a:

• Richieste di sottorisorse
• richieste fetch()
• Esplorazione di sottoframe

Le restrizioni LNA inizialmente non si applicano ai tipi di connessione seguenti, anche se si prevede di includerli presto:

• WebSocket
• WebTransport
• WebRTC

Attualmente non è previsto l'applicazione delle restrizioni LNA alla struttura di spostamento dei fotogrammi principale. Anche se un bug nella bozza di implementazione in Edge 139 e versioni precedenti ha accidentalmente influenzato lo spostamento dei fotogrammi principali.

Attualmente non è previsto l'applicazione di restrizioni LNA alle estensioni. Attualmente, le estensioni con le autorizzazioni host necessarie sono autorizzate a effettuare richieste di rete locale.

Le restrizioni LNA non si applicano ad Android WebView. Le app Android che incorporano WebView che effettuano richieste di rete locale sono invece soggette alla nuova autorizzazione di rete locale di Android.

Come è possibile fornire agli utenti un contesto aggiuntivo per la richiesta di autorizzazione LNA?

Quando si richiede un'autorizzazione, può essere utile fornire all'utente un contesto aggiuntivo nell'app Web per il motivo per cui è necessaria l'autorizzazione e per cosa usarla. L'API Autorizzazioni consente di verificare se un utente ha concesso (o negato) una determinata autorizzazione e quindi personalizzare l'interfaccia utente di conseguenza.

A causa del funzionamento dell'API autorizzazioni, l'esecuzione di query sullo stato dell'autorizzazione di accesso alla rete locale restituisce "prompt" indipendentemente dal fatto che il flag di funzionalità LNA sia abilitato, se all'utente non viene concessa o negata l'autorizzazione. Il flag di funzionalità è abilitato per impostazione predefinita in Microsoft Edge 143, quindi è possibile inviare comportamenti diversi in base alla versione principale nella stringa dell'agente utente.

Per fornire più contesto prima di attivare la richiesta di autorizzazione LNA, le linee guida correnti prevedono l'uso di un modello simile al seguente:

• Se il client è Edge < 143, le richieste di rete locale devono funzionare in modo invisibile all'utente
• Se il client è Edge >= 143, eseguire una query sull'API delle autorizzazioni (vedere la chiamata di esempio seguente)
  • Se viene concessa l'autorizzazione, procedere con il tentativo di richiesta
  • Se l'autorizzazione viene negata, mostra facoltativamente l'interfaccia utente per aiutare l'utente a correggere se necessario
  • Se lo stato dell'autorizzazione è "prompt", contestualizzare nell'app che si verifica un prompt

Chiamata API Autorizzazioni di esempio:

navigator.permissions.query({ name: "local-network-access" })
.then((result) => {
  console.log(`LNA permission state: ${result.state}`)
});

Nota: l'API Autorizzazioni restituirà sempre "negato" quando viene chiamato da una pagina HTTP.

Come è possibile attivare il prompt delle autorizzazioni a livello di codice?

Il prompt delle autorizzazioni LNA non viene attivato se non viene stabilita una connessione all'endpoint remoto. Se è più semplice per il flusso di lavoro attivare la richiesta di autorizzazione prima di tentare di stabilire una connessione al dispositivo locale, un modo per aggirare questo aspetto consiste nell'effettuare una richiesta fetch() a un nome host che può essere verificato come presente negli spazi degli indirizzi locali o di loopback tramite l'esame visivo del nome host (ad esempio localhost o un valore letterale di loopback o indirizzo IP locale).

In pratica, ciò significa che se si attiva un prompt delle autorizzazioni per le connessioni a localhost, in JavaScript viene attivata una chiamata fetch() come indicato di seguito:

fetch("http://localhost")

In alternativa, se si attiva una richiesta di autorizzazione per una connessione a un dispositivo locale, seguire questa procedura:

fetch("https://10.0.0.1")

Alcune note:

• Funziona in Microsoft Edge 144 o versione successiva
• Se l'utente ha accettato (o negato) l'autorizzazione, l'utente non visualizzerà un altro prompt delle autorizzazioni.
• Questo non attiverà una richiesta di autorizzazione se il contesto in cui è stato eseguito il fetch() non richiede l'autorizzazione per contattare localhost (o la rete locale)

Come è possibile effettuare richieste di rete locale dall'interno di un iframe?

Per effettuare una richiesta di rete locale dall'interno di un iframe è necessario che il documento di incorporamento specifichi il flag dei criteri di accesso alla rete locale nell'iframe. Ad esempio, se domainA.example include un iframe per domainB.example, è necessario delegare in modo esplicito l'autorizzazione all'iframe come indicato di seguito:

<iframe src="domainB.example" allow="local-network-access"></iframe>

Quando viene effettuata una richiesta di rete locale dal documento incorporato, viene considerata come se il documento di incorporamento avesse richiesto l'autorizzazione LNA e qualsiasi decisione di autorizzazione da parte dell'utente verrà associata all'origine del documento di incorporamento.

Se il documento all'interno dell'iframe passa ad altri documenti che effettuano anche richieste di rete locale, è necessario specificare tutte le origini di tutti i documenti che possono eventualmente effettuare richieste di rete locale nel flag dei criteri di autorizzazione. Per estendere l'esempio precedente, se domainB.example passa dall'iframe a domainC.example e domainB.example e domainC.example eseguano una richiesta di accesso alla rete locale, è necessario delegare in modo esplicito l'autorizzazione a entrambe le origini come indicato di seguito:

<iframe src="domainB.example" allow="local-network-access domainB.example domainC.example"></iframe>

È anche possibile specificare allow="local-network-access *" per consentire a tutte le origini che possono essere caricate nell'iframe di effettuare richieste di rete locale (anche se non si sa necessariamente cosa sono in anticipo). Ad esempio, questo può essere utile nei casi in cui un iframe può effettuare reindirizzamenti arbitrari a un'altra origine (ad esempio per l'accesso SSO) prima di reindirizzare di nuovo a localhost.

Altre cose da notare:

• Sia la pagina di incorporamento che l'iframe devono essere contesti sicuri per richiedere l'autorizzazione LNA.
• La richiesta dell'autorizzazione LNA all'interno di un iframe annidato (ad esempio, domainA.example incorpora un iframe per domainB.example, che incorpora un iframe per domainC.example, che effettua la richiesta di rete locale) richiede che tutti gli iframe specifichino il flag dei criteri delle autorizzazioni di accesso alla rete locale.
• I criteri di autorizzazione devono essere impostati negli iframe che effettuano richieste di rete locale, anche se si ignora la richiesta di autorizzazione tramite criteri aziendali.

Come è possibile effettuare richieste di rete locale da un ruolo di lavoro del servizio o da un ruolo di lavoro condiviso?

Le richieste di rete locale dai ruoli di lavoro del servizio e dai ruoli di lavoro condivisi sono supportate purché all'origine del ruolo di lavoro sia già stata concessa l'autorizzazione LNA in un contesto di finestra principale. Si vuole tentare di richiedere l'autorizzazione effettuando una richiesta di rete locale iniziale dalla finestra principale dell'applicazione e quindi i lavoratori possono usare tale autorizzazione (anche in background).

Come è possibile effettuare richieste di rete locale da un ruolo di lavoro dedicato?

I ruoli di lavoro dedicati sono strettamente di proprietà di una finestra principale esistente, pertanto le richieste di rete locale da un ruolo di lavoro dedicato attivano il prompt delle autorizzazioni LNA nella finestra proprietaria.

Come è possibile evitare che le richieste di rete locale si blocchino come contenuto misto?

Con LNA, alcune richieste di rete locale sono ora esenti dal blocco del contenuto misto, consentendo ai siti HTTPS di effettuare richieste di rete locale a questi endpoint HTTP:

• Domini locali (ad esempio, http://printer.local)
• Valori letterali IP privati (ad esempio, http://192.168.0.1/)

Inoltre, quando si usa l'API fetch() è possibile specificare l'opzione targetAddressSpace per contrassegnare che una richiesta è destinata alla rete locale o all'indirizzo di loopback. Ad esempio:

• fetch('http://domainA.example', {targetAddressSpace: 'local'}) funzionano se domainA.example si risolve in un indirizzo IP locale come 192.168.10.1
• fetch('http://domainB.example', {targetAddressSpace: 'loopback'}) funzionerà se domainB.example viene risolto nell'indirizzo di loopback 127.0.0.1

Tutti questi elementi saranno esentati dal blocco del contenuto misto.

Come è possibile effettuare richieste di rete locale da una pagina HTTP?

Per richiedere l'autorizzazione LNA, un sito servito tramite HTTPS (ad esempio, LNA richiede un contesto sicuro). Tuttavia, a causa della complessità delle richieste di rete locale, in cui a volte le destinazioni attualmente non supportano HTTPS attendibile pubblicamente, ciò significa che queste richieste di rete locale HTTP potrebbero essere bloccate come contenuto misto.

Mentre LNA tenta di ritagliare eccezioni per i casi comuni (vedere la sezione precedente su "Come posso evitare che le richieste di rete locale siano bloccate come contenuto misto?"), potrebbe non essere semplice adattare il sito per evitare problemi con il contenuto misto.

Se si ha bisogno di più tempo per passare al sito per usare HTTPS o si verificano problemi di blocco con le eccezioni di contenuto misto di LNA attualmente implementate in Microsoft Edge, è possibile iscriversi a una versione di valutazione dell'origine per consentire temporaneamente al sito HTTP di richiedere l'autorizzazione LNA.

Nota: Il token di valutazione dell'origine deve essere servito tramite intestazioni HTTP. Questa versione di valutazione dell'origine non supporta i token distribuiti tramite meta tag o a livello di codice tramite JS.

Come è possibile mantenere al meglio la compatibilità tra browser?

Poiché diversi browser stanno implementando queste restrizioni in momenti diversi, potrebbe essere necessario implementare una logica di rilevamento user-agent per ottimizzare la compatibilità.

La principale differenza di compatibilità tra un browser che supporta la nuova specifica di accesso alla rete locale e una che non è ancora incentrata sul contenuto misto. Nei browser che supportano LNA, l'accesso alla rete locale e l'autorizzazione LNA sono disponibili solo da origini sicure. Le richieste provenienti da origini non sicure hanno esito negativo.

Nei browser che non supportano ancora la specifica LNA, è probabile che la maggior parte dell'accesso alla rete locale sia stato eseguito da un'origine non sicura per evitare che le richieste non sicure alle risorse locali vengano identificate come contenuto misto.

Se attualmente si esegue la pubblicazione della pagina tramite HTTP a causa di questo blocco di contenuto misto, è possibile che si voglia fornire un reindirizzamento a HTTPS per Microsoft Edge 143 e versioni successive, ma continuare a gestire altri browser tramite HTTP (fino a quando non vengono fornite anche restrizioni LNA e le eccezioni di contenuto misto).

Se si effettuano solo richieste di rete locale a localhost, si dovrebbe già essere in grado di gestire il sito tramite HTTPS, poiché localhost è considerato un'origine sicura dalla specifica del contenuto misto e non verrà bloccato come contenuto misto.

Durante l'implementazione di Microsoft Edge, è possibile registrarsi a una versione di valutazione dell'origine per abilitare temporaneamente il prompt delle autorizzazioni LNA per le origini non sicure (HTTP). Altre informazioni sulla registrazione alle versioni di valutazione dell'origine. Questa versione di valutazione dell'origine sarà disponibile solo tramite Microsoft Edge 146 (che è previsto per il canale Stabile a marzo 2026). Gli utenti della versione di valutazione dell'origine devono mirare a eseguire la migrazione a HTTPS prima di tale ora.

Come è possibile testare l'autorizzazione LNA in EdgeDriver/Selenium/e così via?

L'autorizzazione di accesso alla rete locale può essere gestita tramite WebDriver/EdgeDriver. Vedere la documentazione di Selenium sulle funzionalità specifiche di Edge e la documentazione di Microsoft Edge sull'uso di WebDriver per automatizzare Microsoft Edge. Per la gestione specifica delle autorizzazioni, vedere il comando setPermissions di WebDriver e la specifica delprotocollo.

Come è possibile attivare il prompt LNA nei test locali?

Poiché le restrizioni LNA non si applicano ancora alle richieste local→locale o locale→loopback, le configurazioni di sviluppo locali tipiche (come l'esecuzione di un server in localhost) non attivano il prompt delle autorizzazioni in Microsoft Edge.

Può tuttavia essere utile per l'attivazione del prompt delle autorizzazioni nei test locali, ad esempio se si sta lavorando alla personalizzazione dell'interfaccia utente per aggiungere altro contesto prima della richiesta o per consentire agli utenti di ripristinare se l'autorizzazione è stata negata (vedere Come è possibile fornire agli utenti un contesto più in più per il prompt delle autorizzazioni LNA? Sopra).

Microsoft Edge offre due modi per gestire una pagina come se fosse servita da un indirizzo pubblico:

• L'intestazione Content-Security-Policy: treat-as-public-address nel documento HTML fa sì che il documento venga trattato come se fosse stato servito da un indirizzo pubblico.
• Il flag della riga di comando --ip-address-space-overrides può essere usato per forzare indirizzi IP specifici a essere considerati come uno spazio indirizzi specifico (pubblico, locale o loopback).

Esempio di flag di sostituzione dello spazio indirizzi: Il server di sviluppo locale principale viene eseguito nella versione 192.168.10.11, che effettua quindi richieste a un server separato in esecuzione nella versione 192.168.10.12. È possibile passare --ip-address-space-overrides=192.168.10.11:0=public quando si esegue Microsoft Edge per forzare il trattamento della versione 192.168.10.11 come indirizzo pubblico (una porta di 0 significa "applica a tutte le porte"). Quindi, quando le richieste vengono effettuate al server in esecuzione nella versione 192.168.10.12, verranno trattate come richieste di rete locale e attiveranno la richiesta di autorizzazione.

Come è possibile evitare di attivare la richiesta LNA nei test automatizzati?

Le restrizioni LNA non si applicano ancora alle richieste local→locale o locale→loopback, ma alcune configurazioni di test basate su browser possono coinvolgere server locali che potrebbero causare l'attivazione del prompt LNA. Se ciò è imprevisto e non corrisponde al percorso utente reale che si sta testando (ad esempio, il sito di produzione effettua solo richieste ai servizi pubblici), è possibile configurare Microsoft Edge per considerare indirizzi IP specifici come pubblici usando il flag della riga di comando --ip-address-space-overrides=ip-address>:<port>=<address-space e quindi le richieste ai siti pubblici non attiveranno il prompt LNA.

È possibile specificare una porta pari a 0 per applicare l'override a tutte le porte su tale indirizzo IP. È possibile specificare più regole di override, separate da virgole (ad esempio, ip-address-space-overrides=192.168.0.1:8080=public,10.0.1.20:0=loopback). È possibile trovare la grammatica completa per il flag qui.

Esempio: il server di staging viene eseguito nella versione 23.220.75.232 (un indirizzo IP pubblico) ma effettua richieste a un servizio eseguito internamente nella versione 10.0.1.108 (un indirizzo IP privato). Nell'ambiente di produzione, questo servizio viene eseguito su un indirizzo IP pubblico, quindi non è previsto che gli utenti reali vedano il prompt LNA. Nell'imbracatura di test automatizzata per questo servizio si passa il flag della riga di comando --ip-address-space-overrides=10.0.1.108:0=public in modo che tutte le connessioni a tale indirizzo IP siano considerate pubbliche e nessun prompt LNA venga attivato durante il test.

Come determinare il motivo per cui un sito è bloccato da LNA

Ogni volta che un'applicazione Web tenta di accedere alle risorse considerate nella rete locale, viene attivato un prompt per consentire all'utente di consentire o bloccare tale richiesta:

Consentire l'accesso in genere sblocca la funzionalità prevista dall'applicazione Web. Attualmente, quando il tentativo di accesso alla rete locale sta per (o proviene da) un iframe cross-origin considerato nella rete locale, l'esenzione dell'applicazione Web (manualmente o tramite criteri di gruppo) non funzionerà.

Questo scenario iframe è comunemente accompagnato da un errore della console di DevTools:

Access to fetch at 'http://127.0.0.1:8080/data' from origin 'https://example.com'  

has been blocked by CORS policy: Permission was denied for this request to access the `unknown` address space. 

Identificazione degli host cross-origin e di primo livello definiti per l'iframe. Anche se è consigliabile adattare un'applicazione Web interessata per aggiungere l'autorizzazione "accesso alla rete locale" nell'iframe, questo potrebbe non essere possibile senza il controllo diretto sul codice dell'applicazione Web.

Alcune librerie usate nelle applicazioni Web che possono essere usate all'interno di iframe cross-origin già rilasciati correzioni per supportare le autorizzazioni LNA necessarie, ad esempio MSAL-browser, incluse nella versione 4.26.1 o successiva.

Come attenuare l'impatto per iframe tra le origini

Quando gli host di primo livello o iframe sono considerati nella rete locale, a seconda di condizioni di rete specifiche, l'unico modo per attenuare l'impatto senza eseguire modifiche al codice consiste nell'usare l'impostazione dei LocalNetworkAccessRestrictionsTemporaryOptOut criteri.

Esistono piani per fornire due impostazioni aggiuntive dei criteri per superare questo scenario, una per consentire agli iframe di origine incrociata di ereditare l'autorizzazione LNA dell'host di primo livello e un'altra per esentare uno spazio indirizzi specifico dall'essere considerato una rete locale (come l'intervallo di indirizzi NAT di livello carrier ). La documentazione viene aggiornata quando Microsoft Edge fornisce supporto ufficiale per questi criteri.

Come è possibile fornire commenti e suggerimenti su LNA in generale?

Registrare un problema con il feedback sul repository delle specifiche di accesso alla rete locale in GitHub.

Come è possibile segnalare bug nell'implementazione LNA di Microsoft Edge?

Per problemi specifici dell'implementazione di Microsoft Edge dell'accesso alla rete locale, usare i canali di feedback di Microsoft Edge o contattare supporto tecnico Microsoft per i clienti aziendali.

[Enterprise] Come consentire URL di elenco o di blocco per le richieste di rete locale

Esistono due criteri aziendali per LNA: LocalNetworkAccessAllowedForUrls e LocalNetworkAccessBlockedForUrls. Questi possono essere usati per consentire le richieste di rete locale da un URL senza visualizzare il prompt delle autorizzazioni o per impedire a un URL di effettuare richieste di rete locale.

Questi criteri supportano anche i caratteri jolly con la sintassi del modello DI URL .

Il criterio LocalNetworkAccessAllowedForUrls si applica all'origine di primo livello del sito che effettua la richiesta. Se l'accesso alla rete locale effettivo viene eseguito all'interno di un iframe incorporato in tale pagina (o in un iframe annidato), tutti gli iframe devono impostare il flag dei criteri di autorizzazione.

[Enterprise] È stato impostato LocalNetworkAccessAllowedForUrls, ma si verificano ancora problemi

Se il criterio LocalNetworkAccessAllowedForUrls è stato impostato correttamente, ma le applicazioni non funzionano ancora, è probabile che sia necessario correggere gli iframe. Vedere la sezione precedente intitolata "Come è possibile effettuare richieste di rete locale dall'interno di un iframe?"

Esiste anche un criterio aziendale temporaneo, LocalNetworkAccessRestrictionsTemporaryOptOut, che consente alle aziende di rifiutare esplicitamente tutte le restrizioni LNA. Questo criterio è un criterio temporaneo e verrà rimosso dopo Edge 152.

Nota: questi criteri possono essere configurati usando Criteri di gruppo (tramite modelli ADMX), Microsoft Intune (usando il Catalogo impostazioni) o altre soluzioni MDM (Mobile Gestione dispositivi). Per altre informazioni sulla configurazione dei criteri di Microsoft Edge, vedere Configurare le impostazioni dei criteri di Microsoft Edge.