Bagikan melalui


Konfigurasikan Azure Static Web Apps

Anda dapat menentukan konfigurasi untuk Azure Static Web Apps dalam file staticwebapp.config.json , yang mengontrol pengaturan berikut:

Catatan

routes.json yang sebelumnya digunakan untuk mengonfigurasi routing sudah tidak digunakan lagi. Gunakan staticwebapp.config.json seperti yang dijelaskan dalam artikel ini untuk mengonfigurasi perutean dan pengaturan lain untuk aplikasi web statis Anda.

Dokumen ini menjelaskan cara mengonfigurasi Azure Static Web Apps, yang merupakan produk mandiri dan terpisah dari fitur hosting situs web statis Azure Storage.

Lokasi file

Lokasi yang direkomendasikan untuk staticwebapp.config.json berada di folder yang diatur sebagai app_location di file alur kerja. Namun, Anda dapat menempatkan file di subfolder apa pun dalam folder yang ditetapkan sebagai app_location. Selain itu, jika ada langkah build, Anda harus memastikan bahwa file tersebut dihasilkan ke direktori root dari lokasi keluaran.

Lihat file contoh konfigurasi untuk detailnya.

Penting

File routes.json yang tidak digunakan lagi diabaikan jikastaticwebapp.config.json ada.

Rute

Anda dapat menentukan aturan untuk satu atau beberapa rute di aplikasi web statis Anda. Aturan rute memungkinkan Anda membatasi akses ke pengguna dalam peran tertentu atau melakukan tindakan seperti pengalihan atau penulisan ulang. Rute didefinisikan sebagai array aturan pengelompokan rute. Lihat file konfigurasi contoh untuk contoh pemakaiannya.

  • Aturan ditentukan dalam array routes, bahkan jika Anda hanya memiliki satu rute.
  • Aturan dievaluasi dalam urutan saat muncul dalam routes array.
  • Evaluasi aturan berhenti saat kecocokan pertama. Kecocokan route terjadi ketika properti dan nilai dalam methods array (jika ditentukan) cocok dengan permintaan. Setiap permintaan dapat mencocokkan paling banyak satu aturan.

Masalah perutean secara signifikan tumpang tindih dengan konsep autentikasi (mengidentifikasi pengguna) dan otorisasi (menetapkan kemampuan kepada pengguna). Pastikan untuk membaca panduan autentikasi dan otorisasi bersama dengan artikel ini.

Menentukan rute

Setiap aturan terdiri dari pola rute, bersama satu atau beberapa properti aturan opsional. Aturan rute ditentukan dalam array routes. Lihat file konfigurasi contoh untuk contoh pemakaiannya.

Penting

route Hanya properti dan methods (jika ditentukan) yang digunakan untuk menentukan apakah aturan cocok dengan permintaan.

Properti aturan Wajib Nilai bawaan Komentar
route Ya n/a Pola rute yang diminta oleh penelepon.
  • Wildcards didukung di akhir jalur rute.
    • Misalnya, rute /admin* cocok dengan rute apa pun yang dimulai dengan /admin.
methods Tidak Semua metode Menentukan array metode permintaan yang cocok dengan rute. Metode yang tersedia meliputi: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, dan PATCH.
rewrite Tidak n/a Menentukan file atau path yang dikembalikan dari permintaan.
  • Tidak dapat digabungkan dengan aturan redirect.
  • Menulis ulang aturan tidak mengubah lokasi browser.
  • Nilai harus relatif terhadap akar aplikasi.
redirect Tidak n/a Menentukan tujuan pengalihan file atau path untuk suatu permintaan.
  • Saling eksklusif terhadap aturan rewrite.
  • Aturan pengalihan mengubah lokasi browser.
  • Kode respons default adalah 302 (pengalihan sementara), tetapi Anda dapat mengesampingkannya dengan 301 (pengalihan permanen).
statusCode Tidak 301 atau 302 untuk pengalihan Kode status HTTP dari respons.
headers Tidak n/a Kumpulan header HTTP ditambahkan ke respons.
  • Header khusus rute menggantikan globalHeaders ketika header khusus rute sama dengan header global di respons.
  • Untuk menghapus header, atur nilai ke string kosong.
