Configurare App Web statiche di Azure

È possibile definire la configurazione per App Web statiche di Azure nel file staticwebapp.config.json, che controlla le impostazioni seguenti:

• Routing
• Autenticazione
• Autorizzazione
• Regole di fallback
• Override della risposta HTTP
• Definizioni di intestazione HTTP globali
• Tipi MIME personalizzati
• Networking

Percorso del file

Il percorso consigliato per il staticwebapp.config.json si trova nella cartella impostata come app_location nel file del flusso di lavoro. Tuttavia, è possibile inserire il file in qualsiasi sottocartella all'interno della cartella impostata come app_location. Inoltre, se è presente un passaggio di compilazione, è necessario assicurarsi che il passaggio di compilazione restituisca il file alla radice del output_location.

Per informazioni dettagliate, vedere il file di configurazione di esempio.

Route

È possibile definire regole per una o più route nell'app Web statica. Le regole di route consentono di limitare l'accesso agli utenti in ruoli specifici o di eseguire azioni come il reindirizzamento o la riscrittura. Le route vengono definite come una matrice di regole di routing. Vedere il file di configurazione di esempio per esempi di utilizzo.

• Le regole vengono definite nella routes matrice, anche se si dispone di una sola route.
• Le regole vengono valutate nell'ordine in cui vengono visualizzate nella routes matrice.
• La valutazione delle regole si arrestata alla prima corrispondenza. Una corrispondenza si verifica quando la route proprietà e un valore nella methods matrice (se specificato) corrispondono alla richiesta. Ogni richiesta può corrispondere al massimo a una regola.

Il routing riguarda una sovrapposizione significativa con i concetti relativi all'autenticazione (identificazione dell'utente) e all'autorizzazione (assegnazione di capacità all'utente). Leggere la guida all'autenticazione e all'autorizzazione insieme a questo articolo.

Definire le route

Ogni regola è costituita da un modello di route, insieme a una o più proprietà della regola facoltative. Le regole di route vengono definite nella routes matrice. Vedere il file di configurazione di esempio per esempi di utilizzo.

Proprietà regola	Richiesto	Default value	Comment
route	Sì	n/d	Modello di route richiesto dal chiamante. I caratteri jolly sono supportati alla fine dei percorsi di route. Ad esempio, la route /admin* corrisponde a qualsiasi route che inizia con /admin.
methods	No	Tutti i metodi	Definisce una matrice di metodi di richiesta che corrispondono a una route. I metodi disponibili includono: GET, HEADPOST, PUT, DELETE, CONNECT, OPTIONS, TRACE, e PATCH.
rewrite	No	n/d	Definisce il file o il percorso restituito dalla richiesta. Si escludono a vicenda una redirect regola. Le regole di riscrittura non modificano la posizione del browser. I valori devono essere relativi alla radice dell'app.
redirect	No	n/d	Definisce la destinazione di reindirizzamento del file o del percorso per una richiesta. Si escludono a vicenda una rewrite regola. Le regole di reindirizzamento modificano la posizione del browser. Il codice di risposta predefinito è un 302 (reindirizzamento temporaneo), ma è possibile eseguire l'override con un 301 (reindirizzamento permanente).
statusCode	No	301 o 302 per i reindirizzamenti	Codice di stato HTTP della risposta.
headers	No	n/d	Set di intestazioni HTTP aggiunte alla risposta. Le intestazioni specifiche della route eseguono l'override globalHeaders quando l'intestazione specifica della route corrisponde all'intestazione globale nella risposta. Per rimuovere un'intestazione, impostare il valore su una stringa vuota.
allowedRoles	No	anonimo	Definisce una matrice di nomi di ruolo necessari per accedere a una route. I caratteri validi includono a-z, A-Z, 0-9 e _. Il ruolo predefinito, anonymous, si applica a tutti gli utenti. Il ruolo predefinito, authenticated, si applica a qualsiasi utente connesso. Gli utenti devono appartenere ad almeno un ruolo. Per la corrispondenza dei ruoli viene usato l'operatore OR. Se un utente è incluso in uno dei ruoli elencati, viene concesso l'accesso. I singoli utenti sono associati ai ruoli tramite inviti.

