Azure Static Web Apps configureren
U kunt de configuratie voor Azure Static Web Apps definiëren in het staticwebapp.config.json-bestand , waarmee de volgende instellingen worden beheerd:
- Routering
- Verificatie
- Autorisatie
- Terugvalregels
- HTTP-antwoordoverschrijvingen
- Globale HTTP-headerdefinities
- Aangepaste MIME-typen
- Netwerken
Notitie
routes.json die eerder is gebruikt om routering te configureren, is afgeschaft. Gebruik staticwebapp.config.json zoals beschreven in dit artikel om routering en andere instellingen voor uw statische web-app te configureren.
In dit document wordt beschreven hoe u Azure Static Web Apps configureert. Dit is een zelfstandig product en gescheiden van de functie voor het hosten van statische websites van Azure Storage.
Bestandslocatie
De aanbevolen locatie voor de staticwebapp.config.json bevindt zich in de map die is ingesteld als het app_location
in het werkstroombestand. U kunt het bestand echter in elke submap in de map die is ingesteld als de app_location
. Als er een buildstap is, moet u er bovendien voor zorgen dat het bestand wordt uitgevoerd in de hoofdmap van de output_location.
Zie het voorbeeldconfiguratiebestand voor meer informatie.
Belangrijk
Het afgeschafte routes.json bestand wordt genegeerd als er een staticwebapp.config.json bestaat.
Routes
U kunt regels definiëren voor een of meer routes in uw statische web-app. Met routeregels kunt u de toegang tot gebruikers in specifieke rollen beperken of acties uitvoeren, zoals omleiden of herschrijven. Routes worden gedefinieerd als een matrix van routeringsregels. Zie het voorbeeldconfiguratiebestand voor gebruiksvoorbeelden.
- Regels worden gedefinieerd in de
routes
matrix, zelfs als u slechts één route hebt. - Regels worden geëvalueerd in de volgorde zoals ze worden weergegeven in de
routes
matrix. - De regelevaluatie stopt bij de eerste overeenkomst. Er treedt een overeenkomst op wanneer de
route
eigenschap en een waarde in demethods
matrix (indien opgegeven) overeenkomen met de aanvraag. Elke aanvraag kan overeenkomen met maximaal één regel.
De routeringsproblemen overlappen aanzienlijk met verificatie (de gebruiker identificeren) en autorisatieconcepten (het toewijzen van mogelijkheden aan de gebruiker). Lees de verificatie- en autorisatiehandleiding samen met dit artikel.
Routes definiëren
Elke regel bestaat uit een routepatroon, samen met een of meer van de optionele regeleigenschappen. Routeregels worden gedefinieerd in de routes
matrix. Zie het voorbeeldconfiguratiebestand voor gebruiksvoorbeelden.
Belangrijk
Alleen de route
en methods
(indien opgegeven) eigenschappen worden gebruikt om te bepalen of een regel overeenkomt met een aanvraag.
Regeleigenschap | Vereist | Default value | Comment |
---|---|---|---|
route |
Ja | N.v.t. | Het routepatroon dat door de beller is aangevraagd.
|
methods |
Nee | Alle methoden | Definieert een matrix van aanvraagmethoden die overeenkomen met een route. Beschikbare methoden zijn: GET , HEAD , POST , , DELETE PUT , CONNECT , , OPTIONS , , TRACE en PATCH . |
rewrite |
Nee | N.v.t. | Hiermee definieert u het bestand of pad dat door de aanvraag wordt geretourneerd.
|
redirect |
Nee | N.v.t. | Hiermee definieert u het omleidingsdoel voor een bestand of pad voor een aanvraag. |
statusCode |
Nee | 301 of 302 voor omleidingen |
De HTTP-statuscode van het antwoord. |
headers |
Nee | N.v.t. | Set HTTP-headers toegevoegd aan het antwoord.
|
allowedRoles |
Nee | anoniem | Hiermee definieert u een matrix met rolnamen die vereist zijn voor toegang tot een route.
|
Elke eigenschap heeft een specifiek doel in de aanvraag-/antwoordpijplijn.
Doel | Eigenschappen |
---|---|
Routes vergelijken | route , methods |
Verwerken nadat een regel is vergeleken en geautoriseerd | rewrite (wijzigt de aanvraag)redirect , , headers statusCode (wijzigt het antwoord) |
Autoriseren nadat een route is vergeleken | allowedRoles |
Routepatronen opgeven
De route
eigenschap kan een exacte route of een jokertekenpatroon zijn.
Exacte route
Als u een exacte route wilt definiëren, plaatst u het volledige pad van het bestand in de route
eigenschap.
{
"route": "/profile/index.html",
"allowedRoles": ["authenticated"]
}
Deze regel komt overeen met aanvragen voor het bestand /profile/index.html. Omdat index.html het standaardbestand is, komt de regel ook overeen met aanvragen voor de map (/profile of /profile/).
Belangrijk
Als u een mappad (/profile
of /profile/
) in de route
eigenschap gebruikt, komen deze niet overeen met aanvragen voor het bestand /profile/index.html. Wanneer u een route beveiligt die een bestand bedient, gebruikt u altijd het volledige pad van het bestand, zoals /profile/index.html
.
Jokertekenpatroon
Jokertekenregels komen overeen met alle aanvragen in een routepatroon en worden alleen ondersteund aan het einde van een pad. Zie het voorbeeldconfiguratiebestand voor gebruiksvoorbeelden.
Als u bijvoorbeeld routes voor een agendatoepassing wilt implementeren, kunt u alle URL's die onder de agendaroute vallen, herschrijven om één bestand te verwerken.
{
"route": "/calendar*",
"rewrite": "/calendar.html"
}
Het calendar.html-bestand kan vervolgens routering aan de clientzijde gebruiken om een andere weergave te gebruiken voor URL-variaties zoals /calendar/january/1
, /calendar/2020
en /calendar/overview
.
Notitie
Een routepatroon komt /calendar/*
overeen met alle aanvragen onder het /calendar/ -pad. Het komt echter niet overeen met aanvragen voor de paden /agenda of /calendar.html. Gebruik /calendar*
deze optie om alle aanvragen te vinden die beginnen met /calendar.
U kunt jokertekenovereenkomsten filteren op bestandsextensie. Als u bijvoorbeeld een regel wilt toevoegen die alleen overeenkomt met HTML-bestanden in een bepaald pad, kunt u de volgende regel maken:
{
"route": "/articles/*.html",
"headers": {
"Cache-Control": "public, max-age=604800, immutable"
}
}
Als u wilt filteren op meerdere bestandsextensies, neemt u de opties op in accolades, zoals wordt weergegeven in dit voorbeeld:
{
"route": "/images/thumbnails/*.{png,jpg,gif}",
"headers": {
"Cache-Control": "public, max-age=604800, immutable"
}
}
Veelvoorkomende gebruiksvoorbeelden voor jokertekenroutes zijn:
- Een specifiek bestand leveren voor een volledig padpatroon
- Verificatie- en autorisatieregels afdwingen
- Gespecialiseerde regels voor opslaan in cache implementeren
Routes beveiligen met rollen
Routes worden beveiligd door een of meer rolnamen toe te voegen aan de matrix van allowedRoles
een regel. Zie het voorbeeldconfiguratiebestand voor gebruiksvoorbeelden.
Belangrijk
Routeringsregels kunnen alleen HTTP-aanvragen beveiligen voor routes die worden geleverd vanuit Static Web Apps. Veel front-endframeworks maken gebruik van routering aan de clientzijde die routes in de browser wijzigt zonder aanvragen naar Static Web Apps uit te geven. Routeringsregels beveiligen geen routes aan de clientzijde. Clients moeten HTTP-API's aanroepen om gevoelige gegevens op te halen. Zorg ervoor dat API's de identiteit van een gebruiker valideren voordat gegevens worden geretourneerd.
Standaard behoort elke gebruiker tot de ingebouwde anonymous
rol en zijn alle aangemelde gebruikers lid van de authenticated
rol. Gebruikers zijn optioneel gekoppeld aan aangepaste rollen via uitnodigingen.
Als u bijvoorbeeld een route wilt beperken tot alleen geverifieerde gebruikers, voegt u de ingebouwde authenticated
rol toe aan de allowedRoles
matrix.
{
"route": "/profile*",
"allowedRoles": ["authenticated"]
}
U kunt zo nodig nieuwe rollen maken in de allowedRoles
matrix. Als u een route wilt beperken tot alleen beheerders, kunt u uw eigen rol met de naam administrator
definiëren in de allowedRoles
matrix.
{
"route": "/admin*",
"allowedRoles": ["administrator"]
}
- U hebt volledige controle over rolnamen; er is geen lijst waaraan uw rollen moeten voldoen.
- Afzonderlijke gebruikers zijn gekoppeld aan rollen via uitnodigingen.
Belangrijk
Wanneer u inhoud beveiligt, geeft u indien mogelijk exacte bestanden op. Als u veel bestanden wilt beveiligen, gebruikt u jokertekens na een gedeeld voorvoegsel. Bijvoorbeeld: /profile*
beveiligt alle mogelijke routes die beginnen met /profile, inclusief /profile.
Toegang tot hele toepassing beperken
U wilt vaak verificatie vereisen voor elke route in uw toepassing. Als u uw routes wilt vergrendelen, voegt u een regel toe die overeenkomt met alle routes en de ingebouwde authenticated
rol in de allowedRoles
matrix opneemt.
Met de volgende voorbeeldconfiguratie worden anonieme toegang geblokkeerd en worden alle niet-geverifieerde gebruikers omgeleid naar de aanmeldingspagina van Microsoft Entra.
{
"routes": [
{
"route": "/*",
"allowedRoles": ["authenticated"]
}
],
"responseOverrides": {
"401": {
"statusCode": 302,
"redirect": "/.auth/login/aad"
}
}
}
Notitie
Standaard zijn alle vooraf geconfigureerde id-providers ingeschakeld. Als u een verificatieprovider wilt blokkeren, raadpleegt u Verificatie en autorisatie.
Terugvalroutes
Toepassingen met één pagina zijn vaak afhankelijk van routering aan de clientzijde. Deze routeringsregels aan de clientzijde werken de vensterlocatie van de browser bij zonder dat er aanvragen naar de server worden verzonden. Als u de pagina vernieuwt of rechtstreeks naar URL's gaat die zijn gegenereerd door routeringsregels aan de clientzijde, is een terugvalroute aan de serverzijde vereist voor de juiste HTML-pagina. De terugvalpagina wordt vaak aangeduid als index.html voor uw app aan de clientzijde.
Notitie
Routeregels worden niet toegepast op aanvragen die worden geactiveerd navigationFallback
.
U kunt een terugvalregel definiëren door een navigationFallback
sectie toe te voegen. In het volgende voorbeeld worden /index.html geretourneerd voor alle statische bestandsaanvragen die niet overeenkomen met een geïmplementeerd bestand.
{
"navigationFallback": {
"rewrite": "/index.html"
}
}
U kunt bepalen welke aanvragen het terugvalbestand retourneren door een filter te definiëren. In het volgende voorbeeld worden aanvragen voor bepaalde routes in de map /images en alle bestanden in de map /css uitgesloten van het retourneren van het terugvalbestand.
{
"navigationFallback": {
"rewrite": "/index.html",
"exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
}
}
Met de volgende mapstructuur zou de bovenstaande terugvalregel voor navigatie bijvoorbeeld resulteren in de resultaten die in de volgende tabel worden beschreven.
├── images
│ ├── logo.png
│ ├── headshot.jpg
│ └── screenshot.gif
│
├── css
│ └── global.css
│
├── about.html
└── index.html
Aanvragen voor... | Retourneert... | met de status... |
---|---|---|
/over/ | Het bestand /index.html . | 200 |
/images/logo.png | Het afbeeldingsbestand. | 200 |
/images/icon.svg | Het bestand /index.html - omdat de svg-bestandsextensie niet wordt vermeld in het /images/*.{png,jpg,gif} filter. |
200 |
/images/unknown.png | Fout bij bestand niet gevonden. | 404 |
/css/unknown.css | Fout bij bestand niet gevonden. | 404 |
/css/global.css | Het opmaakmodelbestand. | 200 |
/about.html | De HTML-pagina. | 200 |
Een ander pad buiten de /images - of /css-mappen die niet overeenkomen met het pad naar een geïmplementeerd bestand. | Het bestand /index.html . | 200 |
Belangrijk
Als u migreert van het afgeschafte routes.json bestand, neemt u de verouderde terugvalroute ("route": "/*"
) niet op in de routeringsregels.
Algemene headers
De globalHeaders
sectie bevat een set HTTP-headers die worden toegepast op elk antwoord, tenzij deze worden overschreven door een regel voor de routeheader , anders wordt de samenvoeging van zowel de headers van de route als de globale headers geretourneerd.
Zie het voorbeeldconfiguratiebestand voor gebruiksvoorbeelden.
Als u een koptekst wilt verwijderen, stelt u de waarde in op een lege tekenreeks (""
).
Enkele veelvoorkomende gebruiksvoorbeelden voor algemene headers zijn:
- Aangepaste regels voor opslaan in cache
- Beveiligingsbeleid
- Coderingsinstellingen
- CORS-configuratie (Cross-Origin Resource Sharing)
In het volgende voorbeeld wordt een aangepaste CORS-configuratie geïmplementeerd.
{
"globalHeaders": {
"Access-Control-Allow-Origin": "https://example.com",
"Access-Control-Allow-Methods": "POST, GET, OPTIONS"
}
}
Notitie
Globale headers hebben geen invloed op API-antwoorden. Headers in API-antwoorden blijven behouden en worden geretourneerd naar de client.
Antwoordoverschrijvingen
De responseOverrides
sectie biedt een mogelijkheid om een aangepast antwoord te definiëren wanneer de server anders een foutcode zou retourneren. Zie het voorbeeldconfiguratiebestand voor gebruiksvoorbeelden.
De volgende HTTP-codes zijn beschikbaar om te overschrijven:
Statuscode | Betekenis | Mogelijke oorzaak |
---|---|---|
400 | Ongeldige aanvraag | Ongeldige uitnodigingskoppeling |
401 | Niet geautoriseerd | Aanvraag voor beperkte pagina's terwijl niet-geverifieerd |
403 | Verboden |
|
404 | Niet gevonden | Bestand niet gevonden |
In de volgende voorbeeldconfiguratie ziet u hoe u een foutcode overschrijft.
{
"responseOverrides": {
"400": {
"rewrite": "/invalid-invitation-error.html"
},
"401": {
"statusCode": 302,
"redirect": "/login"
},
"403": {
"rewrite": "/custom-forbidden-page.html"
},
"404": {
"rewrite": "/custom-404.html"
}
}
}
Platform
De platform
sectie bepaalt platformspecifieke instellingen, zoals de runtimeversie van de API-taal.
De runtimeversie van de API-taal selecteren
Als u de runtimeversie van de API-taal wilt configureren, stelt u de apiRuntime
eigenschap in de platform
sectie in op een van de volgende ondersteunde waarden.
Versie van taalruntime | Besturingssysteem | Azure Functions-versie | apiRuntime waarde |
Einddatum van ondersteuning |
---|---|---|---|---|
.NET Core 3.1 | Windows | 3.x | dotnet:3.1 |
zaterdag 3 december 2022 |
.NET 6.0 in-process | Windows | 4.x | dotnet:6.0 |
- |
.NET 6.0 geïsoleerd | Windows | 4.x | dotnet-isolated:6.0 |
- |
.NET 7.0 geïsoleerd | Windows | 4.x | dotnet-isolated:7.0 |
- |
.NET 8.0 geïsoleerd | Windows | 4.x | dotnet-isolated:8.0 |
- |
Node.js 12.x | Linux | 3.x | node:12 |
zaterdag 3 december 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
Als u de runtimeversie in een .NET-app wilt wijzigen, wijzigt u de TargetFramework
waarde in het csproj-bestand . Als u een apiRuntime
waarde instelt in het bestand staticwebapp.config.json , controleert u of de waarde overeenkomt met wat u in het csproj-bestand definieert.
In het volgende voorbeeld ziet u hoe u het TargetFramework
element voor NET 8.0 bijwerkt als de runtimeversie van de API-taal in het csproj-bestand .
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
...
</PropertyGroup>
...
Node.js
In de volgende voorbeeldconfiguratie ziet u hoe u de apiRuntime
eigenschap gebruikt om Node.js 16 te selecteren als de runtimeversie van de API-taal in het staticwebapp.config.json-bestand .
{
...
"platform": {
"apiRuntime": "node:16"
}
...
}
Python
In de volgende voorbeeldconfiguratie ziet u hoe u de apiRuntime
eigenschap gebruikt om Python 3.8 te selecteren als de runtimeversie van de API-taal in het staticwebapp.config.json-bestand .
{
...
"platform": {
"apiRuntime": "python:3.8"
}
...
}
Netwerken
De networking
sectie bepaalt de netwerkconfiguratie van uw statische web-app. Als u de toegang tot uw app wilt beperken, geeft u een lijst op met toegestane IP-adresblokken in allowedIpRanges
. Zie Quota in Azure Static Web Apps voor meer informatie over het aantal toegestane IP-adresblokken.
Notitie
Netwerkconfiguratie is alleen beschikbaar in het Azure Static Web Apps Standard-abonnement.
Definieer elk IPv4-adresblok in CIDR-notatie (Classless Inter-Domain Routing). Zie Classless Inter-Domain Routing voor meer informatie over CIDR-notatie. Elk IPv4-adresblok kan duiden op een openbare of persoonlijke adresruimte. Als u alleen toegang vanaf één IP-adres wilt toestaan, kunt u het /32
CIDR-blok gebruiken.
{
"networking": {
"allowedIpRanges": [
"10.0.0.0/24",
"100.0.0.0/32",
"192.168.100.0/22"
]
}
}
Wanneer een of meer IP-adresblokken zijn opgegeven, worden aanvragen die afkomstig zijn van IP-adressen die niet overeenkomen met een waarde allowedIpRanges
, geweigerd.
Naast IP-adresblokken kunt u ook servicetags in de allowedIpRanges
matrix opgeven om verkeer naar bepaalde Azure-services te beperken.
"networking": {
"allowedIpRanges": ["AzureFrontDoor.Backend"]
}
Verificatie
Voor standaardverificatieproviders zijn geen instellingen in het configuratiebestand vereist.
Aangepaste verificatieproviders gebruiken de
auth
sectie van het instellingenbestand.
Zie Routes beveiligen met rollen voor meer informatie over het beperken van routes tot geverifieerde gebruikers.
Cache uitschakelen voor geverifieerde paden
Als u handmatige integratie met Azure Front Door instelt, kunt u caching uitschakelen voor uw beveiligde routes. Als edge op bedrijfsniveau is ingeschakeld, is caching al uitgeschakeld voor uw beveiligde routes.
Als u Azure Front Door-caching voor beveiligde routes wilt uitschakelen, voegt u deze toe "Cache-Control": "no-store"
aan de definitie van de routeheader.
Voorbeeld:
{
"route": "/members",
"allowedRoles": ["authenticated, members"],
"headers": {
"Cache-Control": "no-store"
}
}
Doorsturende gateway
In forwardingGateway
de sectie wordt geconfigureerd hoe een statische web-app wordt geopend vanuit een doorstuurgateway, zoals een CDN (Content Delivery Network) of Azure Front Door.
Notitie
De configuratie van de doorstuurgateway is alleen beschikbaar in het Azure Static Web Apps Standard-abonnement.
Toegestane doorgestuurde hosts
De allowedForwardedHosts
lijst geeft aan welke hostnamen moeten worden geaccepteerd in de header X-Forwarded-Host . Als een overeenkomend domein in de lijst staat, gebruikt Static Web Apps de waarde bij het X-Forwarded-Host
maken van omleidings-URL's, zoals na een geslaagde aanmelding.
Om statische web-apps correct te laten functioneren achter een doorstuurgateway, moet de aanvraag van de gateway de juiste hostnaam in de X-Forwarded-Host
header bevatten en moet dezelfde hostnaam worden vermeld in allowedForwardedHosts
.
"forwardingGateway": {
"allowedForwardedHosts": [
"example.org",
"www.example.org",
"staging.example.org"
]
}
Als de X-Forwarded-Host
header niet overeenkomt met een waarde in de lijst, slagen de aanvragen nog steeds, maar wordt de header niet gebruikt in het antwoord.
Vereiste headers
Vereiste headers zijn HTTP-headers die bij elke aanvraag naar uw site moeten worden verzonden. Een van de vereiste headers is om de toegang tot een site te weigeren, tenzij alle vereiste headers aanwezig zijn in elke aanvraag.
In de volgende configuratie ziet u bijvoorbeeld hoe u een unieke id voor Azure Front Door kunt toevoegen die de toegang tot uw site beperkt vanaf een specifiek Azure Front Door-exemplaar. Zie de zelfstudie Azure Front Door configureren voor meer informatie.
"forwardingGateway": {
"requiredHeaders": {
"X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
}
}
- Sleutel-/waardeparen kunnen elke set willekeurige tekenreeksen zijn
- Sleutels zijn niet hoofdlettergevoelig
- Waarden zijn hoofdlettergevoelig
Afsluitende slash
Een afsluitende slash is het /
einde van een URL. Conventioneel verwijst een afsluitende slash-URL naar een map op de webserver, terwijl een niet-gerailde slash een bestand aangeeft.
Zoekmachines behandelen de twee URL's afzonderlijk, ongeacht of het een bestand of map is. Wanneer dezelfde inhoud wordt weergegeven op beide URL's, dient uw website dubbele inhoud, wat negatieve invloed kan hebben op zoekmachineoptimalisatie (SEO). Wanneer deze expliciet is geconfigureerd, past Static Web Apps een set URL-normalisatie- en omleidingsregels toe waarmee de prestaties en SEO-prestaties van uw website worden verbeterd.
De volgende normalisatie- en omleidingsregels zijn van toepassing op elk van de beschikbare configuraties:
Altijd
Wanneer u dit instelt trailingSlash
always
, worden alle aanvragen die geen afsluitende slash bevatten, omgeleid naar een afsluitende slash-URL. Wordt bijvoorbeeld /contact
omgeleid naar /contact/
.
"trailingSlash": "always"
Aanvragen voor... | Retourneert... | met de status... | en pad... |
---|---|---|---|
/over | Het bestand /about/index.html | 301 |
/over/ |
/over/ | Het bestand /about/index.html | 200 |
/over/ |
/about/index.html | Het bestand /about/index.html | 301 |
/over/ |
/privacy.html | Het bestand /privacy.html | 301 |
/privacy/ |
Nooit
Als u dit instelt trailingSlash
never
, worden alle aanvragen die eindigen op een afsluitende slash omgeleid naar een niet-railende slash-URL. Wordt bijvoorbeeld /contact/
omgeleid naar /contact
.
"trailingSlash": "never"
Aanvragen voor... | Retourneert... | met de status... | en pad... |
---|---|---|---|
/over | Het bestand /about/index.html | 200 |
/over |
/over/ | Het bestand /about/index.html | 301 |
/over |
/about/index.html | Het bestand /about/index.html | 301 |
/over |
/privacy.html | Het bestand /privacy.html | 301 |
/privacy |
Auto
Wanneer u deze instelt trailingSlash
auto
, worden alle aanvragen naar mappen omgeleid naar een URL met een afsluitende slash. Alle aanvragen voor bestanden worden omgeleid naar een niet-railing-slash-URL.
"trailingSlash": "auto"
Aanvragen voor... | Retourneert... | met de status... | en pad... |
---|---|---|---|
/over | Het bestand /about/index.html | 301 |
/over/ |
/over/ | Het bestand /about/index.html | 200 |
/over/ |
/about/index.html | Het bestand /about/index.html | 301 |
/over/ |
/privacy.html | Het bestand /privacy.html | 301 |
/privacy |
Voor optimale websiteprestaties configureert u een afsluitende slash-strategie met behulp van een van de always
, never
of auto
modi.
Wanneer de trailingSlash
configuratie wordt weggelaten, past Static Web Apps standaard de volgende regels toe:
Aanvragen voor... | Retourneert... | met de status... | en pad... |
---|---|---|---|
/over | Het bestand /about/index.html | 200 |
/over |
/over/ | Het bestand /about/index.html | 200 |
/over/ |
/about/index.html | Het bestand /about/index.html | 200 |
/about/index.html |
/privacy.html | Het bestand /privacy.html | 200 |
/privacy.html |
Voorbeeld van configuratiebestand
{
"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"
}
}
Bekijk de volgende scenario's op basis van de bovenstaande configuratie.
Aanvragen voor... | resulteert in... |
---|---|
/profiel | Geverifieerde gebruikers worden het /profile/index.html-bestand geleverd. Niet-geverifieerde gebruikers worden omgeleid naar /login door de regel voor het overschrijven van het 401 antwoord. |
/admin, /admin/, of /admin/index.html | Geverifieerde gebruikers in de beheerdersrol worden geleverd aan het /admin/index.html-bestand . Geverifieerde gebruikers die niet de beheerdersrol hebben , krijgen een 403 fout1. Niet-geverifieerde gebruikers worden omgeleid naar /login |
/images/logo.png | Dient de afbeelding met een aangepaste cacheregel waarbij de maximale leeftijd iets meer dan 182 dagen is (15.770.000 seconden). |
/api/admin | GET aanvragen van geverifieerde gebruikers in de rol geregistreerde gebruikers worden verzonden naar de API. Geverifieerde gebruikers die zich niet in de rol van geregistreerde gebruikers bevinden en niet-geverifieerde gebruikers krijgen een 401 foutmelding.POST , PUT , PATCH en DELETE aanvragen van geverifieerde gebruikers in de beheerdersrol worden verzonden naar de API. Geverifieerde gebruikers die zich niet in de beheerdersrol bevinden en niet-geverifieerde gebruikers worden een 401 fout weergegeven. |
/customers/contoso | Geverifieerde gebruikers die deel uitmaken van de beheerder of customers_contoso rollen, worden het /customers/contoso/index.html-bestand geleverd. Geverifieerde gebruikers die zich niet in de beheerders- of customers_contoso-rollen bevinden, krijgen een 403 fout1. Niet-geverifieerde gebruikers worden omgeleid naar /login. |
/inloggen | Niet-geverifieerde gebruikers worden aangeroepen om te verifiëren met GitHub. |
_/.auth/login/x | Omdat de routeregel X-autorisatie uitschakelt, wordt er een 404 fout geretourneerd. Deze fout valt vervolgens terug op het leveren van /index.html met een 200 statuscode. |
/Logout | Gebruikers worden afgemeld bij een verificatieprovider. |
/calendar/2021/01 | De browser wordt het /calendar.html-bestand geleverd. |
/Specials | De browser wordt permanent omgeleid naar /deals. |
/data.json | Het bestand wordt geleverd met het text/json MIME-type. |
/about of een map die overeenkomt met routeringspatronen aan clientzijde | Het bestand /index.html wordt geleverd met een 200 statuscode. |
Een niet-bestaand bestand in de map /images/ | Een 404 fout. |
1 U kunt een aangepaste foutpagina opgeven met behulp van een regel voor het overschrijven van antwoorden.
Beperkingen
De volgende beperkingen gelden voor het staticwebapp.config.json-bestand .
- De maximale bestandsgrootte is 20 kB
- Maximaal 50 afzonderlijke rollen
Zie het artikel Quota voor algemene beperkingen en beperkingen.