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

• #8268 Tele von Zsinór őstag fazr #8260

  Új Válasz 2012-01-29 01:13:49 #8268

  Ú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

  

  Tele von Zsinór

  őstag

  válasz fazr #8260 üzenetére

  1. erre az az általános megoldás, hogy bejelentkezéskor egy hosszú lejáratú sütit is adsz a felhasználónak valami véletlen értékkel, amit emellett egyaránt tárolsz adatbázisban. Legközelebb, ha olyan helyzet áll elő, hogy ilyet kapsz, de sessiont nem, akkor tudod ellenőrizni, van-e ilyen azonosítójú "hosszú session", és belépteted a megfelelő felhasználót.
  Az alkalmazás megkövetelt biztonsági szintjétől függ, hogy pár nap vagy pár hét lejáratú a süti, illetve hogy milyen gyakran cseréled az így tárolt random értéket.

  2. az utf8 egyike a számos úgynevezett változó szélességű karakterkódolásnak - jelen esetben ez annyit tesz, hogy egy karaktert lehet, hogy egy byte kódol, de akár szükség lehet hatra is. A php-ban vannak erre szolgáló függvények, ezek neve mb_-vel kezdődik, itt az összefoglaló dokumentáció a multibyte stringfüggvényekről. Elsőre soknak tűnhet, de kellenek.

  3. azokról valóban érdemes leszokni. A már meglevő kódjaid ne féltsd, még legalább évekik létezni és működni fognak azok a függvények is.
  A vélemények megoszlanak, de a többség (én is) arra hajlik, hogy a PDO jobb. Hasznos lehet, ha menet közben esetleg váltanod kell másra (mysql helyett pgsql, például), magánvéleményem szerint az apija is kényelmesebb, nem túl rég írtam egy rövid bevezetőt a PDO-ba, ezt az aláírásomban szereplő .eu-s linken megtalálod).

  4. ha valami hiba történik, arról értelmezhető hibaüzenetet soha ne kapjon a felhasználó. Semmit nem ér vele, általános esetben legfeljebb összezavarja, rossz esetben megtud valami olyat a rendszer belső működéséről, amit támadási felületként használhat - ezt hívják információszivárgásnak. Bármi hiba történik, amit nem tudsz lekezelni normálisan, a felhasználó kapjon egy általános http500-as hibaoldalt. Ez nálam egy sima html oldal, php-ből include-olom és die(). Nyilván naplózás után.

  5. olvass utána a prepared statement kifejezésnek. Röviden: átadsz a szervernek egy queryt, jelezve, hogy itt és itt és itt paraméterek lesznek. Ezt ő előkészíti, aztán mondod, hogy hajtsa végre azt, ezekkel a paraméterekkel. Legjobb tudomásom szerint tökéletes védelem az SQL injection ellen, felesleges körök nélkül.
  A még mysql_ függvényeket használó kódjaidban elég a mysql_real_escape_string mindenre! alkalmazva, ami a felhasználótól jön. És nyugodtan feltételezheted, hogy a függvény létezik, nem kell külön ellenőrizni.

  6. ennyi. Esetleg hetente egyszer egy olyat csinálj, hogy törlöd azokat, akik legalább n napja regisztráltak, de még azóta sem aktiváltak.

• #8265 Peter Kiss őstag fazr #8260

  Új Válasz 2012-01-29 00:40:20 #8265

  Ú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

  

  Peter Kiss

  őstag

  válasz fazr #8260 üzenetére

  1. Random (!!!) SessionID-t tárolsz el.
  2. mb_*
  3. Lehet használni a PDO-t, de, ha nincs tervezve semmilyen DB váltás, akkor jó a mysqli, csak azt is OO módon kellene használni.
  4. Semmilyen SQL hibát nem láthat a felhasználó.
  5. Prepared statement
  6. Valahogy így kellene.

• #8262 mobal nagyúr fazr #8260

  Új Válasz 2012-01-29 00:16:03 #8262

  Ú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

  

  mobal

  nagyúr

  válasz fazr #8260 üzenetére

  1. Session -nal csinálod, akkor a session tömböt használd - [link]. Én úgy szoktam, hogy csinálok egy random valamit, amit eltárolok mind a session tömbben, mind az adatbázisban és ha létezik + megegyezik, akkor tovább dobom a usert, ellenkező esetben beléptetem újra.

  2. Az utf8 -nak jónak kéne lenni, ott valami nem jó szerintem. Ha teheted utf8 -at használj, igen mindenhol.

  3. PDO

  4. Hát amíg fejlesztesz, szerintem mindent írass ki, utána pedig logolj.

  5. a mysql_real_escape_string elvileg "elég".

  6. Mondjuk kiküldesz neki egy random jelszót, amit első bejelentkezéskor kell megváltoztatni, és akkor állítod true -ra a változóját?

• #8261 CSorBA őstag fazr #8260

  Új Válasz 2012-01-29 00:13:31 #8261

  Ú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

  

  CSorBA

  őstag

  válasz fazr #8260 üzenetére

  Mobirol irok, irok igy csak egyikre gyorsan:
  2: string muveleteknel mb_ elotag, majd a string utan a kodolas, azaz utf8. Manualban nezz utana!

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