Ogni proprietà ha uno scopo specifico nella pipeline di richiesta/risposta.

Scopo	Proprietà
Corrispondenze route	route, methods
Processo dopo la corrispondenza di una regola e l'autorizzazione	rewrite (modifica la richiesta) redirect, headers, statusCode (modifica la risposta)
Autorizzare dopo la corrispondenza di una route	allowedRoles

Specificare i modelli di route

La route proprietà può essere una route esatta o un criterio con caratteri jolly.

Percorso esatto

Per definire una route esatta, posizionare il percorso completo del file nella route proprietà .

{
  "route": "/profile/index.html",
  "allowedRoles": ["authenticated"]
}

Questa regola corrisponde alle richieste per il file /profile/index.html. Poiché index.html è il file predefinito, la regola corrisponde anche alle richieste per la cartella (/profile o /profile/).

Modello con caratteri jolly

Le regole con caratteri jolly corrispondono a tutte le richieste in un modello di route e sono supportate solo alla fine di un percorso. Vedere il file di configurazione di esempio per esempi di utilizzo.

Ad esempio, per implementare le route per un'applicazione di calendario, è possibile riscrivere tutti gli URL che rientrano nella route del calendario per gestire un singolo file.

{
  "route": "/calendar*",
  "rewrite": "/calendar.html"
}

Il file calendar.html può quindi usare il routing lato client per restituire una visualizzazione diversa per le variazioni degli URL, ad esempio /calendar/january/1, /calendar/2020 e /calendar/overview.

È possibile filtrare le corrispondenze con caratteri jolly in base all'estensione di file. Ad esempio, se si vuole aggiungere una regola che corrisponde solo ai file HTML in un determinato percorso, è possibile creare la regola seguente:

{
  "route": "/articles/*.html",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

Per filtrare in base a più estensioni di file, includere le opzioni tra parentesi graffe, come illustrato in questo esempio:

{
  "route": "/images/thumbnails/*.{png,jpg,gif}",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

I casi d'uso comuni per le route con caratteri jolly includono:

• Gestione di un file specifico per un intero modello di percorso
• Applicazione di regole di autenticazione e autorizzazione
• Implementazione di regole di memorizzazione nella cache specializzate

Proteggere le route con i ruoli

Per proteggere le route è necessario aggiungere uno o più nomi di ruolo in una matrice allowedRoles di una regola. Vedere il file di configurazione di esempio per esempi di utilizzo.

Per impostazione predefinita, ogni utente appartiene al ruolo anonymous predefinito e tutti gli utenti connessi sono membri del ruolo authenticated. Facoltativamente, gli utenti sono associati a ruoli personalizzati tramite inviti.

Ad esempio, per limitare una route solo agli utenti autenticati, aggiungere il ruolo authenticated predefinito alla matrice allowedRoles.

{
  "route": "/profile*",
  "allowedRoles": ["authenticated"]
}

È possibile creare nuovi ruoli in base alle esigenze nella matrice allowedRoles. Per limitare una route solo agli amministratori, è possibile definire il proprio ruolo denominato administrator, nella allowedRoles matrice .

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}

• Hai il controllo completo sui nomi dei ruoli; non esiste un elenco a cui devono essere conformi i ruoli.
• I singoli utenti sono associati ai ruoli tramite inviti.

Limitare l'accesso all'intera applicazione

Spesso si vuole richiedere l'autenticazione per ogni route nell'applicazione. Per bloccare le route, aggiungere una regola che corrisponda a tutte le route e includere il ruolo predefinito authenticated nella allowedRoles matrice.

L'esempio di configurazione seguente blocca l'accesso anonimo e reindirizza tutti gli utenti non autenticati alla pagina di accesso di Microsoft Entra.

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

Route di fallback

Le applicazioni a pagina singola spesso si basano sul routing lato client. Queste regole di routing lato client aggiornano la posizione della finestra del browser senza inviare di nuovo richieste al server. Se si aggiorna la pagina o si passa direttamente agli URL generati dalle regole di routing lato client, è necessaria una route di fallback sul lato server per gestire la pagina HTML appropriata. La pagina di fallback viene spesso designata come index.html per l'app sul lato client.

È possibile definire una regola di fallback aggiungendo una navigationFallback sezione. L'esempio seguente restituisce /index.html per tutte le richieste di file statiche che non corrispondono a un file distribuito.

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

È possibile controllare le richieste che restituiscono il file di fallback definendo un filtro. Nell'esempio seguente, le richieste per determinate route nella cartella /images e tutti i file nella cartella /css vengono esclusi dalla restituzione del file di fallback.

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  }
}

Ad esempio, con la struttura di directory seguente, la regola di fallback di navigazione precedente restituirà i risultati descritti nella tabella seguente.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
├── about.html
└── index.html

Richieste a...	rendiconto...	con lo stato...
/circa/	File /index.html .	200
/images/logo.png	File di immagine.	200
/images/icon.svg	File /index.html : poiché l'estensione di file svg non è elencata nel /images/*.{png,jpg,gif} filtro.	200
/images/unknown.png	Errore file non trovato.	404
/css/unknown.css	Errore file non trovato.	404
/css/global.css	File del foglio di stile.	200
/about.html	Pagina HTML.	200
Qualsiasi altro percorso all'esterno delle cartelle /images o /css che non corrisponde al percorso di un file distribuito.	File /index.html .	200

Intestazioni globali

La globalHeaders sezione fornisce un set di intestazioni HTTP applicate a ogni risposta, a meno che non venga sottoposto a override da una regola di intestazione di route, altrimenti viene restituita l'unione di entrambe le intestazioni della route e delle intestazioni globali.

Vedere il file di configurazione di esempio per esempi di utilizzo.

Per rimuovere un'intestazione, impostare il valore su una stringa vuota ("").

Alcuni casi d'uso comuni per le intestazioni globali includono:

• Regole di memorizzazione nella cache personalizzate
• Criteri di sicurezza
• Impostazioni di codifica
• Configurazione CORS (Cross-Origin Resource Sharing)

Nell'esempio seguente viene implementata una configurazione CORS personalizzata.

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "https://example.com",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS"
  }
}

Override della risposta

La sezione responseOverrides offre l'opportunità di definire una risposta personalizzata quando il server restituirebbe altrimenti un codice di errore. Vedere il file di configurazione di esempio per esempi di utilizzo.

Per eseguire l'override sono disponibili i codici HTTP seguenti:

Codice di stato	significato	Possibile causa
400	Richiesta non valida	Collegamento di invito non valido
401	Non autorizzata	Richiesta di pagine con restrizioni durante l'autenticazione non autenticata
403	Non consentito	L'utente è connesso ma non ha i ruoli necessari per visualizzare la pagina. L'utente è connesso, ma il runtime non può ottenere i dettagli dell'utente dalle attestazioni di identità. Al sito sono connessi troppi utenti con ruoli personalizzati, pertanto il runtime non può accedere all'utente.
404	Non trovato	File non trovato

La configurazione di esempio seguente illustra come eseguire l'override di un codice di errore.

{
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "statusCode": 302,
      "redirect": "/login"
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/custom-404.html"
    }
  }
}

Piattaforma

La platform sezione controlla le impostazioni specifiche della piattaforma, ad esempio la versione del runtime del linguaggio API.

Selezionare la versione del runtime del linguaggio API

Per configurare la versione del runtime del linguaggio API, impostare la apiRuntime proprietà nella platform sezione su uno dei valori supportati seguenti.

Versione del runtime del linguaggio	Sistema operativo	Versione di Funzioni di Azure	Valore apiRuntime	Data di fine supporto
.NET Core 3.1	Finestre	3.x	dotnet:3.1	sabato 3 dicembre 2022
.NET 6.0 in-process	Finestre	4.x	dotnet:6.0	-
Isolato .NET 6.0	Finestre	4.x	dotnet-isolated:6.0	-
Isolato .NET 7.0	Finestre	4.x	dotnet-isolated:7.0	-
.NET 8.0 isolato	Finestre	4.x	dotnet-isolated:8.0	-
Node.js 12.x	Linux	3.x	node:12	sabato 3 dicembre 2022
Node.js 14.x	Linux	4.x	node:14	-
Node.js 16.x	Linux	4.x	node:16	-
Node.js 18.x	Linux	4.x	node:18	-
Node.js 20.x (anteprima)	Linux	4.x	node:20	-
Python 3.8	Linux	4.x	python:3.8	-
Python 3.9	Linux	4.x	python:3.9	-
Python 3.10	Linux	4.x	python:3.10	-

