" İD OLMADAN SEO URL YAPISI "
Selamlar ;
Seo url yapısı için
seo url şu şekilde olacak.
örnek: Şarkıların güzelleriklieri
http://siteismi.com/sarkilarin-guzellikleri (blog daki bir yazı için)
örnek: Elektrikle çalışan araç (ürün adı)
http://siteismi.com/elektrikle-calisan-arac. (ürün adı)
bütün site url yapısını id olmadan ve tek yapıda nasıl yapabilirin.
slug değerini db kaydedecem.
veri çekerken id yerine slug değerini çekecem.
slug da benzersiz olacak wp de ki gibi.
Sorum şu
1. bu şekilde güvenlik açığı olur mu ?
siteismi. Co/ dan sonraki değeri alıp sorgulacam. Biraz riskli gibi.
2. performans açısında kayıplar olur mu ?
3. Sizin önerileriiz ve eleştirileriniz.
Eyüp Başböyük
E
Kısaca site isminden sonraki değeri hash fonksiyonunun içine sokup üretilen değeri mysqlden sorgularsan güvenlik açığı kalmaz. Bunu da hızlıca yapmak için mysql tarafında index kullanmalısın.
iki temel mantık orataya çıktı. birisi index ile tablolardan kontrol etmek. Diğeri ile slug, id, tabloname şeklinde seo url verilerini tek tablola tutmak. sizce hangisi daaha mantıklı ?
Ben olsam seo urlsi değilde hash-table veri yapısı kullanırım yani hash değerini tutarım. Kontrolü karakter sayısı daha kısa olacağından daha hızlı olacaktır. Id, SarkiID, Hash, CreationTime şeklinde tablo oluştururum. Seo linkinin hashini ve sarkinin oluşturulma zamanlarını tutarım. Son oluşturulan 1 haftalık veriyide aynı şekildeki başka tabloda memory üzerinde tutarım. İstek gelince seo linki hashini alıp bellekteki tablodan kontrol ederim eğer yoksa diskte tutulan tablodan 1 haftadan daha eski verilere bakmasını söylerim. Ve hepsinde ID, Hash, CreationTime alanlarına index verirdim. Hem hız sorunu büyük oranda ortadan kalkar hemde güvenli olur.
Emre Burada hash'in size kattığı bir güvenlik durumu yok. Sonuçta o hash'i oluşturmak için de istek gelen slug değerini alıp hash üretip sorguya o hash'i göndereceksiniz. Yani o slug değeri her türlü sizin kodlarınızın arasına sızacak. Öyleyse bunu bu tarz yollarıyla fazla dolandırmadan sorunun kaynağına inip her türlü yapmamız gereken "Validasyon" ile halletmeliyiz. Bu noktada benim önerim sırasıyla; Gelen slug değerinin geçersiz karakter içerip içermediğinin kontrolü ve içeriyorsa temizliği, her ihtimale karşı yeniden üretiliyormuş gibi slug fonksiyonu içine alınması, Çıkan değerin sorguya güvenli bir şekilde aktarılması yeterli olacaktır. Bu işlemler SQL sorgusuna girse de girmese de gelen bir requestteki her türlü girdi için yapılması gereken işlemlerdir. Gelen girdinin istediğimiz formata uyup uymadığının kontrolü güvenliğin kilit noktasını oluşturur. Bunu madem yapıyorsak hash'e gerek yok demektir. Hız açısından ise fark yaratacağını düşünmüyorum açıkçası, kolay gelsin.
Dostum validasyon işlemi güvenlik amacıyla yapılır ve hash ürettiğinde herhangi bir validasyon yapmana ihtiyaç yoktur ve slug değerin kodlarımızın arasına sızma gibi bir durumuda yoktur. Çünkü hash fonksiyonlarının ürettiği şey 128 bitlik integer değer olacaktır. Karakter kontrolü ve temizlik işleminin hesaplama karmaşıklığı MD-5 algoritmasından daha yüksek olacaktır, bu da binlerce istek geldiğinde daha yavaş cevap vermeye yol açar. Veritabanına sorguyu atarkende 20 baytlık seo linkimi tam metin arama işlemi yerine 8 baytlık integer karşılaştırması yapıyorsun ki buda cpu kullanımını düşürecek etkenlerden birisi.
hash degeri sonradan geri donusturulebiliyor mu. yani adam sayfa duzenlerken slug degerinide duzenlemek isteyebilir.
Eyüp Başböyük Hash değeri geri döndürelemez ancak o sayfaya ait hash değeri yeni slug değerinin hashi ile değiştirilirse seo linkide değişmiş olur