Çoğu işletme sahibi oturum düşmesini basit bir aksilik sanır: "internet koptu", "müşteri uzun süre beklemiş", "tarayıcı eski". Bu cümleleri destek ekibine yüzlerce kez yazdın, karşılığında da "önbelleği temizleyin" cevabını aldın. Sonra aynı şey ertesi gün yine oldu. Çünkü panelde oturumun düşmesi neredeyse hiçbir zaman kullanıcının davranışıyla ilgili değildir; sunucu tarafında oturumun nerede tutulduğu, kim tarafından silindiği ve hangi katmanın onu görmediğiyle ilgilidir.
Bir e-pin satış scripti normal bir kurumsal siteden farklı çalışır. Kullanıcı sepete kod ekler, bakiye yükler, ödeme sağlayıcısına gider, geri döner, sipariş geçmişini açar. Bu zincirde oturum tek bir saniye boyunca kaybolursa müşteri kendini giriş ekranında bulur ve o satış biter. Aşağıda, panel oturumunun neden düştüğünü katman katman açacağız ve hangi kontrolü hangi sırayla yapacağını tablo hâlinde vereceğiz. Sonunda elinde tahmin değil, ölçülebilir bir teşhis listesi olacak.
Oturum düşmesinin faturasını hosting firmasına kesmek neden işe yaramıyor?
Destek talebi açtığında sana "sunucuda sorun yok" denir ve teknik olarak bu doğrudur. Sunucu ayakta, PHP çalışıyor, veritabanı cevap veriyor. Oturum ise bunların hiçbirinde değil, çoğu kurulumda geçici dosya dizinindeki küçük metin dosyalarında tutulur. Paylaşımlı barındırmada bu dizin onlarca hesapla ortaktır ve sistemin temizlik görevi, en eski dosyaları senin müşterin hâlâ alışveriş yaparken siler. Yani hosting gerçekten "çalışıyor"; sadece senin oturumunu koruma sözü hiç vermemiş.
İkinci yanılgı, sorunu epin yazılım tarafında tek bir hataya indirgemektir. Oysa oturum üç ayrı yerde ölebilir: depolama katmanında dosya silinir, taşıma katmanında çerez tarayıcıya hiç ulaşmaz, önbellek katmanında ise başka bir kullanıcının sayfası sana servis edilir. Üçünün belirtisi aynıdır; çözümleri tamamen farklıdır. Doğru soru "neden düşüyor" değil, "hangi katmanda düşüyor" olmalı. Bunu ayırmadan yapılan her müdahale, ertesi hafta geri gelen bir yamadır.
Session verisi gerçekte nereye yazılıyor ve onu kim siliyor?
Panelinde bir müşteri giriş yaptığında sunucu ona bir kimlik numarası verir ve bu numaraya ait veriyi diske yazar. Ömrü iki ayardan belirlenir: verinin ne kadar süre geçerli sayılacağı ve temizleyicinin ne sıklıkla devreye gireceği. Paylaşımlı planlarda bu değerleri sen değiştirsen bile sistem geneli temizleyici senin dosyanı yaş sınırına göre siler. Sonuç: bakiyesi yüklü müşteri, ödeme sayfasından dönerken sıfırlanmış bir oturumla karşılaşır.
Kalıcı çözüm dosyadan çıkmaktır. Oturumu veritabanı tablosunda ya da bellek tabanlı bir depoda tutmak, ömür kontrolünü tamamen senin eline verir. Aynı zamanda oturumları uzaktan sonlandırma yetisi kazanırsın: şüpheli bir giriş gördüğünde ilgili satırı silip o cihazı anında dışarı atabilirsin. Dosya tabanlı kurulumda bunu yapmanın yolu yoktur. Bir dijital ürün satış yazılımı için bu, konfor değil güvenlik meselesidir; çünkü e-pin panelinde ele geçen bir oturum doğrudan paraya dönüşür.
| Belirti | Muhtemel katman | Nasıl doğrularsın | Kalıcı çözüm |
|---|---|---|---|
| Oturum düzensiz, 10-30 dk arası düşüyor | Depolama (dosya temizleyici) | Oturum dosyasının diskten kaybolduğunu izle | Oturumu veritabanına taşı |
| Ödeme dönüşünde her seferinde çıkış | Çerez (alan adı / güvenli bayrak) | Dönüş isteğinde çerezin gönderilip gönderilmediğine bak | Çerez alan adını ve site bağlamını düzelt |
| Sayfada başka kullanıcının adı görünüyor | Önbellek / CDN | Yanıt başlıklarında önbellek işaretini kontrol et | Oturumlu sayfaları önbellekten çıkar |
| Bazı girişler tutuyor, bazıları tutmuyor | Çoklu sunucu dağıtımı | Aynı kullanıcıyı iki istekte hangi düğüm karşıladı | Merkezî oturum deposu kullan |
| Panele girdikten 2 saniye sonra çıkış | Uygulama (kimlik doğrulama döngüsü) | Yönlendirme zincirini baştan sona izle | Yetki kontrolünü tek noktada topla |
Çerez ayarları sepetini nasıl sessizce boşaltıyor?
Oturum verisi sunucuda sapasağlam dururken müşteri yine de çıkış yapıyorsa suçlu çerezdir. En sık rastlanan üç hata şudur: çerez yalnızca güvenli bağlantıda gönderilecek şekilde işaretlenmiştir ama bazı sayfalar hâlâ güvensiz adresten servis edilir; çerez ana alan adına değil alt alan adına yazılmıştır, dolayısıyla panel ile ödeme dönüş adresi birbirini görmez; ya da çerezin site-arası davranışı çok katı ayarlanmıştır ve ödeme sağlayıcısından gelen dönüş isteğinde tarayıcı çerezi hiç göndermez.
Üçüncüsü, son yıllarda e-pin satış yazılımı kullanan işletmelerin en çok kanadığı noktadır. Tarayıcılar varsayılan davranışı sıkılaştırdı; eski kurulumlar bu değişikliği hesaba katmadığı için ödeme dönüşü çalışmaz oldu. Müşteri parayı ödedi, siteye döndü, giriş ekranını gördü ve haklı olarak "param gitti" diye yazdı. Çerez politikasını ödeme akışıyla uyumlu kurmak, tek satırlık bir ayarla önlenebilecek yüzlerce destek talebini ortadan kaldırır.
Panel oturumu neden düşüyor? Vaka dağılımı
- Dosya tabanlı oturum silinmesi 45%
- Çerez alan adı / bağlam hatası 25%
- Önbellek ve CDN karışması 20%
- Uygulama içi yetki döngüsü 10%
Önbellek ve çoklu sunucu: aynı müşteri iki farklı beyne bağlanırsa
Trafiği hızlandırmak için önüne bir önbellek katmanı koyduğunda, o katmanın oturumdan haberi yoktur. "Hesabım" sayfası bir kez önbelleğe alınırsa, sonraki ziyaretçi başka birinin bakiyesini görür. Bu yalnızca bir hata değil, veri sızıntısıdır. Çözüm basittir ama atlanır: giriş gerektiren her adres önbellek kapsamından çıkarılmalı, yalnızca ürün listesi ve içerik sayfaları hızlandırılmalıdır.
Yükü iki sunucuya dağıttığında ise tablo değişir. Müşteri ilk isteği birinci düğümde karşılar, oturum orada yazılır; ikinci isteği diğer düğüme düşer ve orada oturum yoktur. Kullanıcı için bu, "bir giriyorum bir çıkıyorum" hissidir. Tek çare oturumu her iki düğümün eriştiği merkezî bir depoda tutmaktır. Büyümeyi planlıyorsan bunu trafik gelmeden kurmak gerekir; canlı kampanya gününde yapılan mimari değişiklik en pahalı değişikliktir.
Yönetici oturumu ile müşteri oturumunu ayırmayan bir e-pin scripti neden risklidir?
Pek çok kurulumda yönetim paneli ile müşteri paneli aynı oturum mekanizmasını paylaşır. Sen oturum ömrünü uzatınca, yönetici oturumu da gereksiz uzun süre açık kalır. Tersini yapıp ömrü kısaltınca müşteri alışverişin ortasında dışarı atılır. İki tarafın ihtiyacı birbirine zıttır: yönetici için kısa ömür ve hareketsizlik kilidi doğruyken, müşteri için uzun ömür ve yumuşak yenileme doğrudur.
Sağlam bir e-pin scripti bu ikisini ayrı tutar. Yönetici tarafında IP değişiminde yeniden doğrulama, kritik işlemlerde parola tekrarı ve aktif oturum listesi bulunur. Müşteri tarafında ise oturum sessizce yenilenir, sepet oturumdan bağımsız saklanır ve ödeme dönüşü kimlikten değil sipariş anahtarından doğrulanır. Böylece oturum bir an için kaybolsa bile sipariş kaybolmaz. Kritik olan cümle bu: siparişin hayatta kalması oturumun hayatta kalmasına bağlı olmamalı.
Ödeme dönüş adresini oturumdan tamamen bağımsız hâle getir. Dönüşü, tahmin edilemez tek kullanımlık bir sipariş anahtarıyla doğrula. Oturum düşse de müşteri kodunu görür, sen de destek talebi almazsın.
Pinova bu katmanları nasıl tek noktada topluyor?
Pinova bir e-pin satıcısı değil, e-pin ve dijital ürün satan işletmelerin kullandığı lisanslı yönetim yazılımıdır. Oturum konusunu kurulum sonrası düzeltilecek bir detay olarak değil, mimarinin parçası olarak ele alır. Oturumlar veritabanı destekli tutulur, ömürleri yönetici ve müşteri için ayrı tanımlanır, aktif oturumlar panelden görülüp tek tıkla sonlandırılabilir. Ödeme dönüşü sipariş anahtarıyla doğrulandığı için çerez kaybı satışı öldürmez.
Bunun yanında önbelleğe alınmaması gereken adresler varsayılan olarak işaretlenir, güvenli bağlantı zorlanır ve çerez bağlamı ödeme akışına uygun gelir. Yani bir dijital ürün satış scripti seçerken sorman gereken soru "tasarımı güzel mi" değil, "oturumu nerede tutuyor ve kim sonlandırabiliyor" olmalı. Özellik listesini özellikler bölümünde, lisans seçeneklerini fiyat bölümünde karşılaştırabilirsin.
| Kontrol | Nerede bakılır | Beklenen durum | Yanlışsa sonuç |
|---|---|---|---|
| Oturum depolama tipi | Uygulama yapılandırması | Veritabanı veya bellek deposu | Rastgele oturum kaybı |
| Oturum ömrü ayrımı | Yönetici / müşteri ayarları | Yönetici kısa, müşteri uzun | Ya güvenlik ya satış kaybı |
| Çerez alan adı | Çerez tanımı | Ana alan adını kapsar | Ödeme dönüşünde çıkış |
| Site-arası çerez davranışı | Çerez bayrakları | Ödeme dönüşüne uygun | Tarayıcı çerezi göndermez |
| Önbellek istisnaları | Önbellek / CDN kuralları | Giriş gerektiren adresler dışarıda | Başka kullanıcının verisi görünür |
| Aktif oturum listesi | Yönetim paneli | Görülebilir ve sonlandırılabilir | Ele geçen oturum kapatılamaz |
| Ödeme dönüş doğrulaması | Sipariş akışı | Tek kullanımlık sipariş anahtarı | Ödeyen müşteri kodunu göremez |
Oturum sorununu yama ile değil mimariyle çöz
Pinova lisansıyla oturum yönetimi, ödeme dönüşü ve panel güvenliği tek yapı altında gelir. Her sorun için ayrı eklenti aramazsın.
Oturum ömrünü çok uzun yapsam sorun çözülür mü?
Hayır. Dosya tabanlı kurulumda sistem temizleyicisi ömür ayarına bakmadan eski dosyaları siler. Ayrıca uzun ömür yönetici tarafında ciddi güvenlik riski yaratır. Önce depolama katmanını değiştirmen gerekir.
Ödeme sağlayıcısından dönerken neden hep çıkış yapılıyor?
Büyük olasılıkla çerezin site-arası davranışı ya da alan adı kapsamı hatalıdır. Kalıcı çözüm, dönüşü oturuma değil tek kullanımlık sipariş anahtarına bağlamaktır.
Önbellek kullanmayı tamamen bırakmalı mıyım?
Gerek yok. Ürün listeleri ve içerik sayfalarını hızlandır, giriş gerektiren tüm adresleri önbellek kapsamından çıkar. Böylece hem hız hem veri güvenliği korunur.
Bu düzeltmeleri mevcut kurulumumda yapabilir miyim?
Çoğu durumda evet, ancak oturum ve ödeme akışı birbirine sıkı bağlanmışsa dokunmak riskli olur. Bu yüzden yapıyı baştan doğru kuran bir yazılım uzun vadede daha az maliyetlidir.
Oturum düşmesi bir kader değil, ölçülebilir bir mühendislik sorunudur. Yukarıdaki kontrol listesini kendi panelinde tek tek işaretlediğinde hangi katmanda kanadığını bir saat içinde bulabilirsin. Doğru kurulmuş bir yapının nasıl davrandığını kendi gözünle görmek istersen canlı demo üzerinden giriş yap, ödeme akışını baştan sona dene ve oturumun tek bir adımda bile kopmadığını test et.