Hirdetés
- Épített vízhűtés (nem kompakt) topic
- A napi Windows-hiba? Teljes adatvesztés Bitlockerrel
- Letisztultságra vágysz? Itt az ASUS legújabb miditornya
- OLED TV topic
- Micro Four Thirds
- E-book olvasók
- Azonnali alaplapos kérdések órája
- Amlogic S905, S912 processzoros készülékek
- Léghűtés topik
- TCL LCD és LED TV-k
Új hozzászólás Aktív témák
-
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.
Új hozzászólás Aktív témák
- NZXT Kraken Z53 RGB(fehér)+NZXT H5 Elite ATX(fehér) garancia 2026.01.31-ig
- Apple Watch Ultra, Újszerű,Dobozával, 12 hónap garanciával
- Tamron 28-75mm F/2.8 Di III VXD G2 (Sony E)
- -ÚJ,2 ÉV GAR- DDR5 GAMER PC: RYZEN 7 8700F/9700X/9800X3D +RX 6600/6700XT +16-64GB DDR5! SZÁMLA!
- Predator GM7000 4 TB M.2 NVME PCI-E 4.0 x4 - Új - 7400-6700 MBs - Eladó!
- Samsung Galaxy S23 Ultra 5G 512GB, Kártyafüggetlen, 1 Év Garanciával
- Zalman S3 Black modern, letisztult szèpsèg
- Xiaomi Redmi Note 9 / 4/128GB / Kártyafüggetlen / 12 Hó Garancia
- AKCIÓ! DELL PowerEdge R630 rack szerver - 2xE5-2680v4 (28c/56t, 2.4/3.3GHz), 128GB RAM, 1G, áfás
- Gamer PC-Számítógép! Csere-Beszámítás! I5 12400F / RTX 3060Ti / 32GB DDR4 / 512 M.2 SSD
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
(másik kulcs, pass vs. userpass... 

