Sdílet prostřednictvím

Konfigurace Azure Static Web Apps

  • Článek

Konfiguraci pro Azure Static Web Apps můžete definovat v souboru staticwebapp.config.json , který řídí následující nastavení:

Poznámka:

routes.json, která byla dříve použita ke konfiguraci směrování, je zastaralá. Ke konfiguraci směrování a dalších nastavení pro statickou webovou aplikaci použijte staticwebapp.config.json , jak je popsáno v tomto článku.

Tento dokument popisuje, jak nakonfigurovat Azure Static Web Apps, což je samostatný produkt a oddělený od funkce hostování statického webu služby Azure Storage.

Umístění souboru

Doporučené umístění pro staticwebapp.config.json je ve složce nastavené jako app_location v souboru pracovního postupu. Soubor však můžete umístit do libovolné podsložky v rámci složky nastavené jako app_location. Pokud existuje krok sestavení, musíte také zajistit, aby krok sestavení vypíše soubor do kořenového adresáře output_location.

Podrobnosti najdete v ukázkovém konfiguračním souboru.

Důležité

Zastaralý soubor routes.json se ignoruje, pokud existuje staticwebapp.config.json.

Trasy

Ve statické webové aplikaci můžete definovat pravidla pro jednu nebo více tras. Pravidla směrování umožňují omezit přístup k uživatelům v konkrétních rolích nebo provádět akce, jako je přesměrování nebo přepsání. Trasy jsou definovány jako pole pravidel směrování. Příklady použití najdete v ukázkovém konfiguračním souboru .

  • Pravidla jsou definována routes v poli, i když máte pouze jednu trasu.
  • Pravidla se vyhodnocují v pořadí, v jakém se zobrazují v routes poli.
  • Vyhodnocení pravidla se zastaví při první shodě. Shoda nastane, když route vlastnost a hodnota v methods poli (pokud je zadána) odpovídají požadavku. Každý požadavek může odpovídat maximálně jednomu pravidlu.

Směrování se výrazně překrývají s koncepty ověřování (identifikace uživatele) a autorizace (přiřazování schopností uživateli). Nezapomeňte si přečíst průvodce ověřováním a autorizací společně s tímto článkem.

Definování tras

Každé pravidlo se skládá ze vzoru trasy spolu s jednou nebo více volitelnými vlastnostmi pravidla. Pravidla směrování jsou definována routes v poli. Příklady použití najdete v ukázkovém konfiguračním souboru .

Důležité

route K určení, jestli pravidlo odpovídá požadavku, se používají pouze vlastnosti a methods (pokud jsou zadané).

Vlastnost pravidla Požaduje se Default value Comment
route Yes Není k dispozici Vzor trasy požadovaný volajícím.
methods No Všechny metody Definuje pole metod požadavků, které odpovídají trase. Mezi dostupné metody patří: GET, HEAD, POST, PUT, CONNECTDELETE, OPTIONS, , TRACEa PATCH.
rewrite No Není k dispozici Definuje soubor nebo cestu vrácenou z požadavku.
  • Vzájemně se vylučují pravidlo redirect .
  • Přepis pravidel nemění umístění prohlížeče.
  • Hodnoty musí být relativní vzhledem ke kořenovému adresáři aplikace.
redirect No Není k dispozici Definuje cíl přesměrování souboru nebo cesty pro požadavek.
  • Vzájemně se vylučují pravidlo rewrite .
  • Pravidla přesměrování mění umístění prohlížeče.
  • Výchozí kód odpovědi je 302 (dočasné přesměrování), ale můžete ho 301 přepsat (trvalé přesměrování).
statusCode No 301 nebo 302 pro přesměrování Stavový kód HTTP odpovědi.
headers No Není k dispozici Sada hlaviček HTTP přidaných do odpovědi
  • Hlavičky specifické pro trasu přepíší, globalHeaders když je hlavička specifická pro trasu stejná jako globální hlavička v odpovědi.
  • Pokud chcete záhlaví odebrat, nastavte hodnotu na prázdný řetězec.
