PHP unserialize() függvény kinyiffant?

Internet: PHP, CGI, stb.

Sziasztok!

Nemrég készítettem egy okostelefonokra optimalizát, webalapú szolgáltatást, ami sütikben tárolja a szolgáltatás használata során a különböző információkat. Hónapok óta a szerveren van a cucc, amit nem én üzemeltetek, hanem önkormányzati fenntartású. Pár napja megadta magát a php-s unserialize() függvény, ami a sütiben tárolt adatokat, tömbbé alakítja vissza és átadja egy tömb-változónak.

$suti_tomb = unserialize($_COOKIE["valami"]) or die("Süti olvasási hiba!!");
Az itthoni helyi-hálózati apache szerveremen hibamentesen működik az alkalmazás, az alkalmazást újra felraktam a szerverre, ott pedig a fenti hiba jelentkezik. Más is járt már így? Telefonáltam a rendszergazdáknak, ők azt mondják, hogy már egy ideje nem frissítették sem a webszervert, sem a PHP-t. Mire tippeltek, mi lehet a gond? Nekem már ötletem sincs, a cookie nyers tartalmát ki tudtam íratni, úgyhogy a cookie létrejött és a tartalma is olvasható, viszont muszáj lenne visszaalakítanom tömbbé, mert a benne tárolt adatokkal műveleteket kell végeznie az alkalmazásomnak. A számlázás már pár hete megtörtént, addig hiba mentesen működött az alkalmazás, a hiba jelentkezéséig nem hajtottam végre semmilyen módosítást.

Köszi.
MysteryKe.

  • 8271 megtekintés

( dragi v | 2013. 12. 15., v – 21:12 )

Mi a pontos hibauzenet? Tehat php error log mit mond?
Miert nem sessionbe tarolod?

nincsen hibaüzenet, pedig bekapcsoltam a display_error-t az ini_set függvénnyel. az error log-hoz nem férek hozzá, nem az én szerverem, hanem az önkormányzat informatikai részlegéjé. Elmondásuk szerint semmilyen biztonsági szabályt nem módosítottak, nem változtattak semmit sem a php beállításokban és nem frissítettek semmit az elmúlt pár hétben. Ők sem értik mi lehet a gond.
Sajnos a felhasználás módjából eredően nem használhatok session változókat. Nem mondhatom el, hogy miért, mert még nem lett nyilvánosságra hozva az alkalmazás, majd csak kb. fél év múlva lesz éppen ezért nem mondhatok róla többet :) Csak hogy pár nappal ezelőttig működött az unserialize, aztán nem :)

( dataup | 2013. 12. 15., v – 21:14 )

phpinfo(); össze hasonlítása a két szerver között meg volt ?

( agoston | 2013. 12. 15., v – 21:45 )

Amit unserializ-álsz, annak van értéke? Nem emlékszem pontosan,de néha valamit hack-elni kell az unserialize környékén...

( uid_7086 | 2013. 12. 15., v – 22:34 )

Nekem egy dolog (biztosan) nem tiszta a történetben: minden próbálkozásnál hibázik vagy csak egyes klienseknél?

Akkor ez nem nyert. Arra gondoltam, hogy esetleg valami kliens oldali váltás okozza. (pl. a teszteléshez használt mobilokon felhúzták az androidot 4.3-ra a korábbi verzióról)

Viszont.. ugyan offtopic, de itt az első, a kérdéshez fűzött komment megerősítette, amit csak gyanítottam: óriási sec.hole ha a cookie-ból visszakapott adatot adod oda az unserialize fv.-nek!

ui: ugye azt a hibát nem követed el, hogy a cookie kiírását követően, még abban a menetben vissza is akarod olvasni?

Melyik része nem tiszta?
Cookie-ban max. a session azonosítójára utaló kódot tárolnék, minden mást adatbázisban. (azért a dologhoz hozzátartozik, hogy tavaly foglalkoztam pár hónapig PHP-vel, se előtte, se azóta, szóval nem árt fenntartással kezelni az ilyen megjegyzéseimet)