.NET

Per modificare la versione di runtime in un'app .NET, modificare il TargetFramework valore nel file csproj . Anche se facoltativo, se si imposta un apiRuntime valore nel file staticwebapp.config.json , assicurarsi che il valore corrisponda a quello definito nel file csproj .

L'esempio seguente illustra come aggiornare l'elemento TargetFramework per NET 8.0 come versione del runtime del linguaggio API nel file csproj .

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    ...
  </PropertyGroup>
...

Node.js

La configurazione di esempio seguente illustra come usare la apiRuntime proprietà per selezionare Node.js 16 come versione del runtime del linguaggio API nel file staticwebapp.config.json .

{
  ...
  "platform": {
    "apiRuntime": "node:16"
  }
  ...
}

Python

La configurazione di esempio seguente illustra come usare la apiRuntime proprietà per selezionare Python 3.8 come versione del runtime del linguaggio API nel file staticwebapp.config.json .

{
  ...
  "platform": {
    "apiRuntime": "python:3.8"
  }
  ...
}

Rete

La networking sezione controlla la configurazione di rete dell'app Web statica. Per limitare l'accesso all'app, specificare un elenco di blocchi di indirizzi IP consentiti in allowedIpRanges. Per altre informazioni sul numero di blocchi di indirizzi IP consentiti, vedere Quote in App Web statiche di Azure.

Definire ogni blocco di indirizzi IPv4 nella notazione CIDR (Classless Inter-Domain Routing). Per ulteriori informazioni sulla notazione CIDR, vedere Classless Inter-Domain Routing. Ogni blocco di indirizzi IPv4 può indicare uno spazio indirizzi pubblico o privato. Se si vuole consentire l'accesso solo da un singolo indirizzo IP, è possibile usare il /32 blocco CIDR.

{
  "networking": {
    "allowedIpRanges": [
      "10.0.0.0/24",
      "100.0.0.0/32",
      "192.168.100.0/22"
    ]
  }
}

Quando vengono specificati uno o più blocchi di indirizzi IP, le richieste provenienti da indirizzi IP che non corrispondono a un valore in allowedIpRanges vengono negate l'accesso.

Oltre ai blocchi di indirizzi IP, è anche possibile specificare tag di servizio nella matrice per limitare il allowedIpRanges traffico a determinati servizi di Azure.

"networking": {
  "allowedIpRanges": ["AzureFrontDoor.Backend"]
}

Autenticazione

• I provider di autenticazione predefiniti non richiedono impostazioni nel file di configurazione.

• I provider di autenticazione personalizzati usano la auth sezione del file di impostazioni.

Per informazioni dettagliate su come limitare le route agli utenti autenticati, vedere Protezione delle route con ruoli.

Disabilitare la cache per i percorsi autenticati

Se si configura l'integrazione manuale con Frontdoor di Azure, è possibile disabilitare la memorizzazione nella cache per le route protette. Con edge di livello aziendale abilitato, la memorizzazione nella cache è già disabilitata per le route protette.

Per disabilitare la memorizzazione nella cache di Frontdoor di Azure per le route protette, aggiungere "Cache-Control": "no-store" alla definizione dell'intestazione di route.

Ad esempio:

{
    "route": "/members",
    "allowedRoles": ["authenticated, members"],
    "headers": {
        "Cache-Control": "no-store"
    }
}

Gateway di inoltro

La forwardingGateway sezione configura la modalità di accesso a un'app Web statica da un gateway di inoltro, ad esempio una rete CDN (rete per la distribuzione di contenuti) o una frontdoor di Azure.

Host inoltrati consentiti

L'elenco allowedForwardedHosts specifica i nomi host da accettare nell'intestazione X-Forwarded-Host . Se un dominio corrispondente si trova nell'elenco, App Web statiche usa il valore durante la X-Forwarded-Host creazione di URL di reindirizzamento, ad esempio dopo un accesso riuscito.

