Aracılığıyla paylaş

Azure Static Web Apps'i yapılandırma

  • Makale

Azure Static Web Apps yapılandırmasını aşağıdaki ayarları denetleyen staticwebapp.config.json dosyasında tanımlayabilirsiniz:

Not

Daha önce yönlendirmeyi yapılandırmak için kullanılan routes.json kullanım dışı bırakıldı. Statik web uygulamanızın yönlendirmesini ve diğer ayarlarını yapılandırmak için bu makalede açıklandığı gibi staticwebapp.config.json kullanın.

Bu belgede, tek başına bir ürün olan ve Azure Depolama'nın statik web sitesi barındırma özelliğinden ayrı olan Azure Static Web Apps'in nasıl yapılandırıldığı açıklanmaktadır.

Dosya konumu

staticwebapp.config.json için önerilen konum, iş akışı dosyasında olarak app_location ayarlanan klasördedir. Ancak, dosyayı olarak ayarlanan app_locationklasör içindeki herhangi bir alt klasöre yerleştirebilirsiniz. Ayrıca, bir derleme adımı varsa, derleme adımının dosyayı output_location köküne çıkışından emin olmanız gerekir.

Ayrıntılar için örnek yapılandırma dosyasına bakın.

Önemli

Bir staticwebapp.config.json varsa, kullanım dışı bırakılan routes.json dosyası yoksayılır.

Rotalar

Statik web uygulamanızda bir veya daha fazla yol için kurallar tanımlayabilirsiniz. Yol kuralları, belirli rollerdeki kullanıcılara erişimi kısıtlamanıza veya yeniden yönlendirme veya yeniden yazma gibi eylemler gerçekleştirmenize olanak tanır. Yollar, bir yönlendirme kuralları dizisi olarak tanımlanır. Kullanım örnekleri için örnek yapılandırma dosyasına bakın.

  • Tek bir yolunuz olsa bile kurallar dizide routes tanımlanır.
  • Kurallar dizide göründükleri routes sırada değerlendirilir.
  • Kural değerlendirmesi ilk eşleşmede durur. Özellik ve dizideki methods bir değer (belirtildiyse) istekle eşleştiğinde route eşleşme oluşur. Her istek en fazla bir kuralla eşleşebilir.

Yönlendirme, kimlik doğrulaması (kullanıcıyı tanımlama) ve yetkilendirme (kullanıcıya yetenek atama) kavramlarıyla önemli ölçüde çakışıyor. Bu makaleyle birlikte kimlik doğrulama ve yetkilendirme kılavuzunu okuduğunuzdan emin olun.

Yolları tanımlama

Her kural, isteğe bağlı bir veya daha fazla kural özelliğiyle birlikte bir yol düzeninden oluşur. Yol kuralları dizide routes tanımlanır. Kullanım örnekleri için örnek yapılandırma dosyasına bakın.

Önemli

Kuralın bir istekle route eşleşip eşleşmediğini belirlemek için yalnızca ve methods (belirtilmişse) özellikleri kullanılır.

Kural özelliği Zorunlu Default value Comment
route Yes yok Çağıran tarafından istenen yol deseni.
methods Hayır Tüm yöntemler Bir yolla eşleşen bir istek yöntemleri dizisi tanımlar. Kullanılabilir yöntemler şunlardır: GET, HEAD, POST, PUT, DELETE, , CONNECT, OPTIONS, TRACEve PATCH.
rewrite Hayır yok İstekten döndürülen dosyayı veya yolu tanımlar.
  • Bir kuralı birbirini dışlar redirect .
  • Yeniden yazma kuralları tarayıcının konumunu değiştirmez.
  • Değerler uygulamanın köküne göre olmalıdır.
redirect Hayır yok bir istek için dosya veya yol yeniden yönlendirme hedefini tanımlar.
  • Bir kuralı birbirini dışlar rewrite .
  • Yeniden yönlendirme kuralları tarayıcının konumunu değiştirir.
  • Varsayılan yanıt kodu bir 302 (geçici yeniden yönlendirmedir) ancak (kalıcı yeniden yönlendirme) ile 301 geçersiz kılabilirsiniz.
statusCode Hayır 301 veya 302 yeniden yönlendirmeler için Yanıtın HTTP durum kodu .
headers Hayır yok Yanıta eklenen HTTP üst bilgileri kümesi.
  • Yola özgü üst bilgiler, yola özgü üst bilgi yanıttaki genel üst bilgiyle aynı olduğunda geçersiz kılar globalHeaders .
  • Üst bilgiyi kaldırmak için değeri boş bir dize olarak ayarlayın.
allowedRoles Hayır Anonim Bir yola erişmek için gereken rol adları dizisini tanımlar.
  • Geçerli karakterler , , A-Z0-9ve _karakterlerini içerira-z.
  • Yerleşik rolü, anonymoustüm kullanıcılar için geçerlidir.
  • Yerleşik rolü, authenticatedoturum açmış tüm kullanıcılar için geçerlidir.
  • Kullanıcılar en az bir role ait olmalıdır.
  • Roller, VEYA temelinde eşleştirilir.
    • Bir kullanıcı listelenen rollerden herhangi birindeyse erişim verilir.
  • Tek tek kullanıcılar davetler aracılığıyla rollerle ilişkilendirilir.

Her özelliğin istek/yanıt işlem hattında belirli bir amacı vardır.

Purpose Properties
Yolları eşleştir route, methods
Kural eşleştirildikten ve yetkilendirildikten sonra işleme rewrite (isteği değiştirir)

redirect, headers, statusCode (yanıtı değiştirir)
Bir yol eşleştirildikten sonra yetkilendirme allowedRoles

Yol desenlerini belirtme

route özelliği tam bir yol veya joker karakter deseni olabilir.

Tam yol

Tam bir yol tanımlamak için, dosyanın tam yolunu özelliğine route yerleştirin.

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

Bu kural /profile/index.html dosyasının istekleriyle eşleşir. index.html varsayılan dosya olduğundan, kural klasör (/profile veya /profile/) istekleriyle de eşleşir.

Önemli

Özelliğinde route bir klasör yolu (/profile veya /profile/) kullanırsanız, /profile/index.html dosyasının istekleriyle eşleşmez. Bir dosyaya hizmet eden bir yolu korurken, her zaman gibi /profile/index.htmldosyanın tam yolunu kullanın.

Joker karakter deseni

Joker karakter kuralları bir yol düzenindeki tüm isteklerle eşleşir ve yalnızca yolun sonunda desteklenir. Kullanım örnekleri için örnek yapılandırma dosyasına bakın.

Örneğin, bir takvim uygulamasının yollarını uygulamak için, tek bir dosyaya hizmet vermek üzere takvim yolunun altındaki tüm URL'leri yeniden yazabilirsiniz.

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

calendar.html dosyası daha sonra, , /calendar/2020ve /calendar/overviewgibi /calendar/january/1URL varyasyonları için farklı bir görünüm sunmak üzere istemci tarafı yönlendirmeyi kullanabilir.

Not

Yol deseni /calendar/* /calendar/ yolu altındaki tüm isteklerle eşleşir. Ancak, /calendar veya /calendar.html yolları için isteklerle eşleşmez. /calendar ile başlayan tüm istekleri eşleştirmek için kullanın/calendar*.

Joker karakter eşleşmelerini dosya uzantısına göre filtreleyebilirsiniz. Örneğin, belirli bir yolda yalnızca HTML dosyalarıyla eşleşen bir kural eklemek isterseniz aşağıdaki kuralı oluşturabilirsiniz:

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

Birden çok dosya uzantısını filtrelemek için, bu örnekte gösterildiği gibi küme ayraçlarına seçenekleri eklersiniz:

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

Joker karakterler için yaygın kullanım örnekleri şunlardır:

  • Yol düzeninin tamamı için belirli bir dosya sunma
  • Kimlik doğrulaması ve yetkilendirme kurallarını zorunlu tutma
  • Özel önbelleğe alma kuralları uygulama

Rollerle yolların güvenliğini sağlama

Yolların güvenliği, kuralın allowedRoles dizisine bir veya daha fazla rol adı eklenerek sağlanır. Kullanım örnekleri için örnek yapılandırma dosyasına bakın.

Önemli

Yönlendirme kuralları yalnızca Statik Web Uygulamalarından sunulan yollara yönelik HTTP isteklerinin güvenliğini sağlayabilir. Birçok ön uç çerçevesi, Statik Web Uygulamalarına istek göndermeden tarayıcıdaki yolları değiştiren istemci tarafı yönlendirmeyi kullanır. Yönlendirme kuralları istemci tarafı yollarının güvenliğini sağlamaz. İstemciler hassas verileri almak için HTTP API'lerini çağırmalıdır. API'lerin verileri döndürmeden önce kullanıcının kimliğini doğruladığından emin olun.

Varsayılan olarak, her kullanıcı yerleşik anonymous role aittir ve oturum açan tüm kullanıcılar rolün authenticated üyesidir. İsteğe bağlı olarak, kullanıcılar davetler aracılığıyla özel rollerle ilişkilendirilir.

Örneğin, bir yolu yalnızca kimliği doğrulanmış kullanıcılarla kısıtlamak için yerleşik rolü diziye allowedRoles ekleyinauthenticated.

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

Dizide allowedRoles gerektiğinde yeni roller oluşturabilirsiniz. Bir yolu yalnızca yöneticilerle kısıtlamak için dizide allowedRoles adlı administratorkendi rolünüzü tanımlayabilirsiniz.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}
  • Rol adları üzerinde tam denetime sahipsiniz; rollerinizin uyması gereken bir liste yok.
  • Tek tek kullanıcılar davetler aracılığıyla rollerle ilişkilendirilir.

Önemli

İçeriğin güvenliğini sağlarken, mümkün olduğunda tam dosyaları belirtin. Güvenli olacak çok sayıda dosyanız varsa, paylaşılan ön ekin ardından joker karakterler kullanın. Örneğin: /profile* /profile dahil olmak üzere /profile ile başlayan tüm olası yolların güvenliğini sağlar.

Uygulamanın tamamına erişimi kısıtlama

Genellikle uygulamanızdaki her yol için kimlik doğrulaması gerektirirsiniz. Yollarınızı kilitlemek için tüm yollarla eşleşen bir kural ekleyin ve diziye authenticated yerleşik rolü allowedRoles ekleyin.

Aşağıdaki örnek yapılandırma anonim erişimi engeller ve kimliği doğrulanmamış tüm kullanıcıları Microsoft Entra oturum açma sayfasına yönlendirir.

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

Not

Varsayılan olarak, önceden yapılandırılmış tüm kimlik sağlayıcıları etkinleştirilir. Bir kimlik doğrulama sağlayıcısını engellemek için bkz . Kimlik doğrulaması ve yetkilendirme.

Geri dönüş yolları

Tek Sayfalı Uygulamalar genellikle istemci tarafı yönlendirmeyi kullanır. Bu istemci tarafı yönlendirme kuralları, sunucuya geri istekte bulunmadan tarayıcının pencere konumunu güncelleştirir. Sayfayı yenilerseniz veya doğrudan istemci tarafı yönlendirme kuralları tarafından oluşturulan URL'lere giderseniz, uygun HTML sayfasına hizmet vermek için sunucu tarafı geri dönüş yolu gerekir. Geri dönüş sayfası genellikle istemci tarafı uygulamanız için index.html olarak belirlenir.

Not

Yol kuralları tetikleyen navigationFallbackisteklere uygulanmaz.

Bölüm ekleyerek navigationFallback bir geri dönüş kuralı tanımlayabilirsiniz. Aşağıdaki örnek, dağıtılan dosyayla eşleşmeyen tüm statik dosya istekleri için /index.html döndürür.

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

Filtre tanımlayarak hangi isteklerin geri dönüş dosyasını döndüreceğini denetleyebilirsiniz. Aşağıdaki örnekte, /images klasöründeki belirli yollar ve /css klasöründeki tüm dosyalar için istekler geri dönüş dosyasını döndürmekten hariç tutulur.

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

Örneğin, aşağıdaki dizin yapısıyla, yukarıdaki gezinti geri dönüş kuralı aşağıdaki tabloda ayrıntılı olarak belirtilen sonuçlarla sonuçlanır.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
├── about.html
└── index.html
İstekler... Döndürür... durumuyla...
/hakkında/ /index.html dosyası. 200
/images/logo.png Görüntü dosyası. 200
/images/icon.svg /index.html dosyası - svg dosya uzantısı filtrede /images/*.{png,jpg,gif} listelenmediğinden. 200
/images/unknown.png Dosya bulunamadı hatası. 404
/css/unknown.css Dosya bulunamadı hatası. 404
/css/global.css Stil sayfası dosyası. 200
/about.html HTML sayfası. 200
/images veya /css klasörleri dışında dağıtılan bir dosyanın yoluyla eşleşmeyen başka bir yol. /index.html dosyası. 200

Önemli

Kullanım dışı bırakılmış routes.json dosyasından geçiş yapıyorsanız, yönlendirme kurallarına eski geri dönüş yolunu ("route": "/*") eklemeyin.

Genel üst bilgiler

bölümü globalHeaders , bir yol üst bilgisi kuralı tarafından geçersiz kılınmadığı sürece, her yanıta uygulanan bir HTTP üst bilgileri kümesi sağlar; aksi takdirde hem yoldaki üst bilgilerin hem de genel üst bilgilerin birleşimi döndürülür.

Kullanım örnekleri için örnek yapılandırma dosyasına bakın.

Üst bilgiyi kaldırmak için değeri boş bir dize ()"" olarak ayarlayın.

Genel üst bilgiler için bazı yaygın kullanım örnekleri şunlardır:

  • Özel önbelleğe alma kuralları
  • Güvenlik ilkeleri
  • Kodlama ayarları
  • Çıkış noktaları arası kaynak paylaşımı (CORS) yapılandırması

Aşağıdaki örnek özel bir CORS yapılandırması uygular.

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

Not

Genel üst bilgiler API yanıtlarını etkilemez. API yanıtlarındaki üst bilgiler korunur ve istemciye döndürülür.

Yanıt geçersiz kılmaları

bölümü, responseOverrides sunucu aksi takdirde bir hata kodu döndüreceği durumlarda özel bir yanıt tanımlama fırsatı sağlar. Kullanım örnekleri için örnek yapılandırma dosyasına bakın.

Geçersiz kılmak için aşağıdaki HTTP kodları kullanılabilir:

Durum Kodu Anlamı Olası nedeni
400 Hatalı istek Geçersiz davet bağlantısı
401 Yetkisiz Kimliği doğrulanmamışken kısıtlanmış sayfalara istek
403 Yasak
  • Kullanıcı oturum açtı, ancak sayfayı görüntülemek için gereken rollere sahip değil.
  • Kullanıcı oturum açtı, ancak çalışma zamanı kimlik taleplerinden kullanıcı ayrıntılarını alamıyor.
  • Sitede özel rollerle oturum açan çok fazla kullanıcı olduğundan çalışma zamanı kullanıcıda oturum açamaz.
404 Bulunamadı Dosya bulunamadı

Aşağıdaki örnek yapılandırma, bir hata kodunun nasıl geçersiz kılınduğunu gösterir.

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

Platform

bölümü, platform API dili çalışma zamanı sürümü gibi platforma özgü ayarları denetler.

API dili çalışma zamanı sürümünü seçin

API dili çalışma zamanı sürümünü yapılandırmak için bölümündeki özelliğini platform aşağıdaki desteklenen değerlerden birine ayarlayınapiRuntime.

Dil çalışma zamanı sürümü İşletim sistemi Azure İşlevleri sürümü apiRuntime değer Destek sonu tarihi
.NET Core 3.1 Windows 3.x dotnet:3.1 3 Aralık 2022 Cumartesi
.NET 6.0 işlemde Windows 4.x dotnet:6.0 -
.NET 6.0 yalıtılmış Windows 4.x dotnet-isolated:6.0 -
.NET 7.0 yalıtılmış Windows 4.x dotnet-isolated:7.0 -
.NET 8.0 yalıtılmış Windows 4.x dotnet-isolated:8.0 -
Node.js 12.x Linux 3.x node:12 3 Aralık 2022 Cumartesi
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 (önizleme) 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

.NET uygulamasında çalışma zamanı sürümünü değiştirmek için csproj dosyasındaki değeri değiştirinTargetFramework. İsteğe bağlı olsa da, staticwebapp.config.json dosyasında bir apiRuntime değer ayarlarsanız, değerin csproj dosyasında tanımladığınız değerle eşleştiğinden emin olun.

Aşağıdaki örnekte, CSproj dosyasında API dili çalışma zamanı sürümü olarak NET 8.0 öğesinin nasıl güncelleştirildiği TargetFramework gösterilmektedir.

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

Node.js

Aşağıdaki örnek yapılandırma, staticwebapp.config.json dosyasında API dili çalışma zamanı sürümü olarak Node.js 16'nın seçilmesi için özelliğinin nasıl kullanılacağını apiRuntime gösterir.

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

Python

Aşağıdaki örnek yapılandırma, staticwebapp.config.json dosyasında API dili çalışma zamanı sürümü olarak Python 3.8'i seçmek için özelliğinin nasıl kullanılacağını apiRuntime gösterir.

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

Ağ

bölümü, networking statik web uygulamanızın ağ yapılandırmasını denetler. Uygulamanıza erişimi kısıtlamak için içinde izin verilen IP adresi bloklarının allowedIpRangeslistesini belirtin. İzin verilen IP adresi bloklarının sayısı hakkında daha fazla bilgi için bkz . Azure Static Web Apps'te kotalar.

Not

Ağ yapılandırması yalnızca Azure Static Web Apps Standart planında kullanılabilir.

Sınıfsız Etki Alanları Arası Yönlendirme (CIDR) gösteriminde her IPv4 adres bloğunu tanımlayın. CIDR gösterimi hakkında daha fazla bilgi edinmek için bkz . Sınıfsız Etki Alanları Arası Yönlendirme. Her IPv4 adres bloğu bir genel veya özel adres alanı belirtir. Yalnızca tek bir IP Adresinden erişime izin vermek istiyorsanız CIDR bloğunu /32 kullanabilirsiniz.

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

Bir veya daha fazla IP adresi bloğu belirtildiğinde, içindeki allowedIpRanges bir değerle eşleşmeyen IP adreslerinden gelen isteklere erişim reddedilir.

IP adresi bloklarına ek olarak, trafiği belirli Azure hizmetlerine kısıtlamak için dizide allowedIpRanges hizmet etiketleri de belirtebilirsiniz.

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

Kimlik Doğrulaması

Yolları kimliği doğrulanmış kullanıcılarla kısıtlama hakkında ayrıntılı bilgi için bkz . Yolları rollerle güvenli hale getirme.

Kimliği doğrulanmış yollar için önbelleği devre dışı bırakma

Azure Front Door ile el ile tümleştirme ayarladıysanız güvenli yollarınız için önbelleğe almayı devre dışı bırakmak isteyebilirsiniz. Kurumsal düzeyde uç etkinleştirildiğinde, güvenli yollarınız için önbelleğe alma zaten devre dışıdır.

Güvenli yollar için Azure Front Door önbelleğini devre dışı bırakmak için yol üst bilgisi tanımına ekleyin "Cache-Control": "no-store" .

Örneğin:

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

Ağ geçidini iletme

bölümünde forwardingGateway , content delivery network (CDN) veya Azure Front Door gibi bir iletme ağ geçidinden statik web uygulamasına nasıl erişilir yapılandırılır.

Not

Ağ geçidi yapılandırmasını iletme yalnızca Azure Static Web Apps Standart planında kullanılabilir.

İzin Verilen İletilen Konaklar

Liste, allowedForwardedHosts X-Forwarded-Host üst bilgisinde kabul edilen konak adlarını belirtir. Listede eşleşen bir etki alanı varsa, Statik Web Apps yeniden yönlendirme URL'lerini oluştururken (örneğin, başarılı bir oturum açma sonrasında) değerini kullanır X-Forwarded-Host .

Statik Web Apps'in bir iletme ağ geçidinin arkasında doğru şekilde çalışması için, ağ geçidinden gelen istek üst bilgide X-Forwarded-Host doğru ana bilgisayar adını içermeli ve aynı ana bilgisayar adı içinde allowedForwardedHostslistelenmelidir.

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

X-Forwarded-Host Üst bilgi listedeki bir değerle eşleşmiyorsa istekler yine başarılı olur, ancak yanıtta üst bilgi kullanılmaz.

Gerekli üst bilgiler

Gerekli üst bilgiler, sitenize her istekle birlikte gönderilmesi gereken HTTP üst bilgileridir. Gerekli üst bilgilerin bir kullanımı, her istekte gerekli üst bilgilerin tümü olmadığı sürece siteye erişimi reddetmektir.

Örneğin, aşağıdaki yapılandırmada Azure Front Door için belirli bir Azure Front Door örneğinden sitenize erişimi sınırlayan benzersiz bir tanımlayıcının nasıl ekleneceği gösterilmektedir. Tüm ayrıntılar için Bkz. Azure Front Door'un yapılandırılması öğreticisi.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}
  • Anahtar/değer çiftleri herhangi bir rastgele dize kümesi olabilir
  • Anahtarlar büyük/küçük harfe duyarlı değildir
  • Değerler büyük/küçük harfe duyarlıdır

Sondaki eğik çizgi

Sondaki eğik çizgi, URL'nin sonundaki eğik çizgidir / . Geleneksel olarak, sondaki eğik çizgi URL'si web sunucusundaki bir dizine başvururken, eğitilmeyen eğik çizgi bir dosyayı gösterir.

Arama motorları, iki URL'yi bir dosya veya dizinden bağımsız olarak ayrı olarak ele alır. Aynı içerik bu URL'lerin her ikisinde de işlendiğinde, web siteniz arama motoru iyileştirmesini (SEO) olumsuz yönde etkileyebilecek yinelenen içerik sağlar. Statik Web Uygulamaları açıkça yapılandırıldığında, web sitenizin performansını ve SEO performansını iyileştirmeye yardımcı olan bir dizi URL normalleştirme ve yeniden yönlendirme kuralı uygular.

Kullanılabilir yapılandırmaların her biri için aşağıdaki normalleştirme ve yeniden yönlendirme kuralları geçerlidir:

Her zaman

olarak ayarlandığında trailingSlash always, sondaki eğik çizgi içermeyen tüm istekler sondaki eğik çizgi URL'sine yönlendirilir. Örneğin, /contact öğesine /contact/yeniden yönlendirilir.

"trailingSlash": "always"
İstekler... Döndürür... durumuyla... ve yol...
/hakkında /about/index.html dosyası 301 /hakkında/
/hakkında/ /about/index.html dosyası 200 /hakkında/
/about/index.html /about/index.html dosyası 301 /hakkında/
/privacy.html /privacy.html dosyası 301 /gizlilik/

Asla

olarak ayarlandığında trailingSlash never, sondaki eğik çizgiyle biten tüm istekler, eğik çizgi olmayan bir URL'ye yönlendirilir. Örneğin, /contact/ öğesine /contactyeniden yönlendirilir.

"trailingSlash": "never"
İstekler... Döndürür... durumuyla... ve yol...
/hakkında /about/index.html dosyası 200 /hakkında
/hakkında/ /about/index.html dosyası 301 /hakkında
/about/index.html /about/index.html dosyası 301 /hakkında
/privacy.html /privacy.html dosyası 301 /gizlilik

Otomatik

olarak autoayarladığınızdatrailingSlash, klasörlere yönelik tüm istekler sonunda eğik çizgi olan bir URL'ye yönlendirilir. Dosyalara yönelik tüm istekler, eğitilemeyen eğik çizgi URL'sine yönlendirilir.

"trailingSlash": "auto"
İstekler... Döndürür... durumuyla... ve yol...
/hakkında /about/index.html dosyası 301 /hakkında/
/hakkında/ /about/index.html dosyası 200 /hakkında/
/about/index.html /about/index.html dosyası 301 /hakkında/
/privacy.html /privacy.html dosyası 301 /gizlilik

En iyi web sitesi performansı için , neverveya auto modlarından birini kullanarak sondaki eğik çizgi stratejisini alwaysyapılandırın.

Varsayılan olarak, yapılandırma atlandığında trailingSlash Statik Web Uygulamaları aşağıdaki kuralları uygular:

İstekler... Döndürür... durumuyla... ve yol...
/hakkında /about/index.html dosyası 200 /hakkında
/hakkında/ /about/index.html dosyası 200 /hakkında/
/about/index.html /about/index.html dosyası 200 /about/index.html
/privacy.html /privacy.html dosyası 200 /privacy.html

Örnek yapılandırma dosyası

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

Yukarıdaki yapılandırmaya bağlı olarak aşağıdaki senaryoları gözden geçirin.

İstekler... sonuç olarak...
/profil Kimliği doğrulanmış kullanıcılara /profile/index.html dosyası sunulur. Kimliği doğrulanmamış kullanıcılar yanıt geçersiz kılma kuralı tarafından /login'e 401 yönlendirilir.
/admin, /admin/veya /admin/index.html Yönetici rolündeki kimliği doğrulanmış kullanıcılara /admin/index.html dosyası sunulur. Yönetici rolünde olmayan kimliği doğrulanmış kullanıcılara 403 hata1 sunulur. Kimliği doğrulanmamış kullanıcılar /login'e yönlendirilir
/images/logo.png Görüntüyü, en fazla yaş değerinin 182 günden (15.770.000 saniye) biraz fazla olduğu özel bir önbellek kuralıyla sunar.
/api/admin GET kayıtlı kullanıcılar rolündeki kimliği doğrulanmış kullanıcılardan gelen istekler API'ye gönderilir. Kayıtlı kullanıcılar rolünde olmayan kimliği doğrulanmış kullanıcılara ve kimliği doğrulanmamış kullanıcılara hata 401 sunulur.

POST, PUT, PATCHve DELETE yönetici rolündeki kimliği doğrulanmış kullanıcılardan gelen istekler API'ye gönderilir. Yönetici rolünde olmayan kimliği doğrulanmış kullanıcılara ve kimliği doğrulanmamış kullanıcılara hata 401 sunulur.
/customers/contoso Yönetici veya customers_contoso rollerine ait kimliği doğrulanmış kullanıcılara /customers/contoso/index.html dosyası sunulur. Yönetici veya customers_contoso rollerinde olmayan kimliği doğrulanmış kullanıcılara 403 hata1 sunulur. Kimliği doğrulanmamış kullanıcılar /login'e yönlendirilir.
/Oturum açma Kimliği doğrulanmamış kullanıcıların GitHub'da kimlik doğrulamasına sahip olması istenir.
_/.auth/login/x Yol kuralı X yetkilendirmesini devre dışı bırakdığından bir 404 hata döndürülür. Bu hata daha sonra durum koduyla /index.html sunulmasına 200 geri döner.
/Oturum kapatma Kullanıcılar herhangi bir kimlik doğrulama sağlayıcısının oturumlarını kapatmış durumdadır.
/calendar/2021/01 Tarayıcıya /calendar.html dosyası sunulur.
/Özel Tarayıcı kalıcı olarak /deals öğesine yönlendirilir.
/data.json Dosya, MIME türüyle birlikte text/json sunulur.
/about veya istemci tarafı yönlendirme desenleri ile eşleşen herhangi bir klasör /index.html dosyası bir 200 durum koduyla sunulur.
/images/ klasöründe var olmayan bir dosya Bir 404 hata.

1 Yanıt geçersiz kılma kuralı kullanarak özel bir hata sayfası sağlayabilirsiniz.

Kısıtlamalar

staticwebapp.config.json dosyası için aşağıdaki kısıtlamalar vardır.

  • En büyük dosya boyutu 20 KB'tır
  • En fazla 50 ayrı rol

Genel kısıtlamalar ve sınırlamalar için Kotalar makalesine bakın.

Sonraki adımlar

Kimlik doğrulama ve yetkilendirmeyi ayarlama