" İ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
Ben 2 adet stun oluşturup birine permalink diğerine konu başlığını yazıyordum konu başlığını alıp boşluklara - işareti getirip özel karakterleri siliyordum sonra. Htaccess den link yapısını belirliyordum son olarak permalink i veritabanında where ile sorguluyordum. Seninki yle aynı mantığa geliyor sanırsam, bir yavaşlama da olmadı bende
int. Bir ver ile varchar bir veriyi sorgulmak farklı diyorlar. 50 60 bin den sonra yavaşlama olur diyorlar ama test etmedim.
bir de url den gelen veriyi dire db gidiyor. örnek olarak sql saldırısı yapabilir. bunu nasıl engellerim tam bilmiyorum. http://siteismic.om/-or-1=1-- gibi url den yola çıkarak saldırı yapabilir mi ki.
Eyüp Başböyük Saldırı yapılabilir lakin bu saldırı. Htaccess ile veya Mod Security ile kolay bir şekilde engellenebilir.
Mert Okyanus http://znframework.com/ valitadion ile çözüyorum onu. yeni yeni bakıyorum.
aaaa yeni farketttim selamlar kolay gelsin :))
1- girdiyi doğru şekilde validasyona sokarsan güvenlik açığı oluşturmaz.
2- performans kaybı ancak çok çok mysql sınırlarını bile zorlayacak kadar veri varken ve yine çok fazla kontrol edilecek tür varken (sayfa, ürün, makale, kategori, haber ...)
olur. Sistemin nasıl yazıldığı, çalıştığı sunucunun donanımı ve bir çok etmen daha var performansı etkileyen. Bu durum kendi başına çok büyük bir kayıp yaşatmaz.
3. Önerim router classlarsan birisini kullanın.
Routeları öncelik sırasına göre oluşturun.
Bir içerik girilirken diğer kategorilerle çakışma olmasını engellemek için tüm tablolardan sefurl’leri alan bir view oluşturup ekleme sırasında hatta başlık girilirken AJAX ile anlık olarak sefurl kontrolü yapıp ürün için girilmiş bir başlığın aynısının blog için girilmesini önleyin.
wp de de öyle anlık kontrol edip varsa aynı yapısı yazdırmıyor.
Ama çok tablo olursa her tabloyu tek tek kontro etmesl lazım. urunler blog safyalar birtane slug değerğnin hangi yapıya ait olduğunu bulmak için 3 tablodan sorgu yapacak..
bu kurumsal firma sitesi olacağı için maksimum 1000 sayfayı geçmez.
Eyüp Başböyük Normal çünkü aynı başlıklar yani aynı slug oluşursa router bunu hangi mapte değerlendirip, hangisi fonksiyonu çalıştıracağını çözemez. Bunu böyle de yapamaz mısın? Yaparsın htaccess’le ama sisteme ölüm olur, zulüm olur. Ve öncelik sırası kazanır. Önceden a-urunu diye bir ürün girmişsindir şimdi aynı slugla blog yazısı girersen ve blogların htaccess kuralı ürünlerden önce yazıldıysa girdiğin o ürünü artık kimse görmeyecek çünkü önce blog kuralı eşleşip çalışacak. Router’da bunu önceliğe göre de yapamazsınız eşleştirme aşamasında exception fırlatır
Hüseyin Yarol sql de benzersiz yapsam
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.