allowedRoles No anonymní Definuje pole názvů rolí požadovaných pro přístup ke trase.
  • Platné znaky zahrnují a-z, A-Z, 0-9a _.
  • Předdefinovaná role anonymousplatí pro všechny uživatele.
  • Předdefinovaná role se authenticatedvztahuje na všechny přihlášené uživatele.
  • Uživatelé musí patřit alespoň do jedné role.
  • Role se shodují podle or .
    • Pokud je uživatel v některé z uvedených rolí, udělí se přístup.
  • Jednotlivé uživatele jsou přidružené k rolím prostřednictvím pozvánek.

Každá vlastnost má v kanálu požadavku nebo odpovědi konkrétní účel.

Účel Vlastnosti
Shoda tras route, methods
Zpracování po porovnávání a autorizaci pravidla rewrite (upraví požadavek)

redirect, headers, statusCode (upravuje odpověď)
Autorizace po spárované trase allowedRoles

Určení vzorů tras

Vlastnost route může být přesná trasa nebo zástupný znak.

Přesná trasa

Pokud chcete definovat přesnou trasu, umístěte úplnou cestu k souboru do route vlastnosti.

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

Toto pravidlo odpovídá požadavkům na soubor /profile/index.html. Vzhledem k tomu , že index.html je výchozím souborem, pravidlo také odpovídá žádostem o složku (/profile nebo /profile/).

Důležité

Pokud ve vlastnosti použijete cestu ke složce (/profilenebo/profile/), nebude odpovídat požadavkům na soubor /profile/index.html.route Při ochraně trasy, která obsluhuje soubor, vždy použijte úplnou cestu k souboru, například /profile/index.html.

Vzor se zástupnými znaky

Pravidla zástupných znaků odpovídají všem požadavkům ve vzoru trasy a podporují se pouze na konci cesty. Příklady použití najdete v ukázkovém konfiguračním souboru .

Pokud chcete například implementovat trasy pro kalendářovou aplikaci, můžete přepsat všechny adresy URL, které spadají pod trasu kalendáře , aby sloužily jednomu souboru.

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

Soubor calendar.html pak může použít směrování na straně klienta k poskytování jiného zobrazení pro varianty adres URL, jako /calendar/january/1je , /calendar/2020a /calendar/overview.

Poznámka:

