Configurare App Web statiche di Azure

  • Articolo

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

Nota

routes.json usato in precedenza per configurare il routing è deprecato. Usare staticwebapp.config.json come descritto in questo articolo per configurare il routing e altre impostazioni per l'app Web statica.

Questo documento descrive come configurare App Web statiche di Azure, ovvero un prodotto autonomo e separato dalla funzionalità di hosting di siti Web statici di Archiviazione di Azure.

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.

Importante

Il file di routes.json deprecato viene ignorato se esiste un staticwebapp.config.json.

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.

Importante

Solo le route proprietà e methods (se specificate) vengono utilizzate per determinare se una regola corrisponde a una richiesta.

Proprietà regola Richiesto Valore predefinito 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/).

Importante

Se si usa un percorso di cartella (/profile o /profile/) nella route proprietà , non corrisponderà alle richieste per il file /profile/index.html. Quando si protegge una route che gestisce un file, usare sempre il percorso completo del file, /profile/index.htmlad esempio .

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.

Nota

Un modello di route di /calendar/* corrisponde a tutte le richieste nel percorso /calendar/ . Tuttavia, non corrisponde alle richieste per i percorsi /calendar o /calendar.html. Usare /calendar* per trovare le corrispondenze con tutte le richieste che iniziano con /calendar.

È 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.

Importante

Le regole di routing possono proteggere solo le richieste HTTP alle route gestite da App Web statiche. Molti framework front-end usano il routing lato client che modifica le route nel browser senza inviare richieste a App Web statiche. Le regole di routing non proteggono le route lato client. I client devono chiamare le API HTTP per recuperare i dati sensibili. Assicurarsi che le API convalidano l'identità di un utente prima di restituire i dati.

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.

Importante

Quando si protegge il contenuto, specificare i file esatti quando possibile. Se sono presenti molti file da proteggere, usare i caratteri jolly dopo un prefisso condiviso. Ad esempio: /profile* protegge tutte le possibili route che iniziano con /profile, incluso /profile.

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"
    }
  }
}

Nota

Per impostazione predefinita, tutti i provider di identità preconfigurati sono abilitati. Per bloccare un provider di autenticazione, vedere Autenticazione e autorizzazione.

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
│
└── index.html
Richieste a... Restituisce... 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
Qualsiasi altro file all'esterno delle cartelle /images o /css File /index.html . 200

Importante

Se si esegue la migrazione dal file di routes.json deprecato, non includere la route di fallback legacy ("route": "/*") nelle regole di routing.

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"
  }
}

Nota

Le intestazioni globali non influiscono sulle risposte api. Le intestazioni nelle risposte API vengono mantenute e restituite al client.

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 Funzioni di Azure versione Valore apiRuntime Data di fine supporto
.NET Core 3.1 Windows 3.x dotnet:3.1 sabato 3 dicembre 2022
.NET 6.0 in-process Windows 4.x dotnet:6.0 -
Isolato .NET 6.0 Windows 4.x dotnet-isolated:6.0 -
Isolato .NET 7.0 Windows 4.x dotnet-isolated:7.0 -
.NET 8.0 isolato Windows 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 -
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.

Nota

La configurazione di rete è disponibile solo nel piano App Web statiche di Azure Standard.

Definire ogni blocco di indirizzi IPv4 nella notazione CIDR (Classless Inter-Domain Routing). Per altre informazioni sulla notazione CIDR, vedere Routing interdominio senza classi. 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 un rete per la distribuzione di contenuti (rete CDN) o frontdoor di Azure.

Nota

La configurazione del gateway di inoltro è disponibile solo nel piano App Web statiche di Azure Standard.

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. Convenzionalmente, l'URL della barra finale fa riferimento a una directory nel server Web, mentre una barra non predefinito 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 (edizione Standard O). 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 del sito Web e edizione Standard O.

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... Restituisce... 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/
/Contattare File /contact.html 301 /Contattare/
/Contattare/ File /contact.html 200 /Contattare/
/contact.html File /contact.html 301 /Contattare/

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... Restituisce... 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
/Contattare File /contact.html 200 /Contattare
/Contattare/ File /contact.html 301 /Contattare
/contact.html File /contact.html 301 /Contattare

Automatica

Quando si imposta su trailingSlashauto, 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... Restituisce... 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/
/Contattare File /contact.html 200 /Contattare
/Contattare/ File /contact.html 301 /Contattare
/contact.html File /contact.html 301 /Contattare

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... Restituisce... 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
/Contattare File /contact.html 200 /Contattare
/Contattare/ File /contact.html 301 /Contattare
/contact.html File /contact.html 200 /contact.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/twitter",
      "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/twitter Poiché la regola di route disabilita l'autorizzazione twitter , 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 .

1 È 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

Configurare l'autenticazione e l'autorizzazione