allowedRoles Tidak anonim Menentukan array nama peran yang diperlukan untuk mengakses rute.
  • Karakter yang valid termasuk a-z, A-Z, 0-9, dan _.
  • Peran bawaan, anonymous, berlaku untuk semua pengguna.
  • Peran bawaan, authenticated, berlaku untuk pengguna yang masuk.
  • Pengguna harus menjadi bagian dari setidaknya satu peran.
  • Peran dicocokkan berdasarkan OR.
    • Jika pengguna menjadi bagian dari salah satu peran yang tercantum, akses akan diberikan.
  • Tiap-tiap pengguna dikaitkan dengan peran melalui undangan.

Setiap properti memiliki tujuan khusus dalam alur permintaan/respons.

Tujuan Properti
Pencocokan rute route, methods
Proses setelah aturan dicocokkan dan diotorisasi rewrite (memodifikasi permintaan)

redirect, headers, statusCode (memodifikasi respons)
Otorisasi setelah rute dicocokkan allowedRoles

Tentukan pola rute

Properti route dapat menjadi rute yang tepat atau pola wildcard.

Rute yang tepat

Untuk menentukan rute yang tepat, tempatkan jalur lengkap file di route properti .

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

Aturan ini cocok dengan permintaan untuk file /profile/index.html. Karena index.html adalah file default, aturan juga cocok dengan permintaan untuk folder (/profile atau /profile/).

Penting

Jika Anda menggunakan jalur folder (/profile atau /profile/) di properti route, jalur tersebut tidak akan cocok dengan permintaan untuk file /profile/index.html. Saat melindungi rute yang melayani file, selalu gunakan jalur lengkap file seperti /profile/index.html.

Pola karakter pengganti

Aturan kartubebas cocok dengan semua permintaan dalam pola rute, dan hanya didukung di akhir jalur. Lihat file konfigurasi contoh untuk contoh pemakaiannya.

Misalnya, untuk menerapkan rute untuk aplikasi kalender, Anda dapat menulis ulang semua URL yang termasuk dalam rute kalender untuk melayani satu file.

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

File calendar.html kemudian dapat menggunakan perutean sisi klien untuk menyajikan tampilan yang berbeda untuk variasi URL seperti /calendar/january/1, /calendar/2020, dan /calendar/overview.

Catatan

Polanya /calendar/* cocok dengan semua permintaan di bawah jalur /calendar/. Namun, ini tidak akan cocok dengan permintaan untuk jalur /kalender atau /calendar.html. Gunakan /calendar* untuk mencocokkan semua permintaan yang dimulai dengan /calendar.

Anda dapat memfilter kecocokan wildcard berdasarkan ekstensi file. Misalnya, jika Anda ingin menambahkan aturan yang hanya cocok dengan file HTML di jalur tertentu, Anda dapat membuat aturan berikut:

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

Untuk memfilter beberapa ekstensi file, Anda menyertakan opsi-opsinya dalam kurung kurawal, seperti yang diperlihatkan dalam contoh ini:

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

Kasus penggunaan umum untuk rute wildcard meliputi:

  • Menyajikan file tertentu untuk seluruh pola jalur
  • Menegakkan aturan autentikasi dan otorisasi
  • Menerapkan aturan cache khusus

Rute aman dengan peran

Rute diamankan dengan menambahkan satu atau beberapa nama peran ke dalam larik allowedRoles di aturan. Lihat file konfigurasi contoh untuk contoh pemakaiannya.

Penting

Aturan perutean hanya dapat mengamankan permintaan HTTP ke rute yang dilayani dari Aplikasi Web Statis. Banyak kerangka kerja front-end menggunakan perutean sisi klien yang memodifikasi rute di browser tanpa mengeluarkan permintaan ke Static Web Apps. Aturan perutean tidak menjamin keamanan rute sisi klien. Klien harus memanggil API HTTP untuk mengambil data sensitif. Pastikan API memvalidasi identitas pengguna sebelum mengembalikan data.

Secara default, setiap pengguna termasuk dalam peran anonymous bawaan, dan semua pengguna yang masuk adalah anggota peran authenticatedtersebut. Jika ingin, pengguna dikaitkan dengan peran khusus melalui undangan.

Misalnya, untuk membatasi sebuah rute agar hanya dapat diakses oleh pengguna yang diautentikasi, tambahkan peran authenticated bawaan ke larik allowedRoles.

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

Anda dapat membuat peran baru sesuai kebutuhan dalam larik allowedRoles. Untuk membatasi sebuah rute hanya ke administrator, Anda dapat menentukan peran Anda sendiri yang bernama administrator, dalam array allowedRoles.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}
  • Anda memiliki kendali penuh atas nama peran; tidak ada daftar yang harus dipatuhi oleh peran Anda.
  • Tiap-tiap pengguna dikaitkan dengan peran melalui undangan.

Penting

Saat mengamankan konten, tentukan file yang tepat jika memungkinkan. Jika Anda memiliki banyak file untuk diamankan, gunakan wildcard setelah prefix yang sama. Misalnya: /profile* mengamankan semua kemungkinan rute yang dimulai dengan /profile, termasuk /profile.

Membatasi akses ke seluruh aplikasi

Anda sering kali ingin memerlukan autentikasi untuk setiap rute dalam aplikasi Anda. Untuk mengamankan rute Anda, tambahkan aturan yang cocok dengan semua rute dan sertakan peran bawaan authenticated dalam array allowedRoles.

Contoh konfigurasi berikut memblokir akses anonim dan mengalihkan semua pengguna yang tidak diautentikasi ke halaman masuk Microsoft Entra.

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

Catatan

Secara default, semua penyedia identitas yang telah dikonfigurasi sebelumnya diaktifkan. Untuk memblokir penyedia autentikasi, lihat Autentikasi dan otorisasi.

Rute cadangan

Aplikasi Halaman Tunggal sering mengandalkan routing sisi klien. Aturan perutean sisi klien ini memperbarui lokasi jendela browser tanpa membuat permintaan kembali ke server. Jika Anda me-refresh halaman, atau langsung masuk ke URL yang dihasilkan oleh aturan perutean sisi klien, rute fallback sisi server diperlukan untuk melayani halaman HTML yang sesuai. Halaman fallback sering ditunjuk sebagai index.html untuk aplikasi sisi klien Anda.

Catatan

Aturan rute tidak diterapkan pada permintaan yang memicu navigationFallback.

Anda dapat menentukan aturan fallback dengan menambahkan bagian navigationFallback. Contoh berikut mengembalikan /index.html untuk semua permintaan file statis yang tidak cocok dengan file yang disebarkan.

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

Anda dapat mengontrol permintaan mana yang menampilkan file fallback dengan menentukan filter. Di contoh berikut, permintaan untuk rute tertentu dalam folder /images dan semua file dalam folder /css dikecualikan dari menampilkan file fallback.

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

Misalnya, dengan struktur direktori berikut, aturan fallback navigasi di atas akan menghasilkan hasil yang dirinci dalam tabel berikut.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
├── about.html
└── index.html
Permintaan ke... mengembalikan... dengan status...
/about/ File /index.html . 200
/images/logo.png File gambar. 200
/images/icon.svg File /index.html - karena ekstensi file svg tidak tercantum dalam /images/*.{png,jpg,gif} filter. 200
/images/unknown.png Kesalahan: file tidak ditemukan. 404
/css/unknown.css Kesalahan file tidak ditemukan. 404
/css/global.css File lembar gaya. 200
/about.html Halaman HTML. 200
Jalur lain di luar folder /images atau /css yang tidak cocok dengan jalur ke file yang disebarkan. File /index.html . 200

Penting

Jika Anda melakukan migrasi dari file routes.json yang tidak digunakan lagi, jangan menyertakan rute fallback warisan ("route": "/*") di aturan perutean.

Header global

Bagian ini globalHeaders menyediakan sekumpulan header HTTP yang diterapkan ke setiap respons, kecuali jika ada aturan header rute yang menimpanya. Jika tidak ada aturan seperti itu, maka perpaduan antara header dari rute dan header global akan digunakan.

Lihat file konfigurasi contoh untuk contoh pemakaiannya.

Untuk menghapus header, atur nilai ke string kosong ("").

Beberapa kasus penggunaan umum untuk header global meliputi:

  • Aturan penembolokan (caching) kustom
  • Kebijakan keamanan
  • Pengaturan kode
  • Konfigurasi berbagi sumber daya lintas asal (CORS)

Contoh berikut mengimplementasikan konfigurasi CORS kustom.

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

Catatan

Header global tidak memengaruhi respons API. Header dalam respons API dipertahankan dan dikembalikan ke klien.

Pengesampingan respons

Bagian responseOverrides ini memberikan kesempatan untuk menentukan respons kustom ketika server mengembalikan kode kesalahan. Lihat file konfigurasi contoh untuk contoh pemakaiannya.

Kode HTTP berikut ini tersedia untuk diambil alih:

Kode status Makna Kemungkinan penyebab
400 Permintaan Tidak Valid Tautan undangan tidak valid
401 Tidak diizinkan Permintaan ke halaman terbatas saat tidak diautentikasi
403 Terlarang
  • Pengguna masuk tetapi tidak memiliki peran yang diperlukan untuk melihat halaman.
  • Pengguna masuk tetapi runtime tidak bisa mendapatkan detail pengguna dari klaim identitas mereka.
  • Terlalu banyak pengguna yang masuk ke situs dengan peran kustom, oleh karena itu runtime tidak dapat memasukkan pengguna.
404 Tidak ditemukan File tidak ditemukan

Contoh konfigurasi berikut menunjukkan cara mengambil alih kode galat.

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

Platform

Bagian platform ini mengatur pengaturan spesifik platform, seperti versi runtime bahasa API.

Pilih versi runtime bahasa API

Untuk mengonfigurasi versi runtime bahasa API, atur apiRuntime properti di bagian platform ke salah satu nilai yang didukung berikut.

Versi runtime bahasa Sistem operasi Versi Azure Functions apiRuntime nilai Tanggal akhir dukungan
.NET Core 3.1 Windows 3.x dotnet:3.1 Sabtu, 03 Desember 2022
.NET 6.0 dalam proses Windows 4.x dotnet:6.0 30 April 2025
.NET 8.0 dalam proses Windows 4.x dotnet:8.0 -
.NET 6.0 terisolasi Windows 4.x dotnet-isolated:6.0 30 April 2025
.NET 7.0 terisolasi Windows 4.x dotnet-isolated:7.0 30 April 2025
.NET 8.0 terisolasi Windows 4.x dotnet-isolated:8.0 -
.NET 9.0 terisolasi Windows 4.x dotnet-isolated:9.0 -
Node.js 12.x Linux 3.x node:12 Sabtu, 03 Desember 2022
Node.js 14.x Linux 4.x node:14 30 April 2025
Node.js 16.x Linux 4.x node:16 30 April 2025
Node.js 18.x Linux 4.x node:18 31 Mei 2025
Node.js 20.x Linux 4.x node:20 -
Python 3.8 Linux 4.x python:3.8 30 April 2025
Python 3.9 Linux 4.x python:3.9 -
Python 3.10 Linux 4.x python:3.10 -
Python 3.11 Linux 4.x python:3.11 -

.NET

Untuk mengubah versi runtime di aplikasi .NET, ubah TargetFramework nilai dalam file csproj . Meskipun opsional, jika Anda menetapkan nilai dalam apiRuntime, pastikan nilainya cocok dengan apa yang Anda tentukan dalam file csproj.

Contoh berikut menunjukkan cara memperbarui TargetFramework elemen untuk NET 8.0 sebagai versi runtime bahasa API dalam file csproj .

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

Node.js

Contoh konfigurasi berikut menunjukkan cara menggunakan apiRuntime properti untuk memilih Node.js 16 sebagai versi runtime bahasa API dalam file staticwebapp.config.json .

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

Python

Contoh konfigurasi berikut menunjukkan cara menggunakan apiRuntime properti untuk memilih Python 3.8 sebagai versi runtime bahasa API dalam file staticwebapp.config.json .

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

Jaringan

Bagian networking mengontrol konfigurasi jaringan aplikasi web statik Anda. Untuk membatasi akses ke aplikasi Anda, tentukan daftar blok alamat IP yang diizinkan di allowedIpRanges. Untuk informasi selengkapnya tentang jumlah blok alamat IP yang diizinkan, lihat Kuota di Azure Static Web Apps.

Catatan

Konfigurasi jaringan hanya tersedia dalam Azure Static Web Apps paket Standar.

Tentukan setiap blok alamat IPv4 dalam notasi Classless Inter-Domain Routing (CIDR). Untuk mempelajari notasi CIDR lebih lanjut, lihat Perutean Antar-Domain Tanpa Kelas. Setiap blok alamat IPv4 dapat menunjukkan ruang alamat publik atau pribadi. Jika Anda hanya ingin mengizinkan akses dari satu Alamat IP, Anda dapat menggunakan /32 blok CIDR.

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

Ketika satu atau beberapa blok alamat IP ditentukan, permintaan yang berasal dari alamat IP yang tidak cocok dengan suatu nilai dalam allowedIpRanges akan ditolak aksesnya.

Selain pemblokiran alamat IP, Anda juga dapat menentukan tag layanan dalam array allowedIpRanges untuk membatasi lalu lintas ke layanan Azure tertentu.

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

Autentikasi

Untuk detail tentang cara membatasi rute ke pengguna yang diautentikasi, lihat Mengamankan rute dengan peran.

Menonaktifkan cache untuk jalur terautentikasi

Jika Anda menyiapkan integrasi manual dengan Azure Front Door, Anda mungkin ingin menonaktifkan cache untuk rute aman Anda. Dengan edge kelas enterprise diaktifkan, penyimpanan sementara sudah dinonaktifkan untuk rute Anda yang aman.

Untuk menonaktifkan cache Azure Front Door untuk rute aman, tambahkan "Cache-Control": "no-store" ke definisi header rute.

Contohnya:

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

Gateway Penerusan

Bagian forwardingGateway mengonfigurasi cara mengakses aplikasi web statis dari gateway penerusan seperti Content Delivery Network (CDN) atau Azure Front Door.

Catatan

Konfigurasi gateway penerusan hanya tersedia pada rencana Standar Azure Static Web Apps.

Host yang Diizinkan Diteruskan

Daftar allowedForwardedHosts menentukan nama host mana yang akan diterima di header X-Forwarded-Host. Jika domain yang cocok ada dalam daftar, Static Web Apps menggunakan X-Forwarded-Host nilai saat membuat URL pengalihan, seperti setelah berhasil masuk.

Agar Static Web Apps berfungsi dengan baik di belakang gateway penerusan, permintaan dari gateway harus menyertakan nama host yang benar di header X-Forwarded-Host dan nama host yang sama harus dicantumkan di allowedForwardedHosts.

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

Jika header X-Forwarded-Host tidak cocok dengan nilai dalam daftar, permintaan tetap berhasil, tetapi header tidak digunakan dalam tanggapan.

Header yang dibutuhkan

Header wajib adalah header HTTP yang harus dikirim bersama setiap permintaan ke situs Anda. Salah satu penggunaan header yang diperlukan adalah untuk menolak akses ke situs kecuali semua header yang diperlukan ada di setiap permintaan.

Misalnya, konfigurasi berikut menunjukkan bagaimana Anda dapat menambahkan pengenal unik untuk Azure Front Door yang membatasi akses ke situs Anda dari instance Azure Front Door tertentu. Lihat tutorial Konfigurasi Azure Front Door untuk detail lengkap.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}
  • Pasangan kunci/nilai dapat berupa rangkaian string arbitrer apa pun
  • Kunci tidak sensitif terhadap huruf besar-kecil
  • Nilai bersifat peka terhadap huruf besar/kecil

Garis miring di akhir

Garis miring berikutnya adalah / di akhir URL. Secara konvensional, URL dengan garis miring akhir mengacu pada direktori di server web, sedangkan URL tanpa garis miring akhir menunjukkan file.

Mesin pencari memperlakukan dua URL secara terpisah, terlepas dari apakah itu file atau direktori. Ketika konten yang sama dirender di kedua URL ini, situs web Anda melayani konten duplikat, yang dapat berdampak negatif pada pengoptimalan mesin pencari (SEO). Saat dikonfigurasi secara eksplisit, Static Web Apps menerapkan serangkaian normalisasi URL dan aturan pengalihan yang membantu meningkatkan performa situs web dan performa SEO Anda.

Aturan normalisasi dan pengalihan berikut berlaku untuk setiap konfigurasi yang tersedia:

Selalu

Saat Anda mengatur trailingSlash ke always, semua permintaan yang tidak menyertakan garis miring berikutnya dialihkan ke URL garis miring berikutnya. Misalnya, /contact dialihkan ke /contact/.

"trailingSlash": "always"
Permintaan ke... mengembalikan... dengan status... dan jalur...
/about File /about/index.html 301 /about/
/about/ File /about/index.html 200 /about/
/about/index.html File /about/index.html 301 /about/
/privacy.html File /privacy.html 301 /Privasi/

Tidak pernah

Saat mengatur trailingSlash ke never, semua permintaan yang berakhiran garis miring akan dialihkan ke URL tanpa garis miring di akhir. Misalnya, /contact/ dialihkan ke /contact.

"trailingSlash": "never"
Permintaan ke... mengembalikan... dengan status... dan jalur...
/tentang File /about/index.html 200 /tentang
/about/ File /about/index.html 301 /tentang
/about/index.html File /about/index.html 301 /tentang
/privacy.html File /privacy.html 301 /Privasi

Otomatis

Saat Anda mengatur trailingSlash ke auto, semua permintaan ke folder dialihkan ke sebuah URL dengan garis miring di akhir. Semua permintaan ke file dialihkan ke URL tanpa garis miring di akhir.

"trailingSlash": "auto"
Permintaan ke... mengembalikan... dengan status... dan jalur...
/about File /about/index.html 301 /about/
/about/ File /about/index.html 200 /about/
/about/index.html File /about/index.html 301 /about/
/privacy.html File /privacy.html 301 /Privasi

Untuk performa situs web yang optimal, konfigurasikan strategi garis miring di akhir menggunakan salah satu mode always, never, atau auto.

Secara default, ketika konfigurasi trailingSlash dihilangkan, Static Web Apps menerapkan aturan berikut:

Permintaan ke... mengembalikan... dengan status... dan jalur...
/tentang File /about/index.html 200 /tentang
/about/ File /about/index.html 200 /about/
/about/index.html File /about/index.html 200 /about/index.html
/privacy.html File /privacy.html 200 /privacy.html

Contoh file konfigurasi

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

Berdasarkan konfigurasi di atas, tinjau skenario berikut.

Permintaan ke... menghasilkan...
/profile File /profile/index.html disajikan kepada pengguna terautentikasi. Pengguna yang tidak diautentikasi dialihkan ke /login oleh aturan penggantian respons 401.
/admin, /admin/, atau /admin/index.html Pengguna terautentikasi dalam peran administrator diberi file /admin/index.html. Pengguna terautentikasi yang tidak berada dalam peran administrator diberi 403 kesalahan1. Pengguna yang tidak diautentikasi dialihkan ke /login
/images/logo.png Melayani gambar dengan aturan cache khusus di mana usia maksimalnya sedikit lebih dari 182 hari (15.770.000 detik).
/api/admin Permintaan GET dari pengguna terautentikasi dalam peran registeredusers dikirim ke API. Pengguna terautentikasi yang tidak dalam peran registeredusers dan pengguna yang tidak diautentikasi diberi kesalahan 401.

Permintaan POST, PUT, PATCH, dan DELETE dari pengguna terautentikasi dalam peran administrator dikirim ke API. Pengguna terautentikasi yang tidak berada dalam peran administrator dan pengguna yang tidak diautentikasi diberi kesalahan 401.
/customers/contoso Pengguna terautentikasi yang termasuk dalam peran administrator atau customers_contoso diberii file /customers/contoso/index.html. Pengguna terautentikasi yang tidak berada dalam peran administrator atau customers_contoso diberi 403kesalahan1. Pengguna yang tidak diautentikasi dialihkan ke /login.
/login Pengguna yang tidak terautentikasi diminta melakukan autentikasi dengan GitHub.
_/.auth/login/x Karena aturan rute menonaktifkan otorisasi X, kesalahan 404 dikembalikan. Kesalahan ini kemudian kembali ke penyajian /index.html dengan 200 kode status.
/logout Pengguna log keluar dari penyedia autentikasi mana pun.
/calendar/2021/01 File /calendar.html disajikan kepada browser.
/specials Browser secara permanen dialihkan ke /deals.
/data.json File disajikan dengan tipe MIME text/json.
/about, atau folder apa pun yang cocok dengan pola perutean sisi klien File /index.html dilayani dengan kode status 200.
File yang tidak ada di folder /images/ Sebuah kesalahan 404.

1 Anda bisa menyediakan halaman kesalahan kustom menggunakan aturan ambil alih respons.

Batasan

Batasan berikut ini ada untuk file staticwebapp.config.json.

  • Ukuran file maksimum adalah 20 KB
  • Maksimal 50 peran berbeda

Lihat artikel Kuota untuk batasan dan pembatasan umum.

Langkah berikutnya