Új hozzászólás Aktív témák

• #3288 Sk8erPeter nagyúr Randomized #3286

  Új Válasz 2016-03-01 23:59:54 #3288

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Randomized #3286 üzenetére

  Ha jól értettem, valójában szerveroldalon az látszik, hogy tényleg sikeres a belépés - vagy mégsem? -, csak kliensoldalon nem gömbölyű valami, de ezt nem fejtetted ki - igazából a lényeget -, hogy mi is nem működik egész pontosan. Maga az oldal újratöltése nem történik meg? Vagy újratöltés után mégsincs bejelentkezve már a felhasználó, pedig korábban úgy tűnt, hogy be van jelentkezve - tehát mégis szerveroldali a para? Vagy kliensoldalon nem látszik valami úgy, ahogy látszania kellene? Vagy mi (nem) történik?

  Ezt az alábbit még azelőtt írtam, hogy visszaolvastam volna, és láttam volna, hogy elméletileg be van jelentkezve a júzer (de lehet, hogy csak úgy tűnik, pedig igazából nem), végül is a benne írtak állnak továbbra is, de mivel itt OFF, meg valószínűleg nem is itt lesz a megoldás, ezért OFF-ba is raktam:
  A PHP-kódnál sokat segít hibafelderítés esetén, ha nem nyomod el a hibakijelzést az error_reporting 0-ra állításával (persze kizárólag fejlesztői, nem production környezetben).
  Egyébként a potenciális hibák lekezelése finoman szólva nem túl alapos, pl. csatlakozás után egyáltalán nem ellenőrzöd, hogy minden rendben ment-e az adatbázissal való kapcsolat létrehozása során. A mysqli_query visszatérési értékét is érdemes lenne leellenőrizni, mielőtt ráhívsz a visszaadott eredményre egy mysqli_num_rows-t - igaz, ennek elméletileg nullát kellene visszaadnia, ha már eleve előtte a query sem futott le helyesen.
  A mysqli_real_escape_string-es bohóckodás nagyon rossz és rég elavult gyakorlat, helyette parametrizálni kell a query-t (lásd itt), és a nyelvi eszközök pedig elintézik, hogy az átpasszolt paraméterek le legyenek kezelve (rosszindulatúság és egyéb szempontokkal kapcsolatban).
  Másik hiba: beállítod az $errors['pass']-t, és aztán később ellenőrzöd, hogy !isset($errors['userpass'])-t. (másik kulcs, pass vs. userpass... ) Egyébként sem sok értelmét látom, hogy más kulcsot használsz fel az $errors tömbödben, mint az eredetileg klienstől (a formban az adott mező name attribútuma formájában) kapott kulcsoknál.
  Egyébként mysqli-nél szerintem nagyon csúnya a procedurális formula, az objektumorientált API nem véletlenül áll rendelkezésre, de persze ízlések és pofonok.

• #3287 martonx veterán Randomized #3284

  Új Válasz 2016-03-01 21:23:35 #3287

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz Randomized #3284 üzenetére

  Nos ez esetben nincs más dolgod, mint debugolva megnézned, hogy mi történik / nem történik meg. PHP-t xdebug-al tudod debugolni, javascriptet meg a kedvenc böngésződdel.

• #3285 Sk8erPeter nagyúr Randomized #3284

  Új Válasz 2016-03-01 20:11:38 #3285

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Randomized #3284 üzenetére

  Az a baj, hogy a hibaleírásból még az sem derül ki egyértelműen, hogy melyik "szereplő" lehet a probléma okozója, mert konkrétabb kódrészletek vagy pontosabb körülírás nélkül nem lehet kitalálni. Némi kód előrébb vihet.

• #3283 martonx veterán Randomized #3282

  Új Válasz 2016-03-01 09:44:31 #3283

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz Randomized #3282 üzenetére

  Remélem érzed, hogy ezt a kérdést a PHP topikban kellene feltenned?

Új hozzászólás Aktív témák