Vzor trasy odpovídá /calendar/* všem požadavkům v cestě /calendar/ . Nebude se však shodovat s požadavky na cesty /calendar nebo /calendar.html. Slouží /calendar* ke shodě všech požadavků, které začínají na /calendar.

Zástupné kóty můžete filtrovat podle přípony souboru. Pokud byste například chtěli přidat pravidlo, které odpovídá pouze souborům HTML v dané cestě, můžete vytvořit následující pravidlo:

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

Pokud chcete filtrovat více přípon souborů, zahrnete možnosti do složených závorek, jak je znázorněno v tomto příkladu:

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

Mezi běžné případy použití tras se zástupnými znaky patří:

  • Obsluha konkrétního souboru pro celý vzor cesty
  • Vynucení ověřovacích a autorizačních pravidel
  • Implementace specializovaných pravidel ukládání do mezipaměti

Zabezpečení tras pomocí rolí

Trasy jsou zabezpečené přidáním jednoho nebo více názvů rolí do pole pravidla allowedRoles . Příklady použití najdete v ukázkovém konfiguračním souboru .

Důležité

Pravidla směrování můžou zabezpečit pouze požadavky HTTP na trasy, které se obsluhují ze statických webových aplikací. Mnoho front-endových architektur používá směrování na straně klienta, které upravuje trasy v prohlížeči bez vydávání požadavků na Static Web Apps. Pravidla směrování nezabezpečí trasy na straně klienta. Klienti by měli volat rozhraní HTTP API pro načtení citlivých dat. Před vrácením dat se ujistěte, že rozhraní API ověřují identitu uživatele.

Ve výchozím nastavení patří každý uživatel k předdefinované anonymous roli a všichni přihlášení uživatelé jsou členy authenticated této role. Volitelně se uživatelé přidružují k vlastním rolím prostřednictvím pozvánek.

Pokud chcete například omezit trasu jenom na ověřené uživatele, přidejte do allowedRoles pole předdefinovanou authenticated roli.

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

V poli můžete podle potřeby allowedRoles vytvořit nové role. Pokud chcete omezit trasu jenom na správce, můžete v allowedRoles poli definovat vlastní roli s názvem administrator.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}
  • Máte plnou kontrolu nad názvy rolí; neexistuje žádný seznam, pro který musí vaše role dodržovat.
  • Jednotlivé uživatele jsou přidružené k rolím prostřednictvím pozvánek.

Důležité

Při zabezpečení obsahu zadejte přesné soubory, pokud je to možné. Pokud máte k zabezpečení mnoho souborů, po sdílené předponě používejte zástupné cardy. Příklad: /profile* Zabezpečuje všechny možné trasy, které začínají na /profile, včetně /profile.

Omezení přístupu k celé aplikaci

Často chcete vyžadovat ověřování pro každou trasu ve vaší aplikaci. Pokud chcete trasy uzamknout, přidejte pravidlo, které odpovídá všem trasám a zahrnuje předdefinované authenticated role v allowedRoles poli.

Následující příklad konfigurace blokuje anonymní přístup a přesměruje všechny neověřené uživatele na přihlašovací stránku Microsoft Entra.

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

Poznámka:

Ve výchozím nastavení jsou povoleni všichni předem nakonfigurovaní zprostředkovatelé identity. Pokud chcete blokovat zprostředkovatele ověřování, přečtěte si téma Ověřování a autorizace.

Náhradní trasy

Jednostrákové aplikace se často spoléhají na směrování na straně klienta. Tato pravidla směrování na straně klienta aktualizují umístění okna prohlížeče, aniž by se požadavky vrátily na server. Pokud stránku aktualizujete nebo přejdete přímo na adresy URL vygenerované pravidly směrování na straně klienta, je k poskytování příslušné stránky HTML vyžadována náhradní trasa na straně serveru. Záložní stránka se často označuje jako index.html pro vaši aplikaci na straně klienta.

Poznámka:

Pravidla směrování se na žádosti, které aktivují, navigationFallbackse nepoužijí .

Náhradní pravidlo můžete definovat přidáním oddílu navigationFallback . Následující příklad vrátí /index.html pro všechny požadavky statického souboru, které neodpovídají nasazeným souborům.

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

Můžete určit, které požadavky vracejí záložní soubor definováním filtru. V následujícím příkladu jsou požadavky na určité trasy ve složce /images a všechny soubory ve složce /css vyloučeny z vrácení záložního souboru.

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

Například s následující adresářovou strukturou by výše uvedené pravidlo záložní navigace vedlo k výsledkům podrobným v následující tabulce.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
├── about.html
└── index.html
Žádosti o... návraty... se stavem...
/asi/ Soubor /index.html . 200
/images/logo.png Soubor obrázku. 200
/images/icon.svg Soubor /index.html – protože přípona souboru svg není uvedená ve /images/*.{png,jpg,gif} filtru. 200
/images/unknown.png Chyba nebyla nalezena. 404
/css/unknown.css Chyba nebyla nalezena. 404
/css/global.css Soubor šablony stylů. 200
/about.html Stránka HTML. 200
Jakákoli jiná cesta mimo složky /images nebo /css , která neodpovídá cestě k nasazenýmu souboru. Soubor /index.html . 200

Důležité

Pokud migrujete ze zastaralého souboru routes.json, nezahrnujte do pravidel směrování starší náhradní trasu ("route": "/*").

Globální hlavičky

Tato globalHeaders část poskytuje sadu hlaviček HTTP použitých pro každou odpověď, pokud není přepsáno pravidlem hlavičky trasy, jinak se vrátí sjednocení obou hlaviček ze trasy a globálních hlaviček.

Příklady použití najdete v ukázkovém konfiguračním souboru .

Pokud chcete záhlaví odebrat, nastavte hodnotu na prázdný řetězec ("").

Mezi běžné případy použití globálních hlaviček patří:

  • Vlastní pravidla ukládání do mezipaměti
  • Zásady zabezpečení
  • Nastavení kódování
  • Konfigurace sdílení prostředků mezi zdroji (CORS)

Následující příklad implementuje vlastní konfiguraci CORS.

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

Poznámka:

Globální hlavičky nemají vliv na odpovědi rozhraní API. Hlavičky v odpovědích rozhraní API se zachovají a vrátí klientovi.

Přepsání odpovědí

Tato responseOverrides část poskytuje příležitost definovat vlastní odpověď, pokud by server jinak vrátil kód chyby. Příklady použití najdete v ukázkovém konfiguračním souboru .

K dispozici jsou následující kódy HTTP, které je možné přepsat:

Kód stavu Význam Možná příčina
400 Chybný požadavek Neplatný odkaz na pozvánku
401 Neautorizováno Požadavek na stránky s omezeným přístupem při neověřeném
403 Zakázáno
  • Uživatel je přihlášený, ale nemá role potřebné k zobrazení stránky.
  • Uživatel je přihlášený, ale modul runtime nemůže získat podrobnosti o uživateli z deklarací identity.
  • K webu s vlastními rolemi je přihlášeno příliš mnoho uživatelů, proto se modul runtime nemůže přihlásit uživatele.
404 Nenalezeno Soubor nenalezen

Následující příklad konfigurace ukazuje, jak přepsat kód chyby.

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

Platforma

Oddíl platform řídí nastavení specifická pro platformu, jako je verze modulu runtime jazyka API.

Vyberte verzi modulu runtime jazyka API.

Pokud chcete nakonfigurovat verzi modulu runtime jazyka API, nastavte apiRuntime vlastnost v platform části na jednu z následujících podporovaných hodnot.

Verze modulu runtime jazyka Operační systém Verze Azure Functions apiRuntime hodnota Datum ukončení podpory
.NET Core 3.1 Windows 3.x dotnet:3.1 sobota 3. prosince 2022
In-process .NET 6.0 Windows 4.x dotnet:6.0 -
Izolované rozhraní .NET 6.0 Windows 4.x dotnet-isolated:6.0 -
Izolované rozhraní .NET 7.0 Windows 4.x dotnet-isolated:7.0 -
Izolované rozhraní .NET 8.0 Windows 4.x dotnet-isolated:8.0 -
Node.js 12.x Linux 3.x node:12 sobota 3. prosince 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 (Preview) 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

Pokud chcete změnit verzi modulu runtime v aplikaci .NET, změňte TargetFramework hodnotu v souboru csproj . Pokud v souboru staticwebapp.config.json nastavíte apiRuntime hodnotu, ujistěte se, že hodnota odpovídá tomu, co definujete v souboru csproj.

Následující příklad ukazuje, jak aktualizovat TargetFramework element pro NET 8.0 jako verzi modulu runtime jazyka API v souboru csproj .

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

Node.js

Následující příklad konfigurace ukazuje, jak pomocí apiRuntime vlastnosti vybrat Node.js 16 jako verzi rozhraní API Language Runtime v souboru staticwebapp.config.json .

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

Python

Následující příklad konfigurace ukazuje, jak pomocí apiRuntime vlastnosti vybrat Python 3.8 jako verzi modulu runtime jazyka API v souboru staticwebapp.config.json .

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

Sítě

Oddíl networking řídí konfiguraci sítě statické webové aplikace. Pokud chcete omezit přístup k aplikaci, zadejte seznam povolených bloků IP adres v allowedIpRangessouboru . Další informace o počtu povolených bloků IP adres najdete v tématu Kvóty ve službě Azure Static Web Apps.

Poznámka:

Konfigurace sítě je dostupná jenom v plánu Azure Static Web Apps Standard.

Definujte každý blok adresy IPv4 v zápisu CIDR (Classless Inter-Domain Routing). Další informace o zápisu CIDR najdete v tématu Směrování mezi doménou bez tříd. Každý blok adresy IPv4 může znamenat veřejný nebo privátní adresní prostor. Pokud chcete povolit přístup jenom z jedné IP adresy, můžete použít /32 blok CIDR.

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

Pokud je zadán jeden nebo více bloků IP adres, požadavky pocházející z IP adres, které neodpovídají hodnotě v allowedIpRanges přístupu, jsou odepřeny.

Kromě bloků IP adres můžete také v poli zadat značky allowedIpRanges služeb, které omezují provoz na určité služby Azure.

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

Ověřování

Podrobnosti o tom, jak omezit trasy na ověřené uživatele, najdete v tématu Zabezpečení tras pomocí rolí.

Zakázání mezipaměti pro ověřené cesty

Pokud nastavíte ruční integraci se službou Azure Front Door, možná budete chtít zakázat ukládání do mezipaměti pro zabezpečené trasy. S povoleným hraničním zařízením na podnikové úrovni je ukládání do mezipaměti pro zabezpečené trasy zakázané.

Pokud chcete zakázat ukládání do mezipaměti služby Azure Front Door pro zabezpečené trasy, přidejte "Cache-Control": "no-store" do definice hlavičky trasy.

Příklad:

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

Předávání brány

Tato forwardingGateway část konfiguruje, jak se statická webová aplikace přistupuje z brány pro předávání, jako je služba Content Delivery Network (CDN) nebo Azure Front Door.

Poznámka:

Konfigurace brány pro předávání je dostupná jenom v plánu Azure Static Web Apps Standard.

Povolené přesměrované hostitele

Seznam allowedForwardedHosts určuje, které názvy hostitelů se mají přijmout v hlavičce X-Forwarded-Host . Pokud je v seznamu odpovídající doména, Static Web Apps použije X-Forwarded-Host hodnotu při vytváření adres URL pro přesměrování, například po úspěšném přihlášení.

Aby služba Static Web Apps fungovala správně za bránou předávání, musí požadavek z brány obsahovat správný název hostitele v X-Forwarded-Host hlavičce a stejný název hostitele musí být uvedený v allowedForwardedHosts.

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

Pokud se hlavička X-Forwarded-Host neshoduje s hodnotou v seznamu, požadavky budou pořád úspěšné, ale hlavička se v odpovědi nepoužije.

Povinná záhlaví

Povinná hlavička jsou hlavičky HTTP, které se musí odesílat s každou žádostí na váš web. Jedním z použití požadovaných hlaviček je odepření přístupu k webu, pokud nejsou v každém požadavku přítomny všechny požadované hlavičky.

Například následující konfigurace ukazuje, jak můžete přidat jedinečný identifikátor služby Azure Front Door , který omezuje přístup k vašemu webu z konkrétní instance služby Azure Front Door. Úplné podrobnosti najdete v kurzu Konfigurace služby Azure Front Door.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}
  • Páry klíč/hodnota můžou být libovolnou sadou libovolných řetězců.
  • Klíče nerozlišují malá a velká písmena.
  • V hodnotách se rozlišují malá a velká písmena.

Koncové lomítko

Koncové lomítko je / na konci adresy URL. Koncová adresa URL lomítka obvykle odkazuje na adresář na webovém serveru, zatímco lomítko indikuje soubor.

Vyhledávací weby zachází se dvěma adresami URL samostatně bez ohledu na to, jestli se jedná o soubor nebo adresář. Pokud se stejný obsah vykreslí na obou těchto adresách URL, váš web obsluhuje duplicitní obsah, který může negativně ovlivnit optimalizaci vyhledávacího webu (SEO). Při explicitní konfiguraci použije Static Web Apps sadu normalizace adres URL a pravidel přesměrování, která pomáhají zlepšit výkon vašeho webu a výkon SEO.

Pro každou z dostupných konfigurací platí následující pravidla normalizace a přesměrování:

Always

Při nastavování trailingSlash se alwaysvšechny požadavky, které neobsahují koncové lomítko, přesměrují na koncovou adresu URL lomítka. Například /contact je přesměrován na /contact/.

"trailingSlash": "always"
Žádosti o... návraty... se stavem... a cesta...
/asi Soubor /about/index.html 301 /asi/
/asi/ Soubor /about/index.html 200 /asi/
/about/index.html Soubor /about/index.html 301 /asi/
/privacy.html Soubor /privacy.html 301 /soukromí/

Nikdy

Při nastavování trailingSlash se nevervšechny požadavky končící na koncové lomítko přesměrují na nezábradlí adresu URL lomítka. Například /contact/ je přesměrován na /contact.

"trailingSlash": "never"
Žádosti o... návraty... se stavem... a cesta...
/asi Soubor /about/index.html 200 /asi
/asi/ Soubor /about/index.html 301 /asi
/about/index.html Soubor /about/index.html 301 /asi
/privacy.html Soubor /privacy.html 301 /soukromí

Automaticky

Když nastavíte trailingSlash hodnotu auto, všechny požadavky na složky se přesměrují na adresu URL s koncovým lomítkem. Všechny požadavky na soubory se přesměrují na adresu URL bez zábradlí lomítka.

"trailingSlash": "auto"
Žádosti o... návraty... se stavem... a cesta...
/asi Soubor /about/index.html 301 /asi/
/asi/ Soubor /about/index.html 200 /asi/
/about/index.html Soubor /about/index.html 301 /asi/
/privacy.html Soubor /privacy.html 301 /soukromí

Pokud chcete dosáhnout optimálního výkonu webu, nakonfigurujte koncovou strategii lomítka pomocí některého z alwaysrežimů . neverauto

Ve výchozím nastavení platí, že pokud trailingSlash je konfigurace vynechána, statická webová aplikace použije následující pravidla:

Žádosti o... návraty... se stavem... a cesta...
/asi Soubor /about/index.html 200 /asi
/asi/ Soubor /about/index.html 200 /asi/
/about/index.html Soubor /about/index.html 200 /about/index.html
/privacy.html Soubor /privacy.html 200 /privacy.html

Vzorový konfigurační soubor

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

Na základě výše uvedené konfigurace si projděte následující scénáře.

Žádosti o... výsledky v...
/profil Ověřeným uživatelům se obsluhuje soubor /profile/index.html . Neověřené uživatele se přesměrují na /login pravidlem 401 přepsání odpovědi.
/admin, /admin/, nebo /admin/index.html Ověřeným uživatelům v roli správce se obsluhuje soubor /admin/index.html . Ověření uživatelé, kteří nejsou v roli správce, se obsluhují s chybou 4031. Neověřené uživatele se přesměrují na /login
/images/logo.png Slouží k obrázku s vlastním pravidlem mezipaměti, ve kterém je maximální věk přes 182 dnů (15 770 000 sekund).
/api/admin GET do rozhraní API se odesílají požadavky od ověřených uživatelů v roli registrovaných uživatelů. Ověření uživatelé, kteří nejsou v roli registrovaných uživatelů a neověřené uživatele, se zobrazí 401 chyba.

POST, , PUTPATCHa DELETE žádosti od ověřených uživatelů v roli správce se odesílají do rozhraní API. Ověření uživatelé, kteří nejsou v roli správce a neověřené uživatele, se zobrazí 401 chyba.
/customers/contoso Ověřeným uživatelům, kteří patří správci nebo customers_contoso rolím, se obsluhují soubor /customers/contoso/index.html. Ověření uživatelé, kteří nejsou správci nebo customers_contoso role, se obsluhují s chybou403 1. Neověřené uživatele se přesměrují na /login.
/přihlášení do systému Neověřené uživatele jsou vyzváni k ověření pomocí GitHubu.
_/.auth/login/x Vzhledem k tomu, že pravidlo trasy zakáže autorizaci X, vrátí se 404 chyba. Tato chyba se pak vrátí do obsluhy /index.html se stavovým kódem 200 .
/odhlášení od sítě Uživatelé jsou odhlášeni od libovolného zprostředkovatele ověřování.
/calendar/2021/01 Prohlížeč se obsluhuje soubor /calendar.html .
/speciály Prohlížeč je trvale přesměrován na /deals.
/data.json Soubor obsluhoval typ text/json MIME.
/about nebo jakákoli složka, která odpovídá vzorům směrování na straně klienta Soubor /index.html se obsluhuje se stavovým kódem 200 .
Neexistující soubor ve složce /images/ Chyba 404 .

1 Pomocí pravidla přepsání odpovědi můžete zadat vlastní chybovou stránku.

Omezení

Pro soubor staticwebapp.config.json existují následující omezení.

  • Maximální velikost souboru je 20 kB
  • Maximálně 50 jedinečných rolí

Obecná omezení a omezení najdete v článku Kvóty.

Další kroky

Nastavení ověřování a autorizace