Affinché App Web statiche funzioni correttamente dietro un gateway di inoltro, la richiesta dal gateway deve includere il nome host corretto nell'intestazione X-Forwarded-Host e lo stesso nome host deve essere elencato in allowedForwardedHosts.

"forwardingGateway": {
  "allowedForwardedHosts": [
    "example.org",
    "www.example.org",
    "staging.example.org"
  ]
}

Se l'intestazione X-Forwarded-Host non corrisponde a un valore nell'elenco, le richieste hanno comunque esito positivo, ma l'intestazione non viene usata nella risposta.

Intestazioni obbligatorie

Le intestazioni obbligatorie sono intestazioni HTTP che devono essere inviate con ogni richiesta al sito. Un uso delle intestazioni obbligatorie consiste nel negare l'accesso a un sito, a meno che non siano presenti tutte le intestazioni necessarie in ogni richiesta.

Ad esempio, la configurazione seguente illustra come aggiungere un identificatore univoco per Frontdoor di Azure che limita l'accesso al sito da un'istanza specifica di Frontdoor di Azure. Per informazioni dettagliate, vedere l'esercitazione Configurare Frontdoor di Azure.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}

• Le coppie chiave/valore possono essere qualsiasi set di stringhe arbitrarie
• Le chiavi non fanno distinzione tra maiuscole e minuscole
• I valori fanno distinzione tra maiuscole e minuscole

Barra finale

Una barra finale è l'oggetto / alla fine di un URL. In modo convenzionale, un URL barra finale fa riferimento a una directory nel server Web, mentre una barra nontrailing indica un file.

I motori di ricerca gestiscono separatamente i due URL, indipendentemente dal fatto che si tratti di un file o di una directory. Quando viene eseguito il rendering dello stesso contenuto in entrambi questi URL, il sito Web serve contenuto duplicato, che può influire negativamente sull'ottimizzazione del motore di ricerca (SEO). Se configurata in modo esplicito, App Web statiche applica un set di regole di normalizzazione e reindirizzamento degli URL che consentono di migliorare le prestazioni e le prestazioni SEO del sito Web.

Per ognuna delle configurazioni disponibili si applicano le regole di normalizzazione e reindirizzamento seguenti:

Sempre

Quando si imposta trailingSlash su always, tutte le richieste che non includono una barra finale vengono reindirizzate a un URL barra finale. Ad esempio, /contact viene reindirizzato a /contact/.

"trailingSlash": "always"

Richieste a...	rendiconto...	con lo stato...	e percorso...
/circa	File /about/index.html	301	/circa/
/circa/	File /about/index.html	200	/circa/
/about/index.html	File /about/index.html	301	/circa/
/privacy.html	File /privacy.html	301	/privacy/

Mai

Quando si imposta trailingSlash su never, tutte le richieste che terminano in una barra finale vengono reindirizzate a un URL barra non predefinito. Ad esempio, /contact/ viene reindirizzato a /contact.

"trailingSlash": "never"

Richieste a...	rendiconto...	con lo stato...	e percorso...
/circa	File /about/index.html	200	/circa
/circa/	File /about/index.html	301	/circa
/about/index.html	File /about/index.html	301	/circa
/privacy.html	File /privacy.html	301	/privacy

Auto

Quando si imposta su trailingSlash auto, tutte le richieste alle cartelle vengono reindirizzate a un URL con una barra finale. Tutte le richieste ai file vengono reindirizzate a un URL barra non predefinito.

"trailingSlash": "auto"

Richieste a...	rendiconto...	con lo stato...	e percorso...
/circa	File /about/index.html	301	/circa/
/circa/	File /about/index.html	200	/circa/
/about/index.html	File /about/index.html	301	/circa/
/privacy.html	File /privacy.html	301	/privacy

Per prestazioni ottimali del sito Web, configurare una strategia di barra finale usando una delle alwaysmodalità , nevero auto .

Per impostazione predefinita, quando la trailingSlash configurazione viene omessa, App Web statiche applica le regole seguenti:

Richieste a...	rendiconto...	con lo stato...	e percorso...
/circa	File /about/index.html	200	/circa
/circa/	File /about/index.html	200	/circa/
/about/index.html	File /about/index.html	200	/about/index.html
/privacy.html	File /privacy.html	200	/privacy.html

File di configurazione di esempio

{
  "trailingSlash": "auto",
  "routes": [
    {
      "route": "/profile*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/admin/index.html",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/images/*",
      "headers": {
        "cache-control": "must-revalidate, max-age=15770000"
      }
    },
    {
      "route": "/api/*",
      "methods": ["GET"],
      "allowedRoles": ["registeredusers"]
    },
    {
      "route": "/api/*",
      "methods": ["PUT", "POST", "PATCH", "DELETE"],
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/customers/contoso*",
      "allowedRoles": ["administrator", "customers_contoso"]
    },
    {
      "route": "/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/.auth/login/x",
      "statusCode": 404
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout"
    },
    {
      "route": "/calendar*",
      "rewrite": "/calendar.html"
    },
    {
      "route": "/specials",
      "redirect": "/deals",
      "statusCode": 301
    }
  ],
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  },
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "redirect": "/login",
      "statusCode": 302
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/404.html"
    }
  },
  "globalHeaders": {
    "content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
  },
  "mimeTypes": {
    ".json": "text/json"
  }
}

In base alla configurazione precedente, esaminare gli scenari seguenti.

Richieste a...	risultati in...
/profile	Agli utenti autenticati viene restituito il file /profile/index.html. Gli utenti non autenticati vengono reindirizzati a /login dalla regola di override della 401 risposta.
/admin, /admin/o /admin/index.html	Gli utenti autenticati nel ruolo di amministratore vengono gestiti dal file /admin/index.html . Gli utenti autenticati non nel ruolo di amministratore vengono gestiti con un 403 errore1. Gli utenti non autenticati vengono reindirizzati a /login
/images/logo.png	Serve l'immagine con una regola della cache personalizzata in cui la validità massima è di poco superiore a 182 giorni (15.770.000 secondi).
/api/admin	GET le richieste degli utenti autenticati nel ruolo registeredusers vengono inviate all'API. Gli utenti autenticati non nel ruolo registeredusers e gli utenti non autenticati vengono visualizzati un 401 errore. POSTLe richieste , PUT, PATCHe DELETE degli utenti autenticati nel ruolo di amministratore vengono inviate all'API. Gli utenti autenticati non nel ruolo di amministratore e gli utenti non autenticati vengono generati un 401 errore.
/customers/contoso	Gli utenti autenticati che appartengono al ruolo di amministratore o customers_contoso vengono gestiti dal file /customers/contoso/index.html . Gli utenti autenticati non inclusi nell'amministratore o nei ruoli di customers_contoso vengono restituiti un 403 errore1. Gli utenti non autenticati vengono reindirizzati a /login.
/login	Agli utenti non autenticati viene richiesto di eseguire l'autenticazione con GitHub.
_/.auth/login/x	Poiché la regola di route disabilita l'autorizzazione X, viene restituito un 404 errore. Questo errore esegue quindi il fallback alla gestione di /index.html con un 200 codice di stato.
/logout	Gli utenti vengono disconnessi da qualsiasi provider di autenticazione.
/calendar/2021/01	Al browser viene restituito il file /calendar.html.
/specials	Il browser viene reindirizzato in modo permanente a /deal.
/data.json	File servito con il text/json tipo MIME.
/about o qualsiasi cartella che corrisponda ai modelli di routing lato client	Il file /index.html viene gestito con un 200 codice di stato.
Un file inesistente nella cartella /images/	Errore 404 .

¹ È possibile specificare una pagina di errore personalizzata usando una regola di override della risposta.

Restrizioni

Per il file di staticwebapp.config.json esistono le restrizioni seguenti.

• La dimensione massima del file è di 20 KB
• Massimo 50 ruoli distinti

Vedere l'articolo Quote per restrizioni e limitazioni generali.

Passaggi successivi

Articoli correlati

• Impostare le impostazioni a livello di applicazione e le variabili di ambiente usate dalle API back-end
• Definire le impostazioni che controllano il processo di compilazione