Hirdetés
- iPhone topik
- Milyen okostelefont vegyek?
- Távozik az Apple vezérigazgatója
- Új, hardveres funkcióval várható a Pixel 11 széria
- Samsung Galaxy A56 - megbízható középszerűség
- Apple Watch
- Apple Watch Sport - ez is csak egy okosóra
- Videóspecialista telefonnal készül a Honor
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Vivo X300 Ultra - tárcsázz, ha van rá keret!
Ú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
- Lenovo X13 Gen 1 Ryzen 5 pro 4650U, 16GB RAM, SSD, jó akku, számla, garancia
- Lenovo gamer laptop bazár - friss lista (2026.04.01)
- Lenovo T14 Thinkpad G3 WUXGA IPS i5-1245U vPro 10mag 16GB 256GB SSD Intel Iris XE Win11 Pro Garancia
- Bomba ár! Asus BR1100F Convertible - Intel N6000 I 8GB I 128SSD I 11,6" Touch I Cam I W11 I Gari!
- HP EliteBook 840 G11 Ultra 7 / 16GB RAM / 512GB SSD / FHD+ IPS / Garancia 2027.11.
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
(másik kulcs, pass vs. userpass... 
