PHP session - mennyire gány?
2011-04-24T17:33:34+02:00
2011-04-26T20:19:48+02:00
2022-07-19T04:26:56+02:00
  • rendben, köszönöm szépen

    Az említett részre és ugyanabba a sorba mégegyszer figyelmetlenség miatt került be a real_escape, hisz a nevéből is egyértelmű, hogy csak az adatbázis lekérdezésekre kell.
    Mutasd a teljes hozzászólást!
  • (mysql_real_escape_string($_POST['felhasznalonev'])==$sor['azonosito'])

    Ez így nem lesz jó. A mysql_real_escape_string csak az adatbáziskezelő felé küldött adatokra kell, a PHP-ban végzett műveleteknél nem szabad ezt rakni, mert ezzel épp elrontod a dolgokat. Eleve a feltétel az && előtti rész felesleges, mert azt a felhasználót kéred le, aminél az azonosito azonos a felhasznalonevvel, vagyis ennek mindig igaz eredményt kell adnia. A 35. sorban szereplő UPDATE-es query-ben viszont kell a $_POST['felhasznalonev']-re a mysql_real_escape_string, mert ez adatbáziskezelő felé menő adatnak minősül.

    Ha nincs változó befűzés, akkor valóban mindegy, de a cikkből is kiderül, hogy változó behelyettesítés esetén azért jelentős eltérés van. Még ha ez egy egész oldal generálásánál csak mondjuk 5% eltérést ad, akkor is sok kicsi sokra megy alapon érdemes az ilyen - semmi plusz munkát nem igénylő - apróságokra figyelni.

    Gondolom a PDO, Pear, stb. hasonlókra, PHP frameworkökre céloz. Amik szépek meg jók, kell is ismerni ezeket, csak jó tisztában lenni az alapokkal is.
    Mutasd a teljes hozzászólást!
  • Nem kell helyette semmit sem használni. Csak írsz egy DB connection osztályt, aztán írsz hozzá egy baseModel osztályt, stb. És utána soha többet nem találkozol ezzel a függvénnyel. Aki viszont minden egyes projektjét ezen függvény leírásával kezdi, az az igazi vérpistike. Én sem láttam ezt a függvényt már évek óta. És már nem is emlékszem mi van a PHP doksiban róla, de nem is érdekel.

    Egyébként ha komolyabb rendszert írsz, érdemes használni valami keretrendszert, annak nyilván van valami ajánlott ORM-je, akkor pedig megint nem találkozol ezzel a függvénnyel. Ilyen ORM lehet a PHP PDO osztálya, vagy a Propel, vagy a Doctrine. Én ezeken kívül még a CakePhp ORMjét ismerem, az is piszok egyszerű. Ott sem kell kézzel queryt írogatnod és egy kezdőnek tudom javasolni, mert elég egyszerű, így könnyen megismerkedhetsz egy aránylag hatékony keretrendszerrel.

    Mutasd a teljes hozzászólást!
  • A javaslatok alapján a csatolt módon javítottam a programom. Természetesen továbbra is várok hasonló javaslatokat/ötleteket, mert az ilyenekből nagyon jól lehet tanulni.
    A globalokat még nem csökkentettem (untam, de sor kerül rájuk ), és a mysql hibákat sem irányítottam még át, mert most, amíg még tanulok könnyebb úgy, hogyha egyből látom, hogy mi és hol a hiba, nem pedig utólag kell bogarásszam. "Élesítés" előtt majd mindegyiket átiranyítom egy logba.
    Az idézőjelekkel kapcsolatban ezt a cikket kaptam, ez alapján gyakorlatilag mindegy, hogy melyiket használjuk.

    Szerintem a vérpistike az, aki tudja mi a különbség a 2 függvény között. Több éve PHP + MySQL programozásból élek, de én életemben talán 3x írtam le ezeket a függvényeket, és utoljára évekkel ezelőtt...


    Akkor esetleg mit érdemes ezek helyett használni?
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Sajnos nem olyan ez a kód, ahol azt lehetne mondani, írd át a 10. és 15. sort, és az megold mindent... Az alapvető problémákat már leírták.

    Még annyi megjegyzésem lenne, hogy duplán hívott md5 nem növeli, hanem csökkenti az entrópiát.

    Mutasd a teljes hozzászólást!
  • mysql_fetch_array-t inkább mellőzzük és csak akkor használjuk, ha valóban szükség van rá. mysql_fetch_assoc is az esetek nagyon nagy százalékában (99+) azt adja, amire szükségünk van, cserébe gyorsabb, érdemes ennek használatát megszokni. mysql_fetch_array-on le lehet mérni, hogy ki a vérpistike és ki az, aki szokott is olvasni dokumentációkat, nem csak egyszer látott valamit, aztán mindent azzal akar csinálni


    Szerintem a vérpistike az, aki tudja mi a különbség a 2 függvény között. Több éve PHP + MySQL programozásból élek, de én életemben talán 3x írtam le ezeket a függvényeket, és utoljára évekkel ezelőtt...
    Mutasd a teljes hozzászólást!
  • Köszönöm a segítséged, megfogadom a tanácsaid és az említett részeken kicsit jobban belemászok a php manualba. Várom még a további javaslatokat is, ha van.
    Mutasd a teljes hozzászólást!
  • de egyelőre fölösleges.


    Nem, nem az. Piszok nagy szopásoktól tud az ilyen megmenteni, ha nem gondolod az ilyesmit feleslegesnek még akkor sem, ha épp jelen pillanatban annak tűnik.

    Egyébként amiket összeírtam két napja a másik témában, csak közben törölték a hozzászólást onnan, és csak most láttam a kérdést újra:


    - alapvetően adatbázisból csak azt az adatot kérjük le, amire szükségünk van, nem pedig mindent és utólag válogatunk belőle, gondolok itt pl. a 28. sorra és az azt követő while-ra. Tehát kell hozzá egy WHERE feltétel, amivel a felhasználónévre keresünk rá (természetesen sql injection ellen védve - mysql_real_escape_string), valamint a végére egy LIMIT 1, mivel eleve egy felhasználónév csak egyszer létezhet, ezért az első találat után nem kell tovább keresni

    - a LIMIT 1 dolog az UPDATE-es adatbázisműveleteknél is odatehető, mivel ott is csak egy sor tartozhat egy felhasználóhoz, illetve kell a WHERE ide is, hogy csak annak az adatait frissítsd, akiről szó van

    - felhasználónévre nem teszünk md5 hash-t

    - mysql_fetch_array-t inkább mellőzzük és csak akkor használjuk, ha valóban szükség van rá. mysql_fetch_assoc is az esetek nagyon nagy százalékában (99+) azt adja, amire szükségünk van, cserébe gyorsabb, érdemes ennek használatát megszokni. mysql_fetch_array-on le lehet mérni, hogy ki a vérpistike és ki az, aki szokott is olvasni dokumentációkat, nem csak egyszer látott valamit, aztán mindent azzal akar csinálni

    - ha adatbázishiba van, akkor azt inkább valami log fájlba érdemes menteni, nem a felhasználónak kitenni (mondjuk nem publikus oldalnál még elmegy, de akkor hogyan akarhatják feltörni, ha nem publikus?)

    - stringek kialakításánál az idézőjel használata felesleges, hacsak nem akarunk a stringbe változót beépíteni. Helyette az aposztróf használata javasolt, ez ugyanis kisebb szerverterhelést jelent mindenféle egyéb gondolkodás nélkül. Én ezt a változó beépítést sem használom (látom, hogy sokan szeretik, és mégtöbbnek lövése sincs a dolog hátteréről - szintén vérpistike effektus...), inkább lezárom a stringet és .-al fűzök össze mindent, mert így áttekinthetőbb számomra a kód, valamint gyorsabb is a kód futása.

    - PHP5-ben alapból a $REMOTE_ADDR már nem létezik, helyette $_SERVER['REMOTE_ADDR'] kell.

    - hibaüzenetet nem rejtünk el, hanem lekezeljük, ez azt jelenti, hogy @ jel kódban nemigazán fordulhat elő

    - global kulcsszó gyakori használata is problémás. Van amikor nem kerülhető el, de nálad ebben a kódban igen.

    Így hirtelen ezek azok, amiket első ránézésre látok. Szóval ez az oldal még nem nevezhető épp komolyabbnak, ami nem baj, mert mindenki volt kezdő, csak fogadd meg a tanácsokat.
    Mutasd a teljes hozzászólást!
  • Egyelőre nincs igény arra, hogy egynél több szerkesztő legyen, úgyhogy jelenleg ennyi is szerepel a táblában, ezért most még fölösleges lenne a WHERE. Bővítés esetén már nem nagy dolog beszúrni a where-t, de egyelőre fölösleges.
    Mutasd a teljes hozzászólást!
  • Az adatbázisból való lekérdezéshez használnám a where feltételt és nem az egész táblát kérném le. Bármennyire is nem számít a terhelés, azért az mégiscsak számít :)

    if (mysql_query("UPDATE felhasznalok SET sid='".$kod."', erv='".$ido."';"))

    Ezzel az összes felhasználó adatát frissíted, ráadásul ugyanarra. Biztos így akarod ezt?

    Mutasd a teljes hozzászólást!
  • Sziasztok

    Bocsánat, hogy megszakítom a folyó beszélgetést, de valamennyire témába vágó kérdésem volna. Eléggé kezdő vagyok PHP-ban most készül az első komolyabb oldalam, ami esetleg támadásoknak is ki lehet téve.
    Olvasgattam a témában, hogy mit hogyan érdemes csinálni, és végül a feltöltött kód született meg a munkamenet kezelése és beléptetésre. Tudom, hogy nem számít "olcsó" megoldásnak, de csak az oldal szerkesztőinek kell tudjanak belépjenek (és így is megfelel, hogy egyszerre csak egy böngészőből 30 perces idle-timeal), így a szerver terhelése nem számít.
    Azt szeretném megkérdezni, hogy ez mennyire gányolás, mennyire biztonságos és esetleg ti mit tennétek másképp. Mint írtam a biztonság a legfontosabb, nem a gyorsaság.
    Előre is köszönöm a véleményetek.
    Mutasd a teljes hozzászólást!
    Csatolt állomány
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd