refactor(pl24): oturum modeli — tek login, çerez tabanlı authorize yenileme #261
Reference in New Issue
Block a user
Delete Branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Faz 1 / adım 1: PL24 oturum modeli. Analiz
/home/s/ss/plv2.md§4.1 (bulgular auth-02/03/05/06/09/11/15, p4legacy-07, consumers-04).Sorun
PL24'ün base JWT'si 600 saniye yaşıyor ve kod bunu oturum sayıyordu:
isTokenValid→login(squeezeOut:true). Talep varsa her ~9 dakikada bir yeniden login (günde ~144/hesap). PL24 hesap başına tek oturum verdiği için bu hem kendi oturumumuzu sürekli düşürüyor hem de iki hesap banından (tr 2026-07-24, de 2026-09-04) önceki otomasyon imzasını oluşturuyordu. Canlı kanıt: her boot'ta prewarm iki paralel login atıyor ve biriHTTP 500alıyordu (logins 1/2).Portalın kendisi bir kez login olup
PL24TOKENçerezini saklıyor, sonra yalnızauthorize'ı yeniliyor. Artık biz de öyle yapıyoruz.Değişiklik
ensureSession()sahibi; Redis'tepl24:auth:session:<hesap>ile 24 saat paylaşılır, api ve worker aynı oturumu devralır. Süre kontrolü yok — oturum yalnız sunucu reddedince düşer.Cookie: PL24TOKENile istenir (Bearer gerekmiyor, canlı doğrulandı).session_status:"gone"ve authorize 401/403 artık okunuyor → oturum düşürülür, tek sefer yeniden login + retry./auth/ext/api/1.1/login, RFC7807 problem gövdesi tiplendi. ÖncesqueezeOut:false, yalnız session-limit'tesqueezeOut:true.PL24_LOGIN_API=legacyeski uca döner (geri çekilme bayrağı).ensureSession'a indirildi; demo-sayfa/401 çaresi artık oturum yenileme.pl24-wmidata(portal WMI decode hazırlığı); ölü kod silindi (base-JWT yolu, hasService, getAvailableServices, AUTH_TOKEN_TTL).Doğrulama
pl24-auth.service.spec.tsyeniden yazıldı — 19 test (tek login, single-flight, Redis devralma, cookie-only authorize, gone/401 yeniden login, 412/400 squeezeOut, P4 cookie-only header, kalıcı hata kesicisi, saatlik tavan). Tüm PL24 + tüketici paketleri 188 test geçti;tscvebiometemiz.e50a907deploy edildi (2489), temiz boot, PL24 dev'de kapalı olduğu için ağa çıkmadı.squeezeOut:falseile login denemesi →HTTP 400 application/problem+json,type: urn:login:session-limit-exceeded,Set-CookieYOK (oturum düşmedi). Kod hem 400 hem 412'yi bu tip için işliyor.Risk / geri alma
Dev'de canlı PL24 doğrulaması bilinçli yapılmadı: dev login atarsa prod oturumunu düşürür. Prod'da merge sonrası ilk boot gerçek doğrulama olacak; beklenen log
PL24 login (de) successful — session establishedve ardındanAuthorizing service ... for account de. Sorun çıkarsaPL24_LOGIN_API=legacyeski login ucuna döner; tam geri almagit revert+ redeploy.Beklenen etki: günlük login sayısı ~144'ten 0-1'e, P4 sayfa başına authorize isteği sıfıra iner.
🤖 Generated with Claude Code
Faz 1 / adım 1 (analiz: /home/s/ss/plv2.md §4.1, bulgular auth-02/03/05/06/09/11/15, p4legacy-07, consumers-04). SORUN: PL24'ün base JWT'si 600 saniye yaşıyor ve kod bunu "oturum" sayıyordu (isTokenValid → login). Talep varsa her ~9 dakikada bir squeezeOut:true ile YENİDEN LOGIN atılıyordu (günde ~144 login/hesap). PL24 hesap başına tek oturum veriyor; bu desen hem kendi oturumumuzu sürekli düşürüyor hem de iki hesap banından önceki otomasyon imzasını oluşturuyordu. Portalın kendisi bir kez login olup PL24TOKEN çerezini saklıyor ve yalnız authorize'ı yeniliyor. DEĞİŞİKLİK: - Oturum = PL24TOKEN çerezi (süresiz). `ensureSession()` sahibi; bellekte tutulur, Redis'te `pl24:auth:session:<hesap>` ile 24 saat paylaşılır (api/worker aynı oturumu devralır). Süre kontrolü YOK — oturum yalnız sunucu reddederse düşer. - Servis token'ı = authorize ile mint edilen 600 s'lik JWT; yalnız `Cookie: PL24TOKEN` ile istenir (Bearer gerekmiyor — canlı doğrulandı). - `session_status:"gone"` ve authorize 401/403 artık okunuyor: oturum düşürülür, tek sefer yeniden login + retry. - Single-flight: süreç içi in-flight promise + Redis kilidi (`pl24:auth:login-lock:<hesap>`), kilidi alamayan paylaşılan oturumu bekler. Eski prewarm iki paralel login atıyordu ve biri her boot'ta HTTP 500 alıyordu. - Login sözleşmesi: portal ucu `/auth/ext/api/1.1/login` ({account,user,password,squeezeOut} → {loginStatus,sessionToken} + Set-Cookie); RFC7807 problem gövdesi tiplendi. Önce squeezeOut:false denenir, yalnız "session-limit-exceeded"/USER_ALREADY_LOGGED_IN'de squeezeOut:true ile tekrar. `PL24_LOGIN_API=legacy` eski uca döner (bir sürüm geri çekilme bayrağı). - Hata sınıflandırma: account-not-active / user-not-active / authentication / 2FA-required → ilk hatada 6 saatlik devre kesici (eskiden ölü hesap 5 dakikada bir sonsuza dek deneniyordu: prod'da 376 ardışık 401). Ağ/timeout → 5 dakika. - Saatlik login tavanı (hesap başına 6) — sağlıklı günde 0-1 login beklenir. - P4 (.action) sayfaları için authorize kaldırıldı: yalnız çerez gönderiliyor (canlı doğrulandı). Ford/PSA'daki 18 "ısıtma" authorize çağrısı ensureSession'a indirildi; demo-sayfa/401 çaresi artık servis token temizleme değil oturum yenileme. - Gerçek Chrome User-Agent sabiti (eski değer hiçbir tarayıcıda yok). - authorize'a `pl24-wmidata` eklendi (portal WMI decode'u için ön hazırlık). - Ölü kod silindi: getAccessToken*/getSessionCookie* base-JWT yolu, hasService, getAvailableServices, AUTH_TOKEN_TTL. Test: pl24-auth.service.spec.ts yeniden yazıldı (19 test: tek login, single-flight, Redis devralma, cookie-only authorize, gone/401 yeniden login, 412 squeezeOut, P4 cookie-only header, kalıcı hata kesicisi, saatlik tavan). Tüm PL24 + tüketici paketleri: 188 test geçti. tsc + biome temiz. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>