Sipariş Linki Normalizasyonu ve Teknik Doğrulama

Siparişlerin başlamamasının önemli teknik nedenlerinden biri, kullanıcıdan alınan bağlantının seçilen servisle uyumlu ve kararlı biçimde işlenmemesidir. Aynı sosyal medya içeriği mobil paylaşım linki, kısa link, takip parametreli URL veya farklı alan adı biçimlerinde gelebilir. Teknik doğrulama katmanı bağlantıyı güvenli şekilde ayrıştırmalı, normalize etmeli ve hedef türünü servisle karşılaştırmalıdır.

Bu rehber; URL güvenliği, platform ve içerik türü tespiti, yönlendirme politikası, gizlilik kontrolü ve sipariş öncesi sunucu doğrulamasını kapsar. Amaç kullanıcı linkini değiştirmek değil, hatalı veya riskli hedefleri API çağrısından önce belirlemektir.

Doğrulama katmanının görevleri

• Girdinin geçerli bir http veya https URL olduğunu kontrol etmek
• Alan adını güvenli biçimde ayrıştırmak
• Platform ve hedef türünü belirlemek
• Servisin beklediği profil, gönderi, video veya kanal türüyle eşlemek
• Takip parametrelerini kontrollü temizlemek
• Kısa veya yönlendirmeli linkleri politika çerçevesinde ele almak
• Yerel ağ ve zararlı protokol erişimini engellemek
• Normalize edilen ve orijinal bağlantıyı kayıt altına almak

URL’yi metin işlemleriyle ayrıştırmayın

Alan adını basit string bölme veya “içeriyor mu?” kontrolüyle doğrulamak güvenli değildir. Standart URL ayrıştırıcısı kullanın. Kullanıcı adı, parola, port, IPv6, Unicode alan adı ve yönlendirme gibi bileşenler yanlış yorumlanabilir.

input: https://example.com/post/123?utm_source=share
scheme: https
host: example.com
path: /post/123
query: utm_source=share

Doğrulama sonucunda protokol, hostname, path ve query ayrı alanlarda değerlendirilmelidir.

Kabul edilen protokoller

Sipariş hedefleri için yalnız https ve gerekli durumda http kabul edin. file, javascript, data, ftp veya özel uygulama protokollerini reddedin. Bağlantı metninin başındaki ve sonundaki boşlukları temizleyin fakat içeriği kontrolsüz dönüştürmeyin.

Alan adı doğrulama

Servis bir platforma özelse kabul edilen resmi alan adlarını açık listeyle yönetin. Alt alan adı kontrolünde hostname son ekini güvenli biçimde değerlendirin. Örneğin “trusted.example.evil.com” gerçek trusted.example alanı değildir.

Unicode alan adlarını normalize ederken gösterim ile gerçek hostname farkını göz önünde bulundurun. Kullanıcıya onay ekranında normalize edilmiş host ve hedef yolunu açık biçimde gösterin.

Platform ve hedef türü tespiti

Her platform için URL kalıplarını ayrı doğrulayıcı modüllerde tutun. Profil, gönderi, kısa video, kanal ve video gibi hedefleri path yapısından belirleyin. Servis kataloğunda yerel bir expected_target_type alanı oluşturarak link sonucu ile karşılaştırın.

{
  "service_id": 120,
  "platform": "instagram",
  "expected_target_type": "post",
  "allowed_hosts": ["instagram.com", "www.instagram.com"]
}

RoketBayim services yanıtı servis adı ve category gibi alanlar döndürür; hedef türü için kendi kontrollü eşleme tablonuzu yönetmeniz gerekebilir. Servis adı değişebileceği için yalnız metin aramasına güvenmeyin; yönetilebilir kural kaydı kullanın.

Normalizasyon kuralları

Güvenli dönüşümler

• Baş ve son boşlukları temizlemek
• Hostname’i standart küçük harf gösterimine çevirmek
• Varsayılan portu kaldırmak
• Bilinen takip parametrelerini politika ile temizlemek
• Gereksiz URL parçasını kaldırmak

Riskli dönüşümler

• Kullanıcı adını tahmin ederek değiştirmek
• Gönderi yolunu başka içerik türüne çevirmek
• Bilinmeyen query parametrelerini koşulsuz silmek
• Kısa linki doğrulamadan hedef kabul etmek
• HTTP içeriğini otomatik olarak farklı domaine yönlendirmek

Orijinal URL’yi denetim için saklayın; API’ye gönderilen normalize URL’yi ayrı alanda tutun.

Yönlendirme politikası

Kısa linklerin hedefini sunucudan çözmek faydalı olabilir fakat güvenlik riski taşır. Maksimum yönlendirme sayısı belirleyin, her adımda hostname ve IP güvenliğini yeniden kontrol edin, özel ağlara yönlenmeyi engelleyin ve kısa zaman aşımı kullanın.

Son hedef beklenen platformda değilse siparişi reddedin veya manuel incelemeye alın. Yönlendirme çözümleme başarısızsa kullanıcıdan doğrudan platform linki isteyin.

SSRF koruması

Link doğrulamak için uzak içeriğe istek gönderen sistem, Server-Side Request Forgery saldırılarına açık olabilir. Aşağıdaki hedefleri engelleyin:

• localhost ve loopback adresleri
• özel IPv4 ve IPv6 ağları
• link-local adresler
• bulut metadata servisleri
• kurum içi DNS adları
• izin verilmeyen portlar

DNS çözümlemesini kontrol ettikten sonra bağlantı sırasında adresin değişmediğinden emin olun. Yalnız kullanıcı tarafından görünen hostname’e güvenmeyin.

Bağlantı erişilebilirliği

URL yapısal olarak doğru olsa bile içerik özel, silinmiş, yaş kısıtlı veya ülkeye bağlı olabilir. Teknik doğrulayıcı mümkünse hafif bir erişim kontrolü yapabilir; ancak sosyal medya platformlarının bot koruması yanlış negatif sonuç üretebilir.

Erişim kontrolünü kesin gerçek olarak değil sinyal olarak kullanın. Kullanıcıdan hesabın herkese açık olduğunu onaylamasını isteyin ve sipariş boyunca görünürlüğü değiştirmemesi gerektiğini belirtin.

Link önizleme ekranı

Sipariş onayından önce kullanıcıya aşağıdaki bilgileri gösterin:

• Seçilen servis
• Tespit edilen platform
• Tespit edilen hedef türü
• Normalize edilmiş bağlantı
• Miktar
• Varsa görünürlük veya yönlendirme uyarısı

Bu ekran, kullanıcının yanlış profile veya gönderiye sipariş vermesini teknik kontrolden sonra ikinci kez önler.

Doğrulama sonucu modeli

{
  "valid": true,
  "original_url": "https://www.example.com/post/123?utm_source=x",
  "normalized_url": "https://example.com/post/123",
  "platform": "example",
  "target_type": "post",
  "warnings": [],
  "rule_version": "2026-08-13"
}

Kural sürümünü saklamak, geçmişte kabul edilen bir linkin bugün neden reddedildiğini açıklamayı kolaylaştırır.

Hata mesajı tasarımı

“Geçersiz link” tek başına yeterli değildir. Kullanıcıya düzeltilebilir neden gösterin:

• Bu servis profil bağlantısı bekliyor; gönderi bağlantısı algılandı.
• Bağlantı desteklenen platform alan adına ait değil.
• Kısa bağlantı çözülemedi; doğrudan içerik linkini girin.
• URL yalnız giriş yapıldığında açılıyor olabilir; hedefi herkese açık yapın.
• Desteklenmeyen protokol kullanıldı.

Cache ve kural güncelleme

Aynı URL’nin kısa süre içinde tekrar doğrulanması için sonuç önbelleğe alınabilir. Ancak kullanıcı içeriği silebilir veya gizleyebilir; uzun süreli cache görünürlüğü yanlış gösterebilir. Yapısal normalizasyon sonucu daha uzun, erişilebilirlik sinyali kısa süreli saklanmalıdır.

Platform URL biçimleri değişebilir. Doğrulayıcı kurallarını konfigürasyon veya sürümlü modül olarak yönetin; kod dağıtımı olmadan acil kural düzeltmesi gerekiyorsa denetimli yönetim aracı kullanın.

API gönderiminden önce son kontrol

Test matrisi

• Geçerli profil ve gönderi linkleri
• Mobil paylaşım ve takip parametreli linkler
• Kısa link ve çoklu yönlendirme
• Yanlış platform veya hedef türü
• Unicode ve benzer görünen alan adları
• localhost, özel IP ve metadata adresleri
• javascript ve data protokolleri
• Silinmiş, özel veya giriş gerektiren içerik
• Kullanıcı adı değişikliğinden sonra eski link
• Kural sürümü değiştiğinde geçmiş siparişler

Operasyon ekibi için görünürlük

Destek ekranında yalnız normalize link değil, orijinal kullanıcı girdisi ve doğrulama uyarıları da görülebilmelidir. Böylece sipariş yanlış hedefe gittiyse sorunun kullanıcı girdisi, normalizasyon veya kural eşlemesinden kaynaklanıp kaynaklanmadığı anlaşılır.

Doğrulama hatalarını platform, hedef türü ve kural koduna göre raporlayın. En sık hata profil yerine gönderi linkiyse form açıklamasını ve örnek linki geliştirin.

Platform adapter mimarisi

Tek bir büyük koşul bloğu yerine her platform için ortak arabirimi uygulayan adapter kullanın. Adapter host kontrolü, normalizasyon, hedef türü tespiti ve kullanıcıya gösterilecek örnek linkleri sağlar. Ortak güvenlik katmanı protokol, özel IP ve yönlendirme kontrolünü bütün adapter’lardan önce uygular.

validate(url)
normalize(url)
detectTargetType(url)
buildDisplayPreview(url)

Bu ayrım, bir platformun URL biçimi değiştiğinde diğerlerini etkilemeden güncelleme ve test yapmanızı sağlar.

Kural yönetimi ve onay

Yeni bir link kalıbını üretime almadan önce örnek geçerli ve geçersiz URL setiyle test edin. Yönetim panelinden kural değiştirilebiliyorsa iki kişi onayı ve sürüm geçmişi kullanın. Hatalı bir regex bütün siparişleri reddedebilir veya yanlış hedefleri kabul edebilir.

Regex güvenliği

Kullanıcı girdisini karmaşık ve kontrolsüz regex’lerle işlemek yüksek CPU kullanımına yol açabilir. Girdi uzunluğunu sınırlayın, mümkün olduğunca URL parser ve basit path segment kontrolleri kullanın. Regex gerekiyorsa kötü niyetli uzun örneklerle performans testi yapın.

Normalize link benzersizliği

Aynı hedef farklı takip parametreleriyle geldiğinde normalize URL üzerinden aktif sipariş kontrolü yapabilirsiniz. Böylece kullanıcı aynı gönderiye farklı paylaşım linkiyle ikinci sipariş açmaya çalışsa bile çakışma uyarısı verilir.

Ancak normalizasyon farklı içerikleri yanlışlıkla aynı linke dönüştürmemelidir. İçerik kimliği path veya query içinde bulunuyorsa korunmalıdır.

Gizlilik ve veri minimizasyonu

Hedef linkler müşteri kampanyası hakkında bilgi taşıyabilir. Loglarda tam URL yerine platform, target_type ve güvenli hash saklamak yeterli olabilir. Operasyon ekranında tam link yalnız yetkili kişilere gösterilmelidir.

Doğrulama servisinin arızası

Link doğrulama servisi yanıt vermediğinde tüm siparişleri sessizce geçerli kabul etmek güvenli değildir. Risk düzeyine göre siparişi kısa süre bekletin veya yalnız yapısal doğrulamadan geçen kaydı manuel incelemeye alın. Kullanıcıya teknik hata nedeniyle kontrolün geciktiğini açıkça gösterin.

Geriye dönük kural analizi

Yeni bir doğrulama hatası bulunduğunda geçmiş aktif siparişleri kural sürümüyle tarayın. Yanlış kabul edilmiş linkler varsa order ID ve durum bazında operasyon listesi çıkarın; otomatik iptal veya değişiklik yapmayın.

Kalite metrikleri

• Platform bazında doğrulama red oranı
• En sık target_type uyuşmazlığı
• Kısa link çözümleme başarı oranı
• Manuel incelemeye düşen bağlantı sayısı
• Doğrulamadan geçtiği hâlde Canceled olan link oranı
• Kural sürümü başına hata ve destek talebi sayısı

Örnek red ve uyarı seviyeleri

Her sorun siparişi kesin reddetmemelidir. Yasaklı protokol, özel IP, yanlış platform veya açık hedef türü uyuşmazlığı error olmalıdır. Takip parametresi, çözülebilen kısa link veya doğrulanamayan görünürlük warning olarak kullanıcı onayına sunulabilir.

Uyarıyla kabul edilen siparişte hangi sinyalin görüldüğünü kaydedin. Bu sipariş daha sonra Canceled olursa doğrulama kuralının kalitesi analiz edilebilir. Aynı uyarı sürekli sorun üretiyorsa error seviyesine yükseltmek için sürümlü kural değişikliği yapılır.

Destek incelemesi

Yanlış link şikâyetinde orijinal URL, normalize URL, platform, target type, kural sürümü ve kullanıcı onay zamanı birlikte gösterilmelidir. Bu kayıt olmadan hatanın form, normalizasyon veya kullanıcı değişikliğinden kaynaklandığı anlaşılamaz.

Canlıya kademeli geçiş

Yeni doğrulayıcıyı önce yalnız gözlem modunda çalıştırın. Eski sistemin kabul ettiği linkler için yeni kuralın error ve warning sonuçlarını kaydedin fakat siparişi engellemeyin. Yanlış pozitif oranı kabul edilebilir düzeye geldiğinde belirli platformlarda zorunlu hâle getirin.

Geçiş sırasında hata oranı, destek talebi ve Canceled sipariş oranını birlikte izleyin. Doğrulama reddi artarken Canceled oranı düşüyorsa kural faydalı olabilir; iki oran da artıyorsa kalıplar yeniden incelenmelidir.

Sonuçlar haftalık olarak teknik ekip tarafından gözden geçirilmelidir.