Show Content

Show Content Aksiyonu Nedir?

Show Content aksiyonu, TR7 üzerinde çalışan vService'lere gelen isteklere veya dönen yanıtlara, önceden tanımlanmış özel içerik sayfaları sunulmasını sağlar. Bu aksiyon, istek (request) veya yanıt (response) aşamasında devreye alınabilir.

Gösterilen içerik sayfası, istemciye belirtilen HTTP durum kodu ile birlikte döndürülür. Varsayılan durum kodu HTTP 200 (OK) olarak gelir; ancak farklı durum kodları da seçilebilir.

Show Content aksiyonu; özel hata sayfaları, bakım bildirimleri, bilgilendirme mesajları, yönlendirme ekranları ve dinamik içerik sunumu amacıyla yaygın olarak kullanılır.

Show Content Aksiyonunun Önemi

Modern web uygulamalarında kullanıcı deneyimi, yalnızca başarılı yanıtlarla değil; belirli senaryolarda sunulan özel içeriklerle de şekillenir. Show Content aksiyonu, bu içeriklerin koşullara bağlı olarak dinamik şekilde sunulmasını sağlar.

Show Content aksiyonu;

• Belirli path'lere veya koşullara özel içerik sunulmasını sağlar,
• Bakım sayfaları ve bilgilendirme mesajları gösterilebilir,
• Yetkisiz erişim denemelerinde özel uyarı sayfaları sunulabilir,
• Kurum Servislerine ulaşmadan önce veya sonra içerik müdahalesi yapılabilir,
• Kurumsal kimliğe uygun, profesyonel içerikler sunularak marka tutarlılığı korunur.

Bu aksiyon, Traffic Manipulation kapsamında içerik yönetiminin temel yapı taşlarından biridir.

İçerik Sayfaları

Show Content aksiyonu, İçerik Sayfaları (Content Pages) profilleri ile birlikte çalışır. İçerik sayfalarının nasıl oluşturulacağı ve yönetileceği hakkında detaylı bilgi Content Pages sayfasında yer alır.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Nasıl Eklenir?

Yeni bir Show Content Aksiyonu, TR7 web yönetim arayüzü üzerinden aşağıdaki adımlar izlenerek eklenebilir:

1. Sol altta bulunan TR7 logosuna tıklanarak Configuration Menu açılır.
2. Load Balancer → Actions → Add adımları takip edilir.
3. Aksiyon için benzersiz ve açıklayıcı bir isim girilir.
4. Action Type olarak Show Content seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Conditions sekmesinden aksiyonun hangi koşul/koşullarda devreye gireceği belirlenir.
7. Add butonuna tıklanarak aksiyon eklenir.

Show Content Aksiyonu Ekleme Formu

Show Content Aksiyonu Ekleme Formu

INFO

Action Name

Oluşturulacak olan Show Content aksiyonu için benzersiz ve açıklayıcı bir isim girilir.

INFO

Action Type

Aksiyon tipi olarak Show Content seçilir.

INFO

Execution Level

Aksiyonun hangi aşamada çalıştırılacağını belirler.

• On Request: Aksiyon, istek ilgili Kurum Servisine iletilmeden önce uygulanır. Bu seviye, istek üzerinde değişiklik yapılması veya Kurum Servisine ek bilgi iletilmesi gereken durumlarda kullanılır.
• On Response: Aksiyon, yanıt istemciye iletilmeden önce uygulanır. Bu seviye, istemciye gönderilen yanıt üzerinde düzenleme veya ekleme yapılması gereken durumlarda kullanılır.

INFO

Hit Counter Varsayılan: Kapalı

Hit Counter, aksiyonun her çalışmasını sayar (aksiyonun kendi koşuluyla birlikte değerlendirilir; Deny gibi sonlandırıcı aksiyonlarda bile sayım kaybolmaz). Aksiyon bazlı hız ve toplamlar, vService panosundaki Action Hits sekmesinde ve canlı istatistik ekranında görüntülenir; listelerde ayrıca bir kolon olarak görünmez. Sayaç kümülatiftir; elle sıfırlama arayüzü yoktur: sayılan aksiyon kümesi değiştiğinde veya vService yeniden yüklendiğinde sıfırdan başlar, geçmiş ise panoda hız (hit/s) olarak korunur.

INFO

Set Variable on Hit

Aksiyon her çalıştığında değeri atanacak bir değişken adı girilebilir (isteğe bağlı; varsayılan boş). Ad; harf, rakam ve alt çizgiden oluşabilir (en fazla 32 karakter). Aksiyon tetiklendiğinde değişken 1 değerine atanır ve aynı vService'teki diğer koşul ve aksiyonlarda %TR7VAR(ad) akıllı değişkeniyle okunarak zincirleme davranışlar kurulabilir.

INFO

Content Page Varsayılan: Access denied page (English)

İstemciye gösterilecek olan Content Pages bu alandan seçilir.

Daha önce oluşturulmuş içerik sayfalarından seçim yapılabilir veya Add butonuna tıklanarak yeni bir içerik sayfası aksiyon ekleme adımında da oluşturulabilir.

İçerik sayfaları Load Balancer → Profiles → Content Pages bölümünden merkezi olarak yönetilir. Detaylı bilgi Content Pages sayfasında yer alır.

İçerik Sayfası Oluşturma

İçerik sayfası yoksa Default içerik sayfası profili kullanılabilir ya da açılır listedeki Add butonuna tıklanarak hızlıca yeni bir sayfa oluşturulur. İçerik sayfaları HTML, CSS ve JavaScript içerebilir.

INFO

Status Code Varsayılan: 200

İstemciye içerik sayfası döndürülürken kullanılacak HTTP durum kodu bu alandan seçilir.

Varsayılan olarak HTTP 200 (OK) seçili gelir. Senaryo gereksinimlerine göre farklı durum kodları tercih edilebilir.

Yaygın Kullanım Senaryoları:

• 200 – OK → Başarılı yanıt. Bilgilendirme sayfaları, özel içerik sunumları için uygundur.
• 403 – Forbidden → Erişim engellendiğinde. Yetkisiz erişim uyarısı içeren sayfalar için kullanılır.
• 404 – Not Found → Kaynak bulunamadığında. Özel 404 hata sayfaları için tercih edilir.
• 503 – Service Unavailable → Servis geçici olarak kullanılamadığında. Bakım sayfaları için idealdir.
• 429 – Too Many Requests → İstek limiti aşıldığında. Rate limit bildirimi için kullanılabilir.

Doğru HTTP durum kodunun seçilmesi, hem kullanıcı deneyimini hem de istemci/tarayıcı davranışını doğrudan etkiler.

İçerik Gösterilemeyen Durum Kodları

HTTP standardına göre bazı durum kodları yanıt gövdesi (body) içeremez. Bu nedenle aşağıdaki kodlar Show Content aksiyonunda kullanılamaz:

• 100, 101, 102, 103 (Informational)
• 204 (No Content)
• 304 (Not Modified)

INFO

Conditions

Bu alanda, ilgili yapılandırmanın hangi koşul veya koşullar sağlandığında devreye gireceği tanımlanır.

Bir veya birden fazla koşul eklenerek, and/or yapısı ile davranışın hedefli ve kontrollü şekilde uygulanması sağlanabilir. Koşullar; istemci IP adresi, path, header, HTTP method, User-Agent gibi birçok farklı kritere göre oluşturulabilir.

Koşullar hakkında detaylı bilgi Conditions sayfasında yer alır.

WARNING

Bu alanda herhangi bir koşul tanımlanmazsa, ilgili aksiyon koşulsuz (Always) olarak çalışır. Bu durumda aksiyon, ilgili vService'e gelen tüm trafiğe uygulanır.

Canlı ortamlarda, koşul tanımlanmadan aksiyon kullanılması beklenmeyen durumlara (servis kesintilerine) yol açabilir. Bu nedenle aksiyon oluşturulurken mutlaka en az bir koşul tanımlanması önerilir.

INFO

Form Butonları

Add

Add butonuna tıklanarak aksiyon ekleme işlemi tamamlanır.

Add & Repeat

Add & Repeat butonu ile aksiyon ekleme işlemi tamamlanır ve farklı konfigürasyonlarla ilgili pencereden çıkılmadan yeni bir aksiyon daha eklenebilir.

Aksiyon Eklendi

"Default profile" seçilmemelidir

İçerik sayfası listesinde yer alan Default profile seçeneğinin karşılığı bir içerik sayfası yoktur. Bu seçenek işaretlenirse aksiyon hiç devreye alınmaz ve arayüzde uyarı da verilmez; istek normal akışına devam eder.

Aynı durum, aksiyona bağlı içerik sayfası silindiğinde de oluşur. Bu nedenle her zaman gerçek bir içerik sayfası seçilmelidir.

Aksiyon isteği sonlandırır

On Request seçildiğinde yanıt doğrudan TR7 tarafından üretilir; istek Kurum Servisine iletilmez ve aksiyon listesinde bu aksiyondan sonra gelen aksiyonlar çalışmaz.

Yanıtın Content-Type bilgisi aksiyondan değil, seçilen içerik sayfasının kendi ayarından gelir. İçeriği boş bir sayfa seçilirse yalnızca durum kodu döner, gövde gönderilmez.

Bu yanıta Manage HTTP Security Headers aksiyonunun eklediği başlıklar uygulanmaz.

TIP

İçerik sayfası metninde akıllı değişkenler kullanılabilir; örneğin istemci IP adresi, zaman damgası veya istek kimliği sayfaya yazdırılarak destek ekibine referans verilebilir.

Operasyonel ve Güvenli Kullanım Önerileri

Show Content aksiyonu, kullanıcı deneyimini doğrudan etkileyen kritik bir bileşendir. Aşağıdaki öneriler, canlı ortamlarda güvenli ve etkili kullanım sağlar.

• Execution Level Seçimini Senaryoya Göre Yapın. Kurum Servisine ulaşmadan içerik gösterilmesi gereken durumlar için On Request, yanıt alındıktan sonra içerik değiştirilmesi gereken durumlar için On Response tercih edilmelidir.
• Status Code Seçimini İçeriğe Uygun Yapın. Bilgilendirme sayfaları için 200, hata bildirimleri için uygun hata kodları (403, 404, 503 vb.) kullanılmalıdır. Yanlış durum kodu seçimi tarayıcı davranışını ve SEO'yu olumsuz etkileyebilir.
• Koşulları Net ve Hedefli Tanımlayın. Gereğinden geniş koşullar, beklenmeyen içeriklerin gösterilmesine yol açabilir. Koşullar mümkün olduğunca spesifik tanımlanmalıdır.
• İçerik sayfaları merkezî olarak yönetilir. Aynı içerik birden fazla aksiyonda kullanılacaksa tek bir İçerik Sayfası profili oluşturulur ve aksiyonlarda bu profile referans verilir; böylece güncellemeler tek noktadan yapılır.
• Canlı ortamda değişiklik öncesinde "Used In" bilgisi kontrol edilir. Bir İçerik Sayfası üzerinde değişiklik yapılmadan önce sayfanın hangi aksiyonlarda ve vService'lerde kullanıldığı kontrol edilir.
• Kurumsal Kimliğe Uygun İçerikler Hazırlayın. Hata sayfaları ve bilgilendirme içerikleri kurumsal kimliğe uygun tasarlanmalı, kullanıcılara yol gösterici bilgiler içermelidir.

Canlı Ortamlarda Yaygın Kullanım Senaryoları

Aşağıdaki örnekler, ilgili aksiyonun gerçek sistemlerde en sık karşılaşılan kullanım senaryolarında nasıl uygulandığını göstermektedir. Bu senaryolar, canlı ortamlarda yaygın olarak tercih edilen ve sahada edinilmiş deneyimlere dayanan pratikleri temel alır.

Senaryo 1: Planlı Bakım Sayfası Gösterimi

Problem: Sistem güncellemesi veya planlı bakım sırasında tüm Kurum Servisleri kapatılacak. Kullanıcılar siteye erişmeye çalıştığında connection timeout veya generic browser error alıyorlar. Bu da kullanıcı deneyimini kötü etkiliyor ve support ekibine gereksiz ticket açılmasına neden oluyor.

Çözüm: Planlı bakım dönemlerinde profesyonel bir bakım sayfası gösterilir; kullanıcılar bilgilendirilir ve bakımın tahmini bitiş saati bildirilir.

Konfigürasyon:

• Execution Level: On Request
• Content Page: Maintenance - Scheduled Downtime
• Status Code: 503 Service Unavailable
• Conditions:
  • Koşulsuz (planlı bakım için tüm trafiğe uygulanır)

Sonuç:

• ✅ Profesyonel görünüm → Kurumsal kimliğe uygun bakım sayfası gösterilir.
• ✅ Kullanıcı bilgilendirme → Bakım süresi, tahmini bitiş saati, iletişim bilgileri sunulur.
• ✅ 503 durum kodu → Arama motorları geçici hata olduğunu anlar, SEO penalty uygulanmaz.
• ✅ Support yükü azalır → Kullanıcılar durumu anlayınca ticket açma oranı düşer.

İçerik Sayfası Örneği:

<h1>Planlı Bakım</h1>
<p>Sistemlerimiz şu anda güncelleniyor.</p>
<p>Tahmini bitiş: 02:00 AM (GMT+3)</p>

Senaryo 2: Tüm Kurum Servisleri Down Durumunda Otomatik Bakım Sayfası

Problem: Beklenmedik bir altyapı sorunu nedeniyle tüm Kurum Servisleri aynı anda down oluyor. TR7 health check'lerde fail alıyor ama kullanıcılar hala siteye erişmeye çalışıyor ve 502 Bad Gateway hatası alıyorlar. Bu durumda kullanıcılar sitenin tamamen çöktüğünü düşünüyor.

Çözüm: Sağlıklı Kurum Servisi sayısı sıfır olduğunda otomatik olarak bakım sayfası gösterilir ve teknik ekibin durumdan haberdar olduğu belirtilir.

Konfigürasyon:

• Execution Level: On Request
• Content Page: Emergency Maintenance
• Status Code: 503 Service Unavailable
• Conditions:
  • Number of Active Servers = 0

Sonuç:

• ✅ Otomatik failover → Kurum Servisleri down olduğunda manuel müdahale gerekmez.
• ✅ Graceful degradation → Kullanıcı generic error yerine anlamlı mesaj görür.
• ✅ 502 önleme → Bad Gateway hatası yerine kontrollü 503 döner.
• ✅ İş sürekliliği → Kullanıcılar durumun geçici olduğunu anlar, siteyi terk etmez.

Çalışma Mantığı:

1. TR7 tüm Kurum Servislerini health check ile izler
2. Sağlıklı Kurum Servisi sayısı = 0 olduğunda koşul tetiklenir
3. Show Content aksiyonu devreye girer
4. Kullanıcı emergency maintenance sayfası görür

Senaryo 3: Statik İçerik Sunumu (Terms, Privacy, Robots.txt)

Problem: Terms of Service, Privacy Policy ve robots.txt gibi statik sayfalar için her seferinde Kurum Servisine istek gönderiliyor. Bu sayfalarda hiç değişiklik olmamasına rağmen Kurum Servisi kaynakları tüketiliyor. Ayrıca Kurum Servisi down olduğunda bu kritik sayfalar da erişilemez oluyor.

Çözüm: Statik içerikler doğrudan TR7 üzerinden sunulur; Kurum Servisine hiç gidilmeden yanıt üretilir ve yüksek erişilebilirlik sağlanır.

Konfigürasyon:

• Execution Level: On Request
• Content Page: Static Legal Pages
• Status Code: 200 OK
• Conditions:
  • Path /terms eşittir
  • OR Path /privacy eşittir
  • OR Path /robots.txt eşittir

Sonuç:

• ✅ Kurum Servisi yükü azalır → Statik içerik TR7'den sunulur, Kurum Servisi kaynakları serbest kalır.
• ✅ Yüksek erişilebilirlik → Kurum Servisi down olsa bile statik sayfalar erişilebilir.
• ✅ Düşük latency → TR7'den direkt yanıt, Kurum Servisi roundtrip yok.
• ✅ SEO dostu → robots.txt her zaman erişilebilir, search engine crawling kesintisiz.

Kullanım Örneği:

• İstek: GET /terms → TR7 direkt content page döner
• İstek: GET /privacy → TR7 direkt content page döner
• İstek: GET /robots.txt → TR7 robots.txt içeriğini döner

Senaryo 4: Kurum Servisi Hatalarında Özel Error Sayfaları

Problem: Kurum Servisi 502, 503 veya 504 hatası döndüğünde kullanıcılar tarayıcının default error sayfasını görüyor. Bu sayfalarda hiçbir kurumsal kimlik veya yardımcı bilgi yok. Kullanıcı ne yapacağını bilmiyor ve sitenin profesyonel olmadığını düşünüyor.

Çözüm: Kurum Servisi hata kodları yakalanır ve kurumsal kimliğe uygun, kullanıcı dostu özel hata sayfaları gösterilir.

Konfigürasyon:

• Execution Level: On Response
• Content Page: Custom Server Error Page
• Status Code: 503 Service Unavailable
• Conditions:
  • Status Code 502 eşittir
  • OR Status Code 503 eşittir
  • OR Status Code 504 eşittir

Sonuç:

• ✅ Profesyonel görünüm → Generic browser error yerine branded error page.
• ✅ Kullanıcı yönlendirme → Alternatif aksiyonlar sunulur (ana sayfaya dön, support'a ulaş).
• ✅ Error maskeleme → Internal server error'lar dışarı sızmaz.
• ✅ Marka imajı korunur → Hata durumlarında bile profesyonel görünüm.

Örnek Akış:

1. Kurum Servisi 502 Bad Gateway döner
2. TR7 response'u yakalar ve condition match eder
3. Kurum Servisi response'u custom error page ile değiştirilir
4. Kullanıcı branded error sayfası görür

Senaryo 5: Admin Panel IP Whitelist ile Koruma

Problem: Admin panel (/admin) public olarak erişilebilir durumda. Sadece ofis IP'lerinden erişilmesi gerekiyor ama application-level IP kontrolü yok. Brute force saldırıları ve yetkisiz erişim denemeleri logları dolduruyor.

Çözüm: Admin panel path'ine whitelist dışı IP'lerden erişim denendiğinde özel bir 403 Forbidden sayfası gösterilir ve erişim engellenir.

Konfigürasyon:

• Execution Level: On Request
• Content Page: Access Denied - Admin Area
• Status Code: 403 Forbidden
• Conditions:
  • Path /admin ile başlar
  • AND Source IP Office Network değil

Sonuç:

• ✅ Perimeter security → Kurum Servisine ulaşmadan IP-based access control.
• ✅ Brute force önleme → Whitelist dışı IP'ler admin panel'e hiç ulaşamaz.
• ✅ Log temizliği → Kurum Servisi logları whitelist dışı isteklerle dolmaz.
• ✅ Özel mesaj → 403 sayfasında "Bu alan sadece yetkili IP'lerden erişilebilir" mesajı.

Güvenlik Akışı:

• Office IP (whitelist): /admin → Kurum Servisine iletilir → Normal login flow
• External IP: /admin → Show Content aksiyonu devreye girer → 403 Forbidden page
• Kurum Servisi external IP'lerden gelen admin isteklerini hiç görmez