Kullanıcı adres eklemişse butonu aktive etmeyi butona sınıf atayarak mı yoksa sunucudan doğrulayarak mı yapmalıyım.
/*
Adres sayfasın açıldığında kullanıcının adresi varsa kayıtlı butana tıklanacak bir class ekleyebilirim.
Yoksa class atamam aynı zamanda disabled yapabilirim, ancak öge denetlenere manipule edilebilir yani tıklama dan sonra yapılsa
sayfada adres varsa butondan önce
*/
//sayfa ilk açıldığında
$adress = db den gelen veri
if(isset($adres) && !isset($_SESSION["adres"])){
$_SESSION["adres"] = true;
//Buton aktif olacak
}else{
//Buton pasif
}
Burada buton aktif bile olsa fetch ile bu session var mı diye php sayfasında doğrulatsam daha doğru olmaz mı.
Eğer kullanıcı ilkkez adres eklerse de eklenen sayfada
$_SESSION["adres"] = true; yaparım
Yani butona tıklandığında her şartta session varmı diye kontrol ederim migrosun sitesine baktım ödeme sayfasında adres yoksa tıklanınca bir istek yapışmıyor sunucuya nasıl yapmışlar bilemedim.
Belkide js sunucuda çalışıyor.
kullanıcı adres seçince devam et gübi bir butonu aktif etmekten bahsediyorsun sanırım.
diyorsun ki: kullanıcı kendisi dom'u manipule edip kendisi bir adres eklerse ve o adresi seçerse buton yine aktif olacak. o yüzden adres seçildiğinde adresin varlığını kontrol etmek için sunucuma istek atayım ve dönen sonuca göre butonu aktif edeyim.
doğru anladıysam,
böyle bir isteği atmana gerek yok. kullanıcı senin sunucuya istek atacağın fonksiyonu da manipule edebilir. veya sunucuya istek atmana fırsat vermeden butona kendisi de active class'ı verebilir veya disabled prop'unu false yapabilir. hatta kullanıcının bu işlemi yapması için web sitene girmesine bile gerek yok. sunucuna postman gibi bir program üzerinden doğrudan post isteği de atabilir. yani kötü niyetli kullanıcıyı o aşamada durduramazsın.
o yüzden sunucuya ek yük bibdirmene ve performans kaybı yaşamana gerek yok.
senin yapman gereken sayfada performansa odaklanmak olmalı. kullanıcı devam et butonuna bastıktan sonra sunucuya istek atmalısın. sunucu isteği karşıladığında önce adres seçilmiş mi diye bakar. sonra adresin varlığını kontrol eder. bu aşamalarda sorun varsa sonraki sayfayı göstermeden direkt hata sayfasına redirect edilir veya aynı sayfaya bir hata mesajıyla redirect edilir.
eğer sunucu kontrolünde bir sorun yoksa kullanıcı doğru sayfaya (sonraki aşamaya) benzersiz bir token ile redirect edilir. bu token içinde benzersizliği sağlayan bir şifre haricinde şifrelenmiş halde adres bilgisi de bulunur.
sonraki aşamada da sunucu önce token kontrolü yapar. token doğru değilse bu sayfaya kötü niyetli bir istek atılmış demektir. sunucu sayfayı göstermeden kullanıcıyı direkt hata sayfasına redirect eder. token doğruysa içindeki adres bilgisi okunur. böylece yeni sayfada adres bilgileri için yeniden veritabanına sorgu da atılmamış olur. veritabanına ne kadar az istek atılırsa o kadar iyi...
her bir devam et butonu olan sayfanda bu yöntemle ilerlersen hem front end'de performanstan ödün vermemiş olursun, hem veriyi token'larla taşıdığın için veritabanına yük bindirmemiş olursun, hem de kimse senin şifreleme anahtarını bilemeyeceği için istemediğin bir sayfaya erişemez.