Archívum - Júl 2005
július 9
A hoszting cégek nem kérnek a phpBB-ből
A Netcraft jelentette, hogy több hoszting cég intézkedéseket léptetett életbe, hogy felhasználói ne telepíthessék a népszerű phpBB fórum szoftvert. Ugyan a csomag fejlesztői alaptalannak tartják a lépéseket, nem tanúskodik alapos biztonsági megfontolásaikról, hogy a decemberben általunk is jelentett (a Santy féreg által programozottan is kihasznált) komoly hibájukat a 2.0.12-es verzióban ugyan kijavították, de a 2.0.15-ösben újra ott volt a rés a rendszerben.
A Big Mac és a Mezítelen Séf
A tanulságos elmélkedés a minőség és a siker témakörét járja be IT cégek esetében (példákat hozva a vendéglátásból).
■ július 9
SessionID-k adatbázisba mentés során SQL hiba mysql_affected_rows() miatt
Van egy ilyen Sessions tábla frissítő kódom (az SQL rétegben a függvények megfelelnek a mysql hasonló nevű függvényeivel, a $db class működik rendese, abban nincs hiba):
Normális esetben semmi gond nincs ezzel az eljárással, csak akkor van gond, ha egy másodpercen bellül kétszer frissítem az oldalt (pl. véletlen duplaclick), ugyanis ekkor SQL hibát jelez. Kis kutakodás után a php manualban megtaláltam a hiba okát:
Kis keresgélés után ráakadtam a mysql_info() függvényre. Azzal ugyan le tudom kérdezni azt, hogy hány sor felel meg a feltételnek és hány módosult, csak nem tartom túl jó ötletnek egy stringből kibányászni számadatot.
■ // SESSID konstans értelemszerűen a session id
$db->sql_query('UPDATE sessions SET ... last='.time().' WHERE id=\''.SESSID.'\' LIMIT 1');
if ($db->sql_affected_rows() == 0) {
$db->sql_query('INSERT INTO sessions (...) VALUES (...)');
}
$db->sql_query('UPDATE sessions SET ... last='.time().' WHERE id=\''.SESSID.'\' LIMIT 1');
if ($db->sql_affected_rows() == 0) {
$db->sql_query('INSERT INTO sessions (...) VALUES (...)');
}
Normális esetben semmi gond nincs ezzel az eljárással, csak akkor van gond, ha egy másodpercen bellül kétszer frissítem az oldalt (pl. véletlen duplaclick), ugyanis ekkor SQL hibát jelez. Kis kutakodás után a php manualban megtaláltam a hiba okát:
Ha UPDATE-tel használod, a MySQL nem fogja azokat a sorokat frissíteni, ahol a sor régi és új értéke megegyezik. Így nem kizárt, hogy a mysql_affected_rows() függvény nem pont az egyező sorok számát adja vissza, hanem csak a ténylegesen megváltoztatott sorok számát.
Kis keresgélés után ráakadtam a mysql_info() függvényre. Azzal ugyan le tudom kérdezni azt, hogy hány sor felel meg a feltételnek és hány módosult, csak nem tartom túl jó ötletnek egy stringből kibányászni számadatot.
