Laravel Auth’u Fortify Üzerine Yeniden Oluşturdum (Entegrasyonun Belirlediği İki Hata)

Geçtiğimiz sefer v0.1.0 sürümünü etiketlediğim LaraFoundry, bir canlı CRM’den açık bir şekilde çıkardığım Laravel SaaS çekirdek katmanıdır. Sadece temel bileşenler: locale, filtreler, middleware, küçük bir Vue UI kit. Henüz kimlik doğrulama yok.

Bu yazı v0.2.x: kimlik doğrulama ve kullanıcılar. Ve iki hatanın 114 testin geçmesini sağladıktan sonra gerçek bir uygulamada paketimi bağladığımda ortaya çıktığı yer. Onlar hakkında yazının sonunda daha fazla bilgi vereceğim; çünkü dürüstçe söylemek gerekirse, en faydalı kısım buydu.

Önemli karar: Kimlik doğrulama işlemini kendiniz yazmayın

Eski CRM kendi kimlik doğrulamasına sahipti. Altı giriş yöntemi, özel oran kısıtlaması, el ile yazılmış bir sınırlayıcı, ve tek paylaşılmış sır üzerinde çalışan bir admin 2FA. Yıllarca iş gördü. Ama bu tür bir kodu çıkarken tekrar okuduğunuzda, Laravel’in zaten doğru bir şekilde çözdüğü güvenlik açısından kritik olan birçok detay olduğunu fark ediyorsunuz.

Bu yüzden erken bir karar aldım: çekirdek Laravel Fortify üzerine inşa edilecek, eski kontrolcülerin bir kopyası üzerine değil.

Fortify, Jetstream’in arkasındaki başsız kimlik doğrulama arka ucudur. Size oturum açma, kayıt, şifre sıfırlama, e-posta onayı, şifre onayı ve gerçek kullanıcı bazında iki faktörlü kimlik doğrulama (TOTP + yedek kodlar + QR kaydı + onay adımı) sunar. Görünümler yok, sadece yollar ve eylemler. Ön yüzünüz Inertia + Vue olduğunda tam olarak ihtiyacınız olan şey budur.

Uymaya çalıştığım kural: Eğer Fortify bunu yapıyorsa, ben yazmam. Çekirdek yalnızca Fortify’nin kapsamadığı şeyleri ekler.

Çekirdek Fortify etrafında ne ekliyor

Fortify, sıkıcı ve doğru olan merkezdir. Paket, gerçekten bana ait olan şeylerle onu sarar:

• Oturum takibi. Her cihaz için bir satır; parmak izi (tarayıcı, OS, tip), IP, giriş yöntemi, son etkinlik, son yol. Bu, “aktif oturumlar” ekranını ve “diğer cihazlarımı çıkış yap” butonunu güçlendirir.
• Socialite ile OAuth. Fortify sosyal girişi ele almıyor. Paket, yönlendirme/geri çağırmayı üstleniyor ve bir hesap ele geçirme koruması sağlıyor.
• Engellenmiş / silinmiş erişim. Middleware olarak bir istek başına, oturumda engellenmiş veya yumuşak silinmiş bir hesabı çıkış yaptırır.
• Bir IsLaraFoundryUser trait. Ana kullanıcının modeli, kimlik, yerel ayar, OAuth alanları, 2FA ve oturum takibi almak için bunu kullanır; şirketler veya roller hakkında bir şey miras almaz. Bunlar, daha sonraki aşamalarda ayrı özelliklerdir, böylece bir model bunları birleştirebilir.
• Yerelleştirilmiş kimlik doğrulama e-postası. Doğrulama ve sıfırlama e-postaları, çekirdek tarafından çeviri anahtarları aracılığıyla işletilir, bu nedenle v0.1.0’dan itibaren yerelleştirilmiş olarak gönderilir ve İngilizce’nin sabit kodlamasını takip etmez.
• Inertia/Vue sayfaları. Giriş, kayıt, unutma/sıfırlama, onaylama, 2FA engeli, 2FA ayarları, engellenmiş ekran. Fortify başsız olduğundan, UI bizimdir.

Tüm bunlar, Pest (arka uç) ve Vitest (Vue sayfaları ve UI kit) ile kaplanmış, PHP 8.2/8.3/8.4’te yeşil CI ile çalışır.

Konuşmaya değer OAuth koruyucusu

İşte eski uygulamadan basitleştirilmiş orijinal OAuth geri çağırma:

$user = User::updateOrCreate(
    ['email' => $socialUser->email],
    [/* sağlayıcı alanları, email_verified_at => now() */]
);
Auth::login($user);

<svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewbox="0 0 24 24" class="highlight-action crayons-icon highlight-action--fullscreen-off"><title>Fullscreen modundan çık</title>
<path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"/>

Güzel görünüyor. Ama değil.

Eğer [email protected] adresinde (şifre ile kayıtlı) yerel bir hesap varsa ve saldırgan, aynı e-postayı belirten bir Google hesabını kontrol ediyorsa, bu updateOrCreate olayını sessizce kurbanın hesabına bağlar ve oturum açar. Hesap ele geçirme, herhangi bir istismar gerektirmeden, sadece bir e-posta çarpışması ile mümkündür.

Çekirdek, kesinlikle şunlarla çözülür:

1. ilk olarak sağlayıcı kimliği (provider_name + provider_id) ile eşleşme, bu tek koşulsuz eşleşmedir;
2. eğer bu kaçarsa ancak e-posta yerel bir hesapla eşleşirse, yalnızca link_existing açıkça etkinleştirildiğinde bağlanır, aksi halde reddedilir ve kullanıcıya öncelikle yerel olarak oturum açması ve ayarlardan sağlayıcıyı bağlaması söylenir;
3. aksi takdirde yeni bir hesap oluşturulur.

Varsayılan refüze etmektir. Bir Pest testi, ele geçirme durumunu belirler, böylece geriye dönemez.

(Burada henüz tam olarak kapatmadığım ikinci, daha dar bir sorun var: yeni bir OAuth hesabı, sağlayıcının e-postasını doğrulamak için email_verified_at = now() değerine sahip olmaktadır. Google/GitHub’ın birincil e-postası için bu iyi, ancak OAuth’u üretim aşamasında etkinleştirmeden önce bunu sertleştirme görevi olarak not ettim. Dürüstlük, parıltıdan daha önemlidir.)

Şimdi iki hata

Gerçekten yazmak istediğim kısım burası, çünkü her ikisi de tüm birim testlerinden geçmesine rağmen, yalnızca paket gerçek bir Laravel uygulamasıyla buluştuğunda ortaya çıktı.

Hata 1: Yanlış olayda oturum takibi

İlk tasarımım, Laravel’in Login olayını dinleyerek oturum satırını kaydediyordu. Temiz, çerçeveye özgü, kayıtlama ve kayıt dahil her giriş yolu için ateş ediliyor. Testler başarılıydı.

Sonra gerçek ana makinemde oturum açtım ve hemen giriş ekranına geri döndüm.

Görünüşe göre Login olayı, kimlik doğrulama koruması içinde ateş ediliyordu ve Fortify, oturum kimliğini bir kez daha yeniden oluşturuyordu, bu da PrepareAuthenticatedSession adımında gerçekleşiyordu. Böylece dinleyicim, bir milisaniye sonra ölü bir oturum kimliğine bağlı bir satır yazdı. Sonra “bu oturum hala geçerli mi” kontrolüm bir uyuşmazlık gördü ve kullanıcıyı her seferinde çıkış yaptırdı.

Birim testleri bunu yakalayamadı çünkü ayrı bir bağlamda ikinci bir yeniden oluşturma yoktu. Zamanlama etkileşimde kalmak için gerçek Fortify hattını gerektiriyordu.

Düzeltme, olayı takip etmeyi durdurmak ve izlemeyi, son canlı oturum kimliğine karşı çalışan bir istek başına middleware’a taşımak oldu. Eski miras uygulamanın yaptığı şeyin tam olarak bu olduğunu söyledim. Bazen sıkıcı eski yaklaşımın bir nedeni vardır. Ek bonus: aynı zamanda last_activity ve last_route_name’i de yeniden canlandırdı, çünkü olay tabanlı versiyonum girişten sonra hiçbirini güncelleyemiyordu.

Hata 2: views => false Inertia’da bir tuzdur

Bu kısım hızlı ama iyi bir yarım saat kaybettim.

Bir SPA için, 'views' => false değerini config/fortify.php dosyasında otomatik olarak ayarlamak içgüdüseldir. Mantıklıdır, değil mi? Fortify’nin Blade oluşturmasını istemezsiniz, ön yüz ekranları halleder.

Fakat views => false, sadece görünüm oluşturma işlemini atlamakla kalmaz. Fortify’nin GET yollarını da tamamen kaydetmesini durdurur. Bu nedenle GET /login 405 döner ve Fortify::loginView(...) kapalı kalır.

Inertia için doğru ayar, 'views' => true ile birlikte bir loginView‘dir ve bu da Inertia::render('Auth/Login') döner. Fortify yönlendirmeleri yönetirken, sizin kapalı alanınız bunu görüntüler. Belgeler bunu söylüyor; ben sadece “SPA = görünüm kapalı” kalıbı ile ileri gittim ve geçtim.

Çıkarım

114 test, birimlerin doğru olduğuna güven verdi. Gerçek uygulamada parçaların bir araya gelip gelmediği hakkında hiçbir şey söylemedi. Entegrasyon duman testi, sadece ana makineyi başlatmak ve kayıt/login/2FA’yı elle tıklamak, her iki gerçek hata da burada yaşıyordu.

Bu nedenle iş akışı devam ediyor: çıkarmak, modernize etmek, test etmek, gözden geçirmek, etiketlemek, ve sonra her şeyi gerçek bir uygulamada çalıştırmadan hiçbirine inanmayın.

Bir sonraki aşama çoklu kiracılık, şirket/takım katmanını aynı üretim sisteminin dışına almak. Bu beni biraz korkutuyor.

Kod GitHub‘da. Eğer Fortify üzerinde benzer bir şey inşa ediyorsanız, oturum-id zamanlama sorununu da yaşayacaksınız, artık bunu biliyorsunuz.