Aracılığıyla paylaş


Azure Static Web Apps'i yapılandırma

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

Güzergahlar

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 route ve dizideki methods bir değer istekle eşleştiğinde eşleşme meydana gelir (belirtildiyse). 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 Varsayılan değer Yorum
route Evet yok Çağıran tarafından istenen rota 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 redirect kuralıyla birbirini dışlar.
  • 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 rewrite kuralıyla birbirini dışlar.
  • 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 bir dizi HTTP üst bilgisi.
  • Rota özgü üst bilgiler, rota özgü üst bilgi yanıtın genel üst bilgiyle aynı olduğunda globalHeaders'yi geçersiz kılar.
  • Ü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-z, A-Z, 0-9 ve _ karakterlerini içerir.
  • 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" mantığı 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.

Amaç Özellikler
Yolları eşleştir route, methods
Bir kural eşleştirildikten ve yetkilendirildikten sonra işleme alınması. rewrite (isteği değiştirir)

redirect, headers, statusCode (yanıtı değiştirir)
Bir yol eşleştirildikten sonra yetkilendirin 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 /profile bir klasör yolu (/profile/ veya route) 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/january/1ve /calendar/2020gibi /calendar/overviewURL 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 yapılan isteklerle eşleşmez. /calendar* ile başlayan tüm istekleri eşleştirmek için kullanın.

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 yol tanımları için yaygın kullanım durumları ş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 güzergahları güvence altına alma

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 authenticated ekleyinallowedRoles.

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

Gerektiğinde allowedRoles dizisinde yeni roller oluşturabilirsiniz. Bir yolu yalnızca yöneticilerle kısıtlamak için dizide administrator adlı allowedRoleskendi 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. Rotalarınızı kilitlemek için, tüm rotalarla eşleşen bir kural ekleyin ve authenticated yerleşik rolünü allowedRoles dizisine 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

navigationFallback tetikleyen isteklere yol kuralları 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ı /images/*.{png,jpg,gif} filtresinde 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ılmış bir dosyanın yoluyla eşleşmeyen herhangi 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 Başlıklar

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 dizeye ("") ayarlayın.

Genel başlıklar 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ı

responseOverrides bölümü, sunucunun 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ğrulanmadan kısıtlanmış sayfalara istek gönderme
403 Yasak
  • Kullanıcı oturum açtı, ancak sayfayı görüntülemek için gereken rollere sahip değil.
  • Kullanıcı oturum açmış durumda, ancak belirtilen çalışma ortamı kimlik doğrulama beyanlarından kullanıcı bilgilerini alamıyor.
  • Sitede özel rollerle oturum açan çok fazla kullanıcı olduğundan sistem 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"
    }
  }
}

Platforma

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 dil çalışma zamanı sürümünü yapılandırmak için apiRuntime bölümündeki platform özelliğini aşağıdaki desteklenen değerlerden birine ayarlayın.

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 30 Nisan 2025
.NET 8.0 işlemde Windows 4.x dotnet:8.0 -
.NET 6.0 yalıtılmış Windows 4.x dotnet-isolated:6.0 30 Nisan 2025
.NET 7.0 yalıtılmış Windows 4.x dotnet-isolated:7.0 30 Nisan 2025
.NET 8.0 yalıtılmış Windows 4.x dotnet-isolated:8.0 -
.NET 9.0 yalıtılmış Windows 4.x dotnet-isolated:9.0 -
Node.js 12.x Linux işletim sistemi 3.x node:12 3 Aralık 2022 Cumartesi
Node.js 14.x Linux işletim sistemi 4.x node:14 30 Nisan 2025
Node.js 16.x Linux işletim sistemi 4.x node:16 30 Nisan 2025
Node.js 18.x Linux işletim sistemi 4.x node:18 31 Mayıs 2025
Node.js 20.x Linux işletim sistemi 4.x node:20 -
Node.js 22.x Linux işletim sistemi 4.x node:20 -
Python 3.8 Linux işletim sistemi 4.x python:3.8 30 Nisan 2025
Python 3.9 Linux işletim sistemi 4.x python:3.9 -
Python 3.10 Linux işletim sistemi 4.x python:3.10 -
Python 3.11 Linux işletim sistemi 4.x python:3.11 -

.NET

.NET uygulamasında çalışma zamanı sürümünü değiştirmek için csprojTargetFrameworkdeğeri değiştirin. İ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 TargetFrameworkgösterilmektedir.

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

Node.js

Aşağıdaki örnek yapılandırma, apiRuntime dili çalışma zamanı sürümü olarak Node.js 20'yi seçmek için özelliğinin nasıl kullanılacağını gösterir.

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

Piton

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

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

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. Daha fazla bilgi için, Azure Static Web Apps'te Kotalar başlığı altında verilen IP adresi bloklarının sayısını inceleyin.

Not

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

Her IPv4 adres bloğunu, Sınıfsız Etki Alanları Arası Yönlendirme (CIDR) gösterimi ile tanımlayın. CIDR gösterimi hakkında daha fazla bilgi edinmek için Sınıfsız Etki Alanları Arası Yönlendirme kısmına bakın. 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 hizmet etiketleriallowedIpRanges.

"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 seviyede kenar etkinleştirildiğinde, güvenli yollarınız için önbelleğe alma önceden 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"
    }
}

Yönlendirici ağ geçidi

forwardingGateway bölümü, Content Delivery Network (CDN) veya Azure Front Door gibi bir iletme ağ geçidinden statik web uygulamasına nasıl erişileceğini yapılandırır.

Not

İletme ağ geçidi yapılandırması yalnızca Azure Static Web Apps Standard planında kullanılabilir.

İzin Verilen İletilen Sunucular

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

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

"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 başlıklar

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 çizgiye sahip bir URL, web sunucusunda bir dizine atıfta bulunurken, sondaki eğik çizgi olmayan bir URL 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 trailingSlashalways, 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 trailingSlashnever, 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

trailingSlash'yı auto olarak ayarladığınızda, klasörlere yönelik tüm istekler, sonunda eğik çizgi olan bir URL'ye yönlendirilir. Dosyalara yönelik tüm istekler, sonunda eğik çizgi olmayan bir URL'ye 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, sondaki eğik çizgi stratejisini always, never veya auto modlarından birini kullanarak yapılandırın.

Varsayılan olarak, trailingSlash yapılandırması dışarıda bırakıldığında, 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 401'e 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 hata403 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. Kimliği doğrulanmış ancak registeredusers rolünde olmayan kullanıcılar ile kimliği doğrulanmamış kullanıcılara bir 401 hatası 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. Kimliği doğrulanmış olup yönetici veya customers_contoso rollerinde olmayan 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 200 sunmaya 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.
/Kampanyalar Tarayıcı kalıcı olarak /deals öğesine yönlendirilir.
/data.json Dosya, text/json MIME türü olarak 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