Egyébként érdemes végigolvasni a php.net/unserialize oldalon a leírást, a WARNING címkével ellátott részeket és a kommenteket is.

Sajnos ebben az esetben nem járható út az adatbázis (sokat gondolkoztam rajta, hogy azzal csináljam-e).

Folyamatosan olvasom az unserialize()-re vonatkozó leírásokat. A függvény egy stringet vár, amit meg is kap, hisz ki tudom nyerni a cookie-ból a tartalmat. Ezért nem értem, hogy miért nem működik a függvény. A fejlesztés ideje alatt, folyamatosan a jelenlegi szervert használtam és a tesztelési időszakban is, amikor számtalan telefonnal és böngészővel próbáltuk ki az alkalmazást, és még utána is kértek módosításokat a megrendelők, utána megint tesztidőszak....... szóval jópár hónapig ment a dolog a jelenlig szerverrel, úgy, hogy a cookie-kezelő részeken azótan nem módosítottam egy karaktert sem és a számlázáskor is működött minden. Egészen a múlt hétig.

szerk.: A cookie nyers tartalmát lazán ki tudom íratani egy változóba: "a:25:{s:4:\"adat1\";s:6:\"valami\".........." stb. Az unserialize()-nek szerintem ezt minden probléma nélkül kellene értelmeznie. Szóval cookie hozzáférési gond nincsen...

Nem beszélgetésre gondoltam. :)
Egyedül nem turkálhatsz éles adatok között, de felügyelet mellett talán megoldható, hogy az éles renszerhez odaengedjenek és közösen keressétek meg a hiba okát.
Ez az egész annyira zűrös, hogy akár php bug is lehet, de akár egy utólag berakott biztonsági eszköz(tűzfalféleség) is belerondíthat. Az utolsó mondat 100%-ig a fantázia terméke, csak már ilyesmi is eszembe jut, ahogy olvasom a történetet.

( eax | 2013. 12. 16., h – 01:33 )

"unserialize($_COOKIE["valami"])"

Engedje meg, hogy asztakurva. Ezt nagyon gyorsan takaritsd le az internetrol, mielott valaki mas teszi meg.

Warning

FALSE is returned both in the case of an error and if unserializing the serialized FALSE value. It is possible to catch this special case by comparing str with serialize(false) or by catching the issued E_NOTICE.

Warning

Do not pass untrusted user input to unserialize(). Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user.

Kulcs a lábtörlő alatt :)

Pár évvel ezelőtt az előző munkahelyemen egy elég nagy franchise cég frissen elkészült, átadás előtt álló ügyviteli rendszerét vizsgálta a biztonsági auditor.

Bejelentkezett egy korlátozott felhasználóval majd az URL-ben átírta a felhasználó azonosítót az egyesre, így adminisztrátori jogot kapott. A kétperces művelet után felállt a gép elől és nem folytatta tovább az auditot :D

--
maszili

( saxus | 2013. 12. 16., h – 01:33 )

Mit serializálsz? Ha osztály, akkor lesz benne egy \0 karakter, amit nem hiszem, hogy túl sok midnen díjazna.

(Az igazán vicc az, hogy ez be is lett jelentve a PHP-soknak, hogy talán nem biztos, hogy a legjobb karaktert választották, erre az volt a válasz, kb. hogy mi a faszt zavar, senki nem mondta, hogy text only lesz a serializálása a PHP-nek. Kár, hogy ezen kívül minden text-be megy PHP-ben, amit serializál és semmi nem indokolja, hogy ez se oda menjen. Cserébe így meg bizonyos esetekben jól meg tudja szivatni az embert.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha a 19 elembol csak 1 van olyan, ami user input, akkor megis mi a retkes feneert kell halozaton utaztatni es odaadni lehetosegnek, hogy az user buzeralja? Miert nem sessionban van es csak az utazik cookieban, ami valoban client side? Bar az is erdekelne, hogy mi az az egy adat, mert valahogy nekem altalaban egy session id-n kivul mas nem kell cookieba.

Arrol nem is beszelve, hogy a cookiek darabra es meretre is limitalt joszagok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Arrol nem is beszelve, hogy a cookiek darabra es meretre is limitalt joszagok."
Meg kodolasra es karakterre, illetve bongeszo fuggoen valamelyik nem szeret meg ezt azt.
A kerdezonek:
Eloallitashoz: base64_encode(serialize($idiota_sessionben_utazo_adatom));
Visszaallitashoz: $idiota_sessionben_utazo_adatom = unserialize(base64_decode($_COOKIE['idiota_cookie_amiben_serializalt_adat_utazik']));

// Happy debugging, suckers
#define true (rand() > 10)

Az elbaszottabb böngészőkben is 64k a limit / cookie, manapság már 4mb. Ha van olyan hülye, hogy cookieban tárol adatokat, akkor utaztassa csak. A base64 meg már csak azért is segíteni fog, mert a cookiek tartalma eléggé restricted, nem véletlen, mivel headerben utazik, így legalább lefedte az összes elcseszett karaktert ami előfordulhat. De ha van jobb ötleted a base64 -en kívül arra hogyan tömörítsen úgy, hogy a szabályoknak is megfelel, örömmel várom.

// Happy debugging, suckers
#define true (rand() > 10)

Azért a cookie használata elkerülhetetlen akár csak session tárolásra, de egy 32 byte hosszú session id-t utaztatni még mindig sokkal egyszerűbb. Persze vannak itt is kerülő utak, pl websocketet használni és akkor a session már adott, viszont a visszatérő látogatók trackelése ott nem megoldott. A cookie jó dolog, csak nem szabad eszeveszett hülyeségbe belemenni mint ahogy a topic nyitója tette, neki marad a base64 és a bazi nagy header

// Happy debugging, suckers
#define true (rand() > 10)

Mivel én 4K-ra emlékeztem, kipróbáltam, de valami nem kerek: ha 4K fölé megy a cookie mérete (HTML4, tehát cookie és nem local storage!), akkor az nginx elhasal azzal, hogy túl nagy a header.
Mivel az nginx-t nem igazán ismerem, csak épp ez volt kéznél, nem tudom, mit gondoljak: szervert kellene átkonfigurálni?

Valami továbbra is a 4K limitet támasztja alá: az nginx már túléli, de a kiírt 16K-s cookie-ból csak 3200 bájtot kapok vissza.
(csupa abcdefgh karakterekből álló string a tartalma egyébként)

FF26 win7.

Hm. Közben ellenőriztem: ki sem küldte a túl nagy cookie-t. Miután töröltem, már nem volt mit visszaolvasnia.

Azt hiszem értem a problémát, kicsit elbeszéltem magam mellett is (nagyon csöndben jegyzem meg hogy igazából hülyén írtam le a gondolatom). A 4k/cookie felhasználás valós, én kifejtve /header -re gondoltam cookie alatt (mert egy domain ala rakhatunk tobb cookie-t is, a cookie-t mint cookie-kat osszegzo cookie aradatot ertettem:D). Az nginx limit ugyanugy problema lett volna ott is

// Happy debugging, suckers
#define true (rand() > 10)

( denton | 2013. 12. 16., h – 13:15 )

Kérlek lapozz el a tutorialokban a SESSIONS részig!
Vagy hozz létre adatbázisban generált id -jű(akár AUTOINC is lehet, nem azt nem kell generálni) vagy generált nevű fájlokat egy mappában és a fájl nevét mentsed le cookie-ba, és később az alapján hivatkozz majd.

De a session-ok jobbak lesznek.

Amúgy hosszabb serializált tömböket base64-el encodolunk, db mentésnél is, mert kiborulhat tőle a rendszer.

Amúgy évekkel ezelőtt ilyen fv-vel toltuk az unserializálást: 


function __unserialize($sObject) {
    
    $__ret =preg_replace('!s:(\d+):"(.*?)";!e', "'s:'.strlen('$2').':\"$2\";'", $sObject );
    
    return unserialize($__ret);
    
}

A php default file alapú session kezelése egy förmedvény, annál valóban jobb db-ben tárolni (de azt sem kell meginnoválni teljesen, megvannak a handlerjei save/load -ra). Minden esetre a cookie-ban tárolt serializált php array-nál csak jobbat tudok, rosszabbat nem

// Happy debugging, suckers
#define true (rand() > 10)

Milyen egész táblát? Én sor szintű lockról írtam. Olvasd már el!
A kérdésem arra vonatkozik, h az általad nyeglén leszólt és "förmedvény"-nek minősitett fájl alapú session kezelés által megvalósított funkcionalitást, amely kizárólagos lockolást valósít meg egy session fájlra a konkurens szálak között, az általad jobb alternatívának feltüntett db-alpú session kezelés, melyekhez -szintén általad említve- már megírt handlerek használhatók, képes-e reprodukálni? Ha igen, akkor vannak-e ennek korlátai és mik azok? Erre vártam volna választ.

Te kérdezted, hogy sor alapú-e a lockolás, én visszakérdeztem hogy miért kéne az egész táblát lockolni? A file alapú session kezelés minden szempontból a lehető legrosszabb (bazi nagy io overhead, nem shardolhato, más szóval: igénytelen), ennek ellenére a legtöbb esetben elég.
"képes-e reprodukálni?": Miért ne lenne képes reprodukálni? Ha olyan db engine-t választasz, vagy elbaszott schema-t, akkor nem, de ez nem a megoldás problémája.
"vannak-e ennek korlátai" -> a file alapú session kezeléssel szemben semmilyen korláttal nem rendelkezik, annál mindenképpen jobb.
Ideális esetben ha a mögöttes DB-t nem egy SQL alapú szerverre bízod, hanem egy key value store-ra, akkor hihetetlen nagy sebességnövekedést is el lehet érni ha masszívan támaszkodik az app a session kezelésre

// Happy debugging, suckers
#define true (rand() > 10)

Konkurencia-kezelést kell megvalósítani többszálú környezetben - ez nem éppen triviális feladat PHP-hoz szokott fejlesztőknek. Ha a rendelkezésre álló db támogatja a sor szintű lockolást akkor könnyebb valamivel, de pusztán ezért innodb-zni,meg tranzakciózni ágyúval verébre esete. Key-value store ugyan lehet gyors, de ha a lockolást nem támogatja ugyan ott vagyunk.
Sajnos a jelenségre - mán a konkurencia-kezelés jelentőségére a session esetében - kevésbé irányul figyelem. A különböző helyeken fellelhető "handlerek" sem implementálják a szükséges funkcionalitást. Nem nagyon javasolnám a beépített session-kezelőtől való eltérést, csak akkor ha nincs más megoldás egy adott feladathoz - illetve olyan fejlesztőnek akinek nem az én javaslatomra van szüksége, mert maga is tudja, h mit csinál.
Amúgy kérésenként egy olvasás és [esetleg] egy írás az a borzasztó IO overhead amit emlegetsz.

Kedvesem, a sejtésedből arra következtetek, hogy módosítani kívánod a "php default file alapú session kezelése egy förmedvény, annál valóban jobb db-ben tárolni " nyegleségedet valamely napi látogatottsági limittel - ettől remélve, hogy kevésbé tűnsz annak ami vagy.

$ cat /var/www/data/forum_comment_1676850.txt

Nem, ezt rád írtam, hogy annak, aki csak csak napi 150 látogatóval rendelkező gagyiportál tömeget farigcsál, tökéletesen megfelel a php default file alapokon nyugvó session kezelése, annak minden hibájával együtt, nem megértve azt, hogy miért nem szerencsés sok kicsi file-t egy könyvtárban tárolni ész nélkül. Igazából a hozzáállásodból kiindulva nem is értem miért használ bárki adatbázis rendszereket, mindent rakjunk ki külön file-ba, bizonyára bazi gyors lesz.

Remélem azért azt felfogod, hogy nem azért került ez a megoldás a php-ba, mert ez olyan kurva jó, hanem azért mert ennek semmilyen dependanciája nincs egy tmp könyvtáron kívül (windowson megoldották már a clean up-ot?:P)

// Happy debugging, suckers
#define true (rand() > 10)

Nem gondolnám, h kizárólag a látogatók száma alapján kéne megitélni egy-egy fejlesztés minőségét, inkább szempont a megvalósított funkcionalitás és a felhasznált technológia. Nem mondtam, h ne lenne legitim megoldás a session db-ben való tárolása, pusztán azt állítom, hogy ez korántsem abból áll, hogy már megírt "handlereket" alkalmazunk - különös tekintettel arra, hogy még php.net -en fellelhető példák sem foglalkoznak a konkurencia-kezelés kérdésével - hanem nagyon is meg kell azt "innoválni". Több gépből álló, elosztott rendszer is megvalósítható fájl alapú session kezeléssel, nem a db-be helyezés az egyetlen lehetőség.

Akkor nézzük csak:
"Nem gondolnám, h kizárólag a látogatók száma alapján kéne megitélni egy-egy fejlesztés minőségét"
Én gondolnám, mert bizonyos szar megoldások egy kis látogató számmal rendelkező oldalon bőven elférnek, nem fognak gondot okozni, mint ahogy ez sem.
"hogy már megírt "handlereket" alkalmazunk":
Értettem ez alatt a !Handlereket!, amik valóban handlerek, de úgy tűnik ezt a részét nem érted: hint: session_set_save_handler
"fellelhető példák sem foglalkoznak a konkurencia-kezelés kérdésével"
Igen, mert a PHP aztán zseniálisan megoldja ezt a kérdést:
Jön egy session id, van file hozzá, lockoljuk az egészet addig míg a script le nem fut, aztán unlockoljuk. Ez aztán zseniális megoldás, így nem kell félni semmitől mert agyonverünk mindenkit addig míg futunk.
"Több gépből álló, elosztott rendszer is megvalósítható fájl alapú session kezeléssel"
Persze, rakjuk ki valami network FS-re, ez aztán zseniális megoldás. És igen, megvalósítható minden, csak hogy a gányolás gányolás marad, akár elosztottan kezeled, akár nem.

Csak hogy értsd a lényeget, megismétlem magam megint: A PHP-ba a file alapú session kezelés egy nagyon buta, alap megoldás azért, hogy dependencia nélkül is tudja ezt a szolgáltatást nyújtani. Nem azért került bele, mert az annyira jó, hanem mert nem kell hozzá semmi. És akkor nézzük hogy miért is szar:
- A lock csak lehetőség, olyan FS-en ami nem támogatja, nem lesz lockolás és erről még csak tudni sem fogsz, kivéve mikor csonka/invalid session-ök halmozódnak
- A lock annyival le van tudva, hogy míg a script dolgozik, le van lockolva az egész session, így többszálú kezelésről szó sincs (session_start(); sleep(60);, aztán nyiss egy új lapot, nem jön be az oldal? nem hát). Ezt nem nevezném konkurencia kezelésnek, viszont ez továbbra is belefér, lévén ez egy nagyon alap megoldás csak azért, hogy legyen, dependencia nélkül.
- Egy clean up-nak nem úgy kéne kinéznie, hogy minden egyes session_start -nál végignézzük az összes session file-t, megnézzük a last modify time-ját, aztán ha túl nagy a különbség, töröljük.
- Alapvetően brutális overhead az, hogy benyalunk minden adatot a file-ból akkor is, ha nincs is rá szükségünk, ráadásként egy futás végén a teljes egészét visszaírjuk abban az esetben is, ha semmi nem változott benne.

Lenne még egy halom technikai jellegü érvem (pl a sok kicsi file struktúrálatlan kezelése etc.), de úgy érzem felesleges téged meggyőzni, mivel csak valahol látott szavakat "többszálú/konkurencia kezelés" büfögsz vissza fogalmak nélkül, mert az alap session kezelésre egyik sem igaz, így oka fogyott az hogy mély szakmai szemmel nézzem.

// Happy debugging, suckers
#define true (rand() > 10)

"Persze, rakjuk ki valami network FS-re, ez aztán zseniális megoldás. És igen, megvalósítható minden, csak hogy a gányolás gányolás marad, akár elosztottan kezeled, akár nem."
Használhatsz sticky session -t is, és akkor mindig ugyan arra gépre jut a user, ezzel a probléma meg is van kerülve.

"A lock csak lehetőség, olyan FS-en ami nem támogatja,"
Miért is rakná valaki a session-öket olyan FS-re ami nem támogatja a lockot?

"míg a script dolgozik, le van lockolva az egész session...Ezt nem nevezném konkurencia kezelésnek"
Ezt hívják pesszimista konkurencia-kezelésnek.

"Egy clean up-nak nem úgy kéne kinéznie, hogy minden egyes session_start -nál végignézzük az összes session file-t"
Lehet h _szerinted_ így működik, de valójában az a helyzet h konfigurálható egy valószínűségi érték, hogy lefusson-e a szemétgyűjtő - alapbeállításként a kérések 1%- ban fut le. De természetesen ez kikapcsolható és akkor cron-ból futtatva takaríthatsz saját elképzelés szerint. Ennek működésében egyébként nincs különbség beépített kezelő és a PHP hookjaira épülő saját kezelő működése között.

Tekintettel arra a sajátos szövegkörnyezetre amiben érvényesülni próbálsz, a magam részéről befejezettnek tekintem a társalgást.

Látom sikeresen kiszemezgetted azokat a kérdéseket, amire tudtál választ adni (mégha a "pesszimista" konkurencia kezelés nem válasz, hanem a szarozásom alátámasztása),de így látván a szar nálad mértékegységként definiált, így csak reménykedem hogy nem akadok össze általad kreált kóddal

// Happy debugging, suckers
#define true (rand() > 10)

( BehringerZoltan | 2013. 12. 16., h – 16:23 )

Az alapvető probléma az, h nem tartod be az inkább írott, mint íratlan konvenciókat (pl. nem bízunk a kapott adatokban; adott feladatra a megfelelő nyelvi elemeket, formulákat használjuk stb.) és így "fejlesztesz". Persze szerinted rossz a szerver, meg "kinyiffant PHP unserialize függvénye" -jelentsen ez a sületlenség bármit is -, csak épp Te nem vagy felelős, mert Nálad működik valami - állítólag.
És valóban, mennyire jellemző: a legfontosabb info: A SZÁMLÁZÁS MÁR MEGTÖRTÉNT! - szerintem ez lehetett a fő baj :-D

Ne mondd, hogy te egyből seniornak születtél. Mindenkinek van/volt olyan kódja, amire "nem annyira büszke", amin megtanulta az ipart. Ha kijavította, pláne jó. Itt most előjött egy csomó baromság (remélem nem fertőző :P ), és ha a kérdező kijavítja a kódját, akkor már megérte.
Neki is mert tanult belőle, meg az ügyfélnek is, mert nem egy sechole kupacot kap jó esetben.

Egyébként igen, itt jön elő az elméleti képzettség előnye, egy csomó hibát eszedbe nem jut elkövetni, még teljesen juniorként sem, mert az iskolában megtanultad.

--
Gábriel Ákos
http://i-logic.hu

( uid_17626 | 2013. 12. 18., sze – 00:37 )

Mások ilyenkor szoktak egy PHP-t fikázó blog írásába kezdeni.
Javaslom ezt neked is, mert bár a problémádon nem segít, de a frusztráltságodon javíthat. :)

szvsz a php nem idióta, csak az emberek elvására túl nagy akik nem ismerik a szigorúan típusos nyelveket és nekik nehéz elmagyarázni hogy mi is lehet a baj egy adótt kóddal ami típusosság ismerete nélkül jónak tűnik. persze a naming convention ami php-ban nincs az jogos "hiba", de szokható, attól a működés nem lesz más. személy szerint szeretem a php-t a hülyeségeivel együtt mert lehet vele gyorsan PoC kódokat csinálni jópár dologra, meg amúgyis kreatívkodni, bár lehetne nehezen tanulhatóbb hogy a skiddiek eltakarodjanak messzire és jobb legyen a hírneve az egésznek

na igen de ha nem tudod hogy az interpreter adott adatot adott pillanatban miért adott típussal fog a memóriában tárolni akkor most megnem találom a neten a konkrét példát, de könnyen belefutsz hogy túl nagy szám esetén a szám hirtelen string lesz és nem érted miért nem működik a $a++ meg hasonlók rajta

Igen, a php alapvetően elvi hibás fos.
Van hozzá egy csomó jó keretrendszer ami ezen elvi hibák egy részét szerencsésen elfedi, ezért is érdemes ezeket használni.

Ettől függetlenül sajnos elég könnyű benne szemetet gyártani.
Sokkal több mindenre kell gondolnia egy php programozónak ha igazán jó kódot akar írni mint mondjuk egy Java-snak.
Egy penge PHP-s nagy kincs, nincs is sok belőle. Tipikus jellemzője hogy ért a teszteléshez.
Olyan, aki relatíve gyorsan össze tud tákolni valami szart, van bőven.

--
Gábriel Ákos
http://i-logic.hu

Tanulj már meg kerek egész mondatokat fogalmazni, mert nem lehet érteni, hogy mit mondasz.

($a++ meg pont rossz példa, mert stringre is simán fogja alkalmazni, csak előbb számként megpróbálja értelmezni. Más kérdés, hogy ha "túl nagy lesz a szám", akkor lebegőpontosat csinál belőle).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

bocsi, épp hogy hazaestem egy egész estés kocsmatúráról... : ) amúgy szerintem elég jó példa, mert használhatatlan lesz a ++ nagy számokkal:

$a = 9223372036854775807
++$a = 9.2233720368548E+18

gondolom látható, hogy a ++ eredménye sokkal inkább lett +24193 mint +1, azaz ha valakinek ténylegesen ilyen nagy számokkal kéne dolgoznia akkor elég nagy fejtörést fog okozni. könnyen lehet, hogy 99%-aban az eseteknek nem lépi át a 32/64 bit korlátait a művelet és ezért nem is gondolta az illető, hogy biginteger kéne inkább, de egy ilyet kidebuggolni... hát lehet elsőre nem ez jutna eszembe, mégha átfordulna a szám akkor csak-csak, de így semmiképp

szerk.: bár tény hogy nem string lett a vége... nem is teljesen tudom miért stringet írtam de betudom az elsősorban olvashatóknak

Mert az mennyivel jobb, hogy kapsz egy overflowt és 0-n/INT_MIN-en állsz? (erre még talán a legkultúráltabb megoldás a C#-os checked context). Ha a bármilyen programozónak elsőre nem jutna eszébe a range check (akkor ad egy, megfogja a unit test, ugyebár ;) és ad kettő,) ugyanekkorát szívna.

BlackY

Erre vonatkozott a C#-os megjegyzés (nyelvi szinten lehetőség van arra, hogy pl. egy overflow-ra azonnal Exception-t dobjon). Pl. egy C-ben nem fog elhasalni a prog., ugyanúgy kapsz egy hibás eredményt, úgyhogy gyakorlatilag ugyanott vagy, mint a PHP-vel, csak más hibás eredményt kapsz :)

BlackY

( GFS | 2013. 12. 18., sze – 21:13 )

nagyon szep!! es fizettek is. oriasi :P tudjak mit vettek?

( errotan v | 2013. 12. 18., sze – 21:28 )

A "szérializált" (húúú de szép szó :D) tömböt próbáltad base64-el bekódolni és úgy tárolni sütibe?

Csak a topic nyitója tűnt el nyomtalanul.
Így pl. talán sohasem fogjuk megtudni, hogy nem-e méretprobléma okozta a gondot.
Pedig engem érdekelne, hogy ha megoldódott, akkor hogyan, ha nem, akkor miért ragaszkodik ennyire ahhoz, hogy minden létező észérv ellenére szerializált objektumot pakoljon cookie-ba...

( MysteryKe | 2013. 12. 18., sze – 23:13 )

Visszatértem, csak muszáj volt kialudnom magamat a 2x15 órás munkanapok után és nem volt időm foglalkozni a projektettel, ugyanis ezt én az alvóidőmben csinálom, plusz most a melóhelyem (ahol nem programozással foglalkozom), most az év végére való készülődés miatt nagy a hajtás.
A tárolási formátumot JSON-ra állítottam és stripslash-el ötvözve már nem okozott gondot. (Bár még mindig rejtély, hogy nélküle hogyan ment eddig, ha most nem...... a szerver gazdái előtt is rejtély) 

 $suti_tomb = (Array) json_decode(stripslashes($_COOKIE[$cookie_name])) or die("<b>Süti olvasási hiba!!!!!</b><br>");

Az alkalmazás pedig nem a NASA-nak készül és nem vállalati használatra, hanem gyerekeknek első sorban, akik játszhatnak vele anya vagy apa telefonján webböngészőn keresztül, napi max. 50-100 felhasználóval számolva. Semmilyen titkos adatot nem tárol. A sütiben tárolt tömbelemek pedig 1 kivételével egyetlen egy karakter tárolnak (azaz csak állapotot), a maradék 1, amit a user visz be, az is szöveges, max. 20 karakterrel számolva, szóval a süti méretet nem haladja meg a 4K-t sem, az adatbázis meg felelslegesen megbonyolítaná az alkalmazás működését és amúgy sem tárol semmilyen felhasználó adatot (feltétele volt a megbízásnak!). Nincsen regisztráció és semmiféle autentikáció.

A "biznisz" pedig úgy működik, hogy hugyér-szarér csinálom meg, mert minden mellékes jól jön és összvisz 2 hónapom volt a tervezéstől egészen az első alfa bemutatójáig, úgy, hogy alig volt időm aludni. Az üzletet nem én bonyolítom én csak kapom a megbízást, a koncepciót pedig úgy, hogy a működés pontosan le van írva, mint egy forgatókönyv és a projektben dolgozó ember forrásanyagait. Az összeg, amiért csináltam, azért szerintem itt a legtöbben ki se kelnének az ágyból. A munkahelyemnek szoktam készíteni belső használatra szánt programokat, ott bizony adatbázist használok (mivel nekem mániám az adatbázis, ezért első sorban így közelítettem meg az egészet, de csak feleslegesen megbonyolította volna, ami holt egyszerű) és rendesen védett inputokat. (azért is kapok kicsit nagyobb bónuszt év végén, szóval itt sem kell arra gondolni, hogy az érte kapott pénz megüti az elfogadottnak tartott összeget). Sütivel most először volt dolgom, mivel eddig sosem volt rá szükségem. Többet nem mondhatok arról, hogy miért cookie-t kell használni, mert azzal már sokat mondanék.

Mindig szívesen fogadom a kritikákat és nem szoktam megsértődni, mert minden munkámmal egyuttal tanulok is és tudom hasznosítani a következőben. Sajnos nem úgy jöttem ki anyukámból, hogy mindent tudok, így kénytelen vagyok folyamatosan tanulni. Nyugi, nagyvállalatnak és kényes dolgok megoldására szánt alkalmazásokat nem vállalok :)

Állami? Nem ilyet nem írtam, de ha mégis, akkor az csakis a másik énem lehetett, aki akkor jöhetett elő, amikor már nem láttam kettőig a fáradtságtól (nyugi, nem vagyok skizofrén :)) )
Nem állami, hanem közvetett módon önkormányzati megbízás, kisgyerekeknek szánt alkalmazásra.

Végül is :) Csak a felhasználás jellege miatt nem mondhatok róla többet, mert ilyen még tudomásunk szerint nincsen Mo.-n. :) Publikus kb. fél év múlva lesz, addig pedig szupertitkos :)

szerk.: ja és köszönöm szépen mindenkinek az építő jellegű hozzászólásokat, nagyon hasznosak voltak :)