Paddle'ın onaylı alan adı denetimi yalnızca tarayıcıdaki checkout'u kısıtlar, sunucu tarafındaki faturalandırmayı değil

Onaylı alan adı listesi gerçekte neyi kapsıyor

dev.to'da yazan bir geliştirici, Paddle'ın faturalandırma platformu hakkında, küçük ürünlerden oluşan portföyündeki ödemeleri nasıl ele aldığını baştan aşağı değiştiren bir bulguyu belgeledi — tarayıcı eklentileri, SaaS araçları ve bir oyun, her biri kendi alt alan adında. Çalışma varsayımı, para toplayan her sitenin Paddle'ın onaylı alan adı listesinde kendi kaydına ihtiyaç duyduğu, yani her yeni alt alan adı için bir inceleme döngüsü gerektiği yönündeydi.

Gönderiye göre liste bundan çok daha azını denetliyor. Yalnızca Paddle.js checkout katmanının tarayıcıda nerede çalışabileceğini kontrol ediyor, başka hiçbir şeyi değil. Yazar, üzerinde hiç alan adı denetimi olmayan üç sunucu tarafı işlem sıralıyor: webhook imzalarının doğrulanması, API anahtarıyla müşteri portalı oturumu açılması ve yönlendirilen olayları alan satıcının kendi endpoint'leri. Tüm ödeme akışı boyunca yalnızca checkout katmanının açılması onaylı bir alan adına bağlı.

Her ürün için tek webhook

Bu keşif, yazarın faturalandırmayı tek bir kuruluma indirmesini sağladı: tek bir Paddle hesabı, apex'te tek bir onaylı alan adı ve tüm ürün ailesine hizmet eden o apex'te tek bir webhook endpoint'i. Endpoint, Paddle'ın imzasını doğruluyor, kaynak siteyi tanımlayan tek bir alanı okuyor ve buna göre yönlendiriyor — apex'e ait olaylar yerel olarak işleniyor, diğer sitelere ait olaylar hiç dokunulmadan onlara iletiliyor, bilinmeyen bir site adı geçen olaylar ise 200 yanıtıyla cevaplanıp bırakılıyor. Yazar son kuralı zor yolla öğrendi: 500 ile yanıt vermek, sağlayıcıyı sizin önce bıktığınız bir geri çekilme döngüsüne sokuyor.

Tasarımı temiz tutan iki kısıt var. Dağıtıcı, fiyat ID'leri veya planlar hakkında hiçbir bilgi taşımıyor — fiyatları yetkilendirmelere eşleme, olaya sahip olan sitede kalıyor — böylece ürün eklemek hiçbir zaman paylaşılan kodu düzenlemek anlamına gelmiyor. Her uydu site, apex zaten doğruladığı için Paddle'ın imzasını yeniden doğrulamadan iletilen bir olayı kabul eden, timingSafeEqual ile karşılanan paylaşımlı bir bearer secret ile korunmuş tek bir dahili endpoint sunuyor. Yerini alan doğrudan webhook rotaları, 410 dönen taslaklar olarak bırakıldı; böylece bayat dashboard yapılandırmaları sürünmek yerine görünür biçimde başarısız oluyor.

Checkout'u apex alan adına devretmek

Bir uydu, kendi onaylanmamış alan adında checkout katmanını açamaz; bu yüzden yönlendirme yapıyor. Kısa ömürlü bir payload imzalıyor — uydunun kimliği, yerel bir kullanıcı ID'si, e-posta, fiyat ID'leri ve miktarlarla satır kalemleri, ortam, bir başarı URL'si, en fazla beş dakika sonrası bir sona erme ve bir nonce — base64url ile kodlanmış JSON artı bir HMAC-SHA256 etiketi olarak, sonra alıcıyı 302 ile apex'e gönderiyor. Apex, token'ı doğruluyor ve checkout katmanını tam olarak içeriğiyle açıyor.

Yazar, bunu güvenli kılan ayrıntıları tek tek vurguluyor. Başarı URL'si bir host allowlist'e karşı doğrulanıyor; çünkü imzalı ama doğrulanmamış bir yönlendirme hedefi, güvenilir görünen açık bir yönlendirmeye dönüşür. Ortam bayrağı token'ın içinde taşınıyor; böylece apex, sandbox veya production client token'ını kendi runtime'ına göre değil, token'ın söylediğine göre seçiyor — aksi halde bir sandbox testi sonunda gerçek bir borç olarak karşınıza çıkabilir. Nonceler sunucu tarafında saklanmıyor; yazar, gerçek tekrar oynatma korumasının, zaten aşağı akışta var olan, olay ID'sine göre anahtarlanmış webhook idempotency'sinden geldiğini savunuyor. Abonelik yönetimi de aynı kalıbı izliyor: uydular müşteri ve abonelik ID'lerini içeren bir payload imzalıyor ve barındırılan portal oturumunu yalnızca apex — API anahtarının tek sahibi — oluşturuyor; böylece her site için değil, döndürülmesi gereken tek bir sır oluyor.

Birleşmenin maliyetleri

Ödünleşimler teknik değil ticari. Ana hesap her ürün için kayıtlı satıcı olduğundan, checkout sayfaları, faturalar ve makbuzların tümü ana hesabın adını taşıyor ve bunları white-label olarak gizlemenin bir yolu yok. Ürünler kendilerini bağımsız şirketler olarak sunamaz; devir işleminin, birbirine ilgili ürün grubu için paylaşılan tek bir checkout olarak dürüstçe okunması gerekiyor. Yazar daha küçük bir kusuru da kabul ediyor: iki uydu, ortam seçici değişkenlerini farklı yazıyor ve sistem, bu tutarsızlık karışıklığa yol açmadan önce hiçbir şekilde tespit etmiyor.

Neden önemli

Satıcılar için pratik ders şu: Paddle'ın onaylı alan adı listesi bir tarayıcı sunum denetimi, sunucu tarafı bir zorlama sınırı değil. Onu faturalandırma trafiğinin nereden gelebileceğine dair bir kapı olarak gören herkes, savunmanın yanlış hattına güveniyor. Bu kurulumda önemli olan korumalar, yazarın kendisinin inşa ettikleri: tek bir güvenilir noktada imza doğrulama, kısa ömürlü imzalı devirler, allowlist'e alınmış yönlendirmeler ve merkezi anahtar saklama. Gönderiden çıkarılacak daha geniş ders, bir satıcının kısıtının tam olarak neyi kapsadığını, etrafına tasarım yapmadan önce kontrol etmektir — yazar, aylarca sonunda yalnızca tek bir satır tarayıcı koduna dokunan bir inceleme sürecinin etrafından dolaşarak zaman harcadı.