WordPress Eklenti Lisans Sistemi: Lisans Sunucusu Nasıl Kurulur?

Ücretli bir WordPress eklentisi geliştirdiğinizde asıl soru yazılımı yazmak değil, onu nasıl satıp güncelleyeceğinizdir. Müşterinin lisansını kontrol eden, siteye güncelleme dağıtan ve kötüye kullanımı sınırlayan bir lisans sistemi gerekir. Bu yazıda, kendi lisanslı ürünümüz AYM Multilingual'ı işletirken öğrendiğimiz mimariyi ve tuzakları anlatıyoruz.

Önce şunu netleştirin: GPL ve lisans anahtarı

WordPress GPL lisanslıdır ve eklentiler de GPL uyumlu olmak zorundadır. Bu, kodun kendisini kilitlemeye çalışmanın boşuna olduğu anlamına gelir. Sattığınız şey kod değil; güncellemeler, destek, hizmet ve ürüne bağlı sunuculardır. Lisans anahtarı bu hizmetlere erişim hakkını yönetir. Bu çerçevede düşündüğünüzde sistem de sadeleşir: amaç korsanlığı sıfırlamak değil, dürüst müşteriyi rahat ettirip ödeme yapmadan kullananı güncelleme ve destekten uzak tutmaktır.

Bu yüzden lisans mesajlarınızda da dürüst bir dil kullanın: “lisansınız geçersiz, eklenti kilitlendi” yerine “güncelleme ve destek için lisansınızı etkinleştirin” demek hem GPL ruhuna hem müşteri ilişkisine daha uygundur.

Lisans sunucusunun dört temel bileşeni

1. Lisans veritabanı: Anahtar, plan, geçerlilik tarihi, site sayısı sınırı ve etkinleştirilen alan adlarını tutar.
2. Aktivasyon ve doğrulama API'si: Eklenti, anahtar ve site adresini sunucuya gönderir; sunucu geçerli, süresi dolmuş veya limit aşılmış gibi bir yanıt döner.
3. Güncelleme servisi: Geçerli lisansa yeni sürümün bilgisini ve indirme adresini verir.
4. Yönetim paneli ve ödeme bağlantısı: Ödeme tamamlanınca anahtar otomatik üretilir; yenileme, iptal ve site devri panelden yönetilir.

Aktivasyon akışı nasıl tasarlanır?

Kullanıcı eklentinin lisans sayfasına anahtarı girer. Eklenti, anahtarı, site alan adını ve eklenti sürümünü HTTPS üzerinden lisans sunucusuna POST eder. Sunucu anahtarı doğrular, plana göre izin verilen site sayısını kontrol eder ve alan adını kaydeder. Alan adını karşılaştırırken normalleştirme yapın: www ve www'siz, http ve https, sondaki eğik çizgi gibi farklar aynı site sayılmalı; geliştirme ve staging ortamları için ayrı bir kural belirleyin. Müşteri başka bir siteye taşınmak istediğinde, eskisini panelden veya eklentiden devre dışı bırakıp hakkını yeniden kullanabilmelidir. Bu, destek yükünüzü büyük ölçüde azaltır.

Kendi ürünümüzde de bu yaklaşımı kullanıyoruz: AYM Multilingual lisansı plana göre site hakkı tanır ve istenirse bir siteyi devre dışı bırakıp hak başka siteye taşınabilir.

Lisans modelini ürününüze göre seçin: yıllık abonelik (güncelleme ve destek süresi bir yıl), ömür boyu lisans, çok siteli ajans paketi ya da deneme sürümü. Yıllık modelde yenileme hatırlatma e-postaları ve süre dolmadan önceki bildirimler gelirinizi doğrudan etkiler. Ajans paketlerinde tek anahtarın birden fazla sitede kullanılabilmesi gerekir; bu da veritabanında anahtar başına etkin site listesi tutmak demektir. Planları baştan esnek bir tabloyla modellemek, sonradan yeni paket eklemeyi kolaylaştırır.

Doğrulama sıklığı ve çevrimdışı dayanıklılık

Lisansı her sayfa yüklemesinde kontrol etmek hem siteyi yavaşlatır hem sunucunuzu yorar. Sonucu transient olarak saklayıp günde bir veya birkaç günde bir WP-Cron ile arka planda doğrulamak yeterlidir. Lisans sunucunuz ulaşılamazsa müşterinin sitesi bozulmamalı: son geçerli durumu belirli bir tolerans süresince kabul edin. Süresi dolan lisans, eklentinin çalışmasını durdurmamalı; genellikle yalnızca güncelleme ve destek erişimini kapatır. Müşteri sitesini kilitleyen bir lisans sistemi güvenini ve itibarınızı kaybettirir.

Pratik bir kural: doğrulama isteği yönetim paneline giriş gibi uygun anlarda tetiklensin, ön yüz ziyaretçisinin sayfa yüklemesini asla bekletmesin. İstek zaman aşımı kısa tutulmalı ve başarısız olursa sessizce bir sonraki denemeye bırakılmalıdır. Kullanıcıya belirsiz bir hata yerine “lisansınızı yenilemeniz gerekebilir” gibi yol gösteren bir mesaj gösterin; müşteri desteğine düşen taleplerin çoğu belirsiz hata mesajlarından gelir.

Otomatik güncelleme dağıtımı

WordPress dışındaki bir adresten güncelleme sunmak için eklenti, güncelleme kontrolüne (pre_set_site_transient_update_plugins filtresi) ve eklenti bilgi ekranına (plugins_api filtresi) kanca atar. Lisans sunucunuz sürüm numarasını, changelog'u, WordPress ve PHP gereksinimlerini ve imzalı bir indirme adresini döner. Paket yalnızca geçerli lisansa sahip sitelere, süreli ve imzalı bir bağlantıyla verilmelidir. Hook mantığını yeniden gözden geçirmek isterseniz eklenti geliştirme rehberimizdeki bölüme göz atın.

Paket yayınlarken sürüm sürecini otomatikleştirin: yeni sürüm etiketlendiğinde zip dosyası üretilsin, changelog sunucuya yazılsın ve gerekirse yeni sürüm önce birkaç siteye açılsın. Hatalı bir sürümü geri çekebilmek için önceki sürümleri saklayın. Güncelleme paketlerinin bütünlüğünü bir sağlama toplamıyla doğrulamak, ortadaki adam saldırılarına karşı ek bir katman sağlar.

Güvenlik, KVKK ve ödeme entegrasyonu

• Yalnızca HTTPS kullanın; sunucu yanıtlarını imzalayın (HMAC gibi) ve istemci tarafında doğrulayın ki sahte bir lisans sunucusu eklentiyi kandıramasın.
• Oran sınırlaması (rate limiting) ile anahtar tahmin saldırılarını ve aşırı isteği engelleyin; anahtarları yeterince uzun ve rastgele üretin.
• REST API uç noktalarını yetkilendirme ve girdi doğrulamasıyla yazın. Bilgi için WordPress REST API el kitabına bakabilirsiniz.
• Minimum veri toplayın: Doğrulama için anahtar, alan adı ve eklenti sürümü çoğu zaman yeterlidir. KVKK kapsamında hangi verinin neden işlendiğini aydınlatma metninizde açıkça yazın ve veri saklama süresini belirleyin.
• Ödeme webhook'ları: iyzico, PayTR veya Stripe ödemesi tamamlandığında lisansı otomatik üretin, imza doğrulaması yapın ve aynı olayın iki kez işlenmesini engelleyin (idempotency). Fatura sürecini muhasebe düzeninize göre kurgulayın.

Eklenti tarafındaki girdi ve çıktı güvenliği de aynı derecede önemlidir; resmi eklenti güvenliği belgelerini her yayın öncesi kontrol listenize ekleyin.

Veri akışını belgeleyin: lisans sunucusuna hangi alanların gönderildiğini gizlilik politikanızda ve eklenti açıklamasında yazın; şeffaflık hem KVKK uyumu hem WordPress topluluğunun güveni için önemlidir.

Son olarak izleme: lisans sunucunuzun yanıt süresini, hata oranını ve anormal aktivasyon denemelerini izleyin; sunucunuz bir gün kapalı kalırsa binlerce müşterinin sitesi etkilenebilir. Sunucuyu yedekleyin, yedekten dönüş sürecini test edin ve lisans veritabanını şifreli saklayın. Lisans sunucusu ürününüzün en kritik altyapısıdır; özenle işletin.

Hazır çözüm mü, kendi sunucunuz mu?

Piyasada hazır lisans ve satış platformları var; bunlar hızlı başlangıç sunar ama abonelik maliyeti, esneklik sınırı ve veri sahipliği açısından değerlendirilmelidir. Kendi lisans sunucunuz ise iş modelinize (yıllık abonelik, çok siteli paketler, ajans lisansı, deneme sürümü) tam uyar ve müşteri verisi sizde kalır. Bu karar, hazır mı özel yazılım mı çerçevesindeki kriterlerle aynı mantıkla verilir: standart ihtiyaç için hazır, farklı iş modeli için özel.

Karar verirken şunları sorun: müşteri verisi nerede duracak? Aboneliği iptal ettiğimde verimi ve lisans kayıtlarımı alabilir miyim? iyzico veya PayTR gibi yerel ödeme sağlayıcılarını destekliyor mu? Faturalandırma süreçlerimle (e-Arşiv gibi) uyumlu mu? Küçük bir ürünle başlıyorsanız hazır bir çözümle başlayıp ürün büyüdükçe kendi sunucunuza geçmek de meşru bir yoldur; yeter ki lisans verilerini dışa aktarabileceğinizden emin olun.

Lisans altyapınızı birlikte kuralım

Kendi eklentimiz için kurup işlettiğimiz lisans sunucusu mimarisini sizin ürününüze uyarlayabiliriz: aktivasyon API'si, güncelleme servisi, ödeme bağlantısı ve yönetim paneli. WordPress eklenti geliştirme hizmetimizi inceleyin; lisans sisteminin canlı örneğini ise AYM Multilingual sayfasında görebilirsiniz.

Paylaş:XLinkedInWhatsApp