Uygulamam kullanıcıyı sürekli login ekranına atıyor (oturum kayboluyor); neden?
Kısa cevap
Oturum kaybının iki ana kaynağı vardır: istekler oturumu tutmayan başka bir Kurum Servisine gidiyordur ya da tarayıcı oturum çerezini geri göndermiyor veya uygulama onu okuyamıyordur. İlk grupta Persistence'ın hiç tanımlanmamış olması, sürelerinin uygulamanın oturumundan kısa olması ve sunucunun düşmesi vardır. İkinci grupta TR7'nin çerez aksiyonları öne çıkar: Cookie Encryption çerezi istemcinin IP adresine ve User-Agent'ına bağlar ve bunlar değişince çözülemeyen çerez uygulamaya FAILED_COOKIE_DECRYPTION değeriyle gider; HTTP Cookie Security'deki SameSite=Strict, SSO dönüşlerinde çerezi göndermez. Secure çerezle HTTP üzerinden erişim ve TLS'in TR7'de sonlandırıldığından habersiz bir uygulama da aynı sonucu doğurur.
Olası Nedenler
| Neden | Nasıl anlaşılır | Bakılacak sayfa |
|---|---|---|
| Persistence tanımlı değil | HTTP Logs'ta aynı istemcinin istekleri farklı Kurum Servislerine gidiyor | Uygulamamın persistence'a ihtiyacı olup olmadığını nasıl anlarım? |
| Persistence var ama bozuluyor | Belirli durumlarda sunucu değişiyor | Persistence açık olmasına rağmen kullanıcılarım farklı sunuculara düşüyor; neden? |
| Persistence süresi oturumdan kısa | Belirli bir boşta kalma süresinden sonra düşüyor; New Cookie'de Cookie Max-Idle varsayılanı 30 dakika, Cookie Max-Life varsayılanı 8 saattir | New Cookie ile Current Cookie arasındaki fark nedir? |
| Cookie encryption ve değişen IP ya da User-Agent | Mobil ağ ile Wi-Fi arasında geçişten ya da tarayıcı güncellemesinden sonra; uygulama logunda çerez değeri FAILED_COOKIE_DECRYPTION | Aksiyon Certain Cookies ile yalnızca uygulamanın ürettiği oturum çerezleriyle sınırlandırılır; TR7'nin önünde CDN varsa gerçek istemci IP'si Trusted Proxy ile çözülür (TR7'nin önünde Cloudflare / Akamai gibi bir CDN var; gerçek istemci IP'sini nasıl alırım (Trusted Proxy)?) |
| Cookie encryption All Cookies ile açık | JavaScript ya da üçüncü taraf çerezlerine bağlı giriş akışı bozuluyor | Kapsam Certain Cookies yapılır |
| SameSite=Strict | SSO, OAuth ya da ödeme dönüşünde yeniden giriş isteniyor | Cookie'lere Secure, HttpOnly, SameSite özelliklerini otomatik ekleyebilir miyim? |
| Secure çerez ve HTTP erişimi | Site http:// ile açılınca oturum yok | HTTP'den HTTPS'e yönlendirmeyi nasıl yaparım? |
| Uygulama HTTPS'ten habersiz | Girişten sonra Location http://… | Backend uygulaması mutlak URL'lerde http:// üretiyor; nasıl düzeltirim? |
| Host ya da çerez Domain uyuşmazlığı | Set-Cookie Domain değeri iç ad; www ile www'suz adres arasında geçiş | www ekleme / kaldırma yönlendirmesini nasıl yaparım? |
| Sunucu ara ara düşüyor | Health check geçmişinde düşüşler | Health Check sürekli up/down arasında gidip geliyor (flapping); ne yapmalıyım? |
| Kişiye özel sayfa önbellekten geliyor | Giriş yapmış kullanıcıya çıkış yapılmış sayfa | Kullanıcıya özel içeriğin yanlışlıkla cache'lenmesini nasıl önlerim? |
Kesin kurallar:
- Cookie Encryption anahtarı vService kimliği, istemcinin IP adresi ve User-Agent bilgisinden türetilir. IP ya da User-Agent değişirse çerez çözülemez; TR7 çerezi silmez, değerini
FAILED_COOKIE_DECRYPTIONyaparak Kurum Servisine iletir. Aksiyon devreye alındığında daha önce verilmiş şifresiz çerezler de çözülemez; o an açık olan oturumlar düşer. - HTTP Cookie Security'de Mark as Secure yalnızca HTTPS isteklerin yanıtlarına uygulanır; Mark as SameSite=Strict bütün Set-Cookie başlıklarına, TR7'nin kendi Persistence çerezine de uygulanır. Strict dışında bir değer gerekiyorsa Replace HTTP Header Content kullanılır.
Nereden İzlenir?
| Ekran | Yol | Ne gösterir |
|---|---|---|
| Tarayıcı geliştirici araçları | Network ve Application sekmeleri | Set-Cookie değerleri (Domain, Path, Secure, SameSite), sonraki istekte çerezin gönderilip gönderilmediği, girişten sonraki Location |
| HTTP Logs | Load Balancer vServices → vService → Logs & Tracking | Aynı Client IP'nin isteklerinin hangi Backend service'e gittiği |
| Load Balancer Management | vService → Load Balancer Management | Persistence ayarı ve çerezlere dokunan aksiyonlar tek ekranda |
| Uygulama logu | Kurum Servisi | Çerez değerinde FAILED_COOKIE_DECRYPTION |
Nasıl Teşhis Edilir?
- Tarayıcıda çerez izlenir: Giriş yanıtında Set-Cookie gelip gelmediği; Domain, Path, Secure ve SameSite değerleri; sonraki istekte çerezin gönderilip gönderilmediği ve girişten sonraki Location değerinin
http://olup olmadığı kontrol edilir. - Sunucu değişimi aranır: Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → HTTP Logs açılır; Filter panelinde Client IP kartından kullanıcının adresi seçilir ve Backend Service değerine bakılır. Giriş ekranına dönüş anında sunucu değişiyorsa sorun Persistence'tadır (Belirli bir istemci IP'sinin isteklerini loglarda nasıl bulurum?).
- vService ayarları gözden geçirilir: Persistence türü ve süreleri; vService'teki Cookie Encryption, HTTP Cookie Security ve Host başlığını değiştiren Set HTTP Header aksiyonları kontrol edilir.
- Uygulama logu incelenir: Çerez değerinde
FAILED_COOKIE_DECRYPTIONgörünüyorsa Cookie encryption çerezi çözememiştir. - Sunucu durumu ve yeniden yükleme kontrol edilir: Olay anında Kurum Servisinin düşüp düşmediği ve yapılandırmanın yeniden yüklenip yüklenmediğine bakılır (Bir yapılandırma değişikliğini kaydetmek persistence tablolarını sıfırlar mı?).
Sık Karıştırılan Noktalar
- "Oturum kaybı her zaman Persistence sorunudur." TR7'nin çerez aksiyonları ve HTTP/HTTPS farkları da oturumu düşürür.
- "Cookie encryption'ı All cookies ile açmak en güvenlisidir." TR7'nin şifrelemediği JavaScript ve üçüncü taraf çerezleri de
FAILED_COOKIE_DECRYPTIONolur; yalnızca Kurum Servisinin ürettiği çerezler Certain Cookies ile adlandırılır. - "SameSite=Strict her uygulamada sorunsuzdur." Dış sitelerden dönen SSO, OAuth ve ödeme akışlarında çerez gönderilmez.
- "vService'i silip yeniden oluşturmak sorunu çözer." Şifreleme anahtarı vService kimliğine bağlıdır; yeni vService'te daha önce verilmiş şifreli çerezlerin hepsi geçersiz olur.
Dokümantasyonda nasıl yapılır
