Weblabor

inf3rno év végi blogpostja kapcsán szeretném kifejteni, hogy szerintem mi a baj a PHP munkamenet-kezelésével, és min kellene változtatni.

A PHP munkamenet-kezelésének egyik fő problémája, hogy az implementáció nagyon sok helyen feltételezi, hogy a munkamenet egy globális, egypéldányos erőforrás. Ennek köszönhető például, hogy a session_encode() és session_decode() függvények csak a $_SESSION szuperglobális tömbből, illetve tömbbe tudnak dolgozni, s ennek javítása sem túl egyszerű, lásd az ide vonatkozó hibajegyet.

Ez ugye azt jelenti, hogy egy tetszőleges munkamenet ki- vagy becsomagolásához el kell menteni a $_SESSION aktuális állapotát, majd a művelet után kiolvasni és visszaállítani az eredeti állapotot.

Na de miért lehet arra szükség, hogy egyik sessionből egy másik sessiont kelljen piszkálni?

Maga az igény lehet valós, inf3rno is hozott fel egy példát, illetve magam is találkoztam olyan szituációval, ahol bele kellett kukkantani, vagy éppen írni egy másik munkamenetbe:

• A bejelentett hibák okának feltárásakor nagyon hasznos tud lenni, ha magunkra ölthetjük a hibát jelző felhasználó személyiségét, az összes munkamenet-változóval együtt.
• Egy másik esetben egy csak a sessionben tárolt információ alapján kellett statisztikát készíteni (hányan használnak egy adott funkciót).
• Megint másik esetben felmerült, hogy egy hiba kapcsán helytelen érték került be bizonyos felhasználók munkamenetébe (tegyük fel, nem létező rekordra tároltunk le neki egy referenciát), itt megtehettük volna, hogy szoftverből lekezeljük ezt az esetet, vagy megvárjuk, míg kipörögnek az érintett munkamenetek, esetleg töröljük mindet, ezáltal kiléptetünk mindenkit, de szebb megoldásnak tűnt végigjárni az összeset, és csak azokat javítani-törölni, amelyek érintettek.

Itt jön képbe a következő (két) probléma:

• A PHP alapértelmezett munkamenet-kezelője egy a serialize()-hoz nagyon hasonló, de mégis eltérő formában tárolja az adatokat (történeti okokból, ami a hibajegyben említett, elsőre nem nyilvánvaló megkötésekkel jár…), emiatt PHP-ben csak a fent említett függvényekkel lehet kibontani, hacsak nem a formátum újraimplementálásával (a függvények dokumentációjában a megjegyzésekben mások már megtették ezt).
• A session_set_save_handler() híváson keresztül definiált munkamenet-kezelőben a read() / write() hívások karakterláncokkal dolgoznak, ezért nincs egyszerű lehetőség a függvények cseréjére.

Ez azt jelenti, hogy ugyanazzal a blob adattal kell dolgozni saját kezelő megadásakor is, amit a session_encode() éppen használ (amit egyébként felül lehet definiálni, de csak C kiterjesztésen keresztül, lásd session.serialize_handler).

Az eredeti probléma megoldásaként felmerülhet még megoldásként a kérdéses munkamenetek egy kérésen belül egyidejű helyett egymás utáni betöltése, azonban ennek is megvannak a hátulütői: a PHP ugyanazzal a névvel több sütit fog kiküldeni, ami nem túl szerencsés, mivel ha minden más paraméter (tartomány, elérési út) azonos, akkor nem megjósolható, hogy adott böngésző melyiket fogja visszaküldeni a következő kérésnél.

További bajnak tartom, hogy a session, ezen belül is a session_set_save_handler() dokumentációja nem tesz említést arról a fontos tényről, hogy az alapértelmezett (és minden normális) munkamenet-kezelő indításkor kizárólagosan zárolja az állományokat, megakadályozva ezzel, hogy két párhuzamos kérés inkonzisztens, vagy éppen teljesen olvashatatlan állapotba hozza az adatokat.

Nem hatalmas gond, de személy szerint nem szeretem, hogy az alapértelmezett kezelő session fixationre sebezhető azon egyszerű okból kifolyólag, hogy a kliens tetszőleges azonosítót kérhet a szervertől (tehát indíthat olyan azonosítóval munkamenetet, ami a munkamenet-kezelő szerint nem létezik még). Többek között erre a biztonsági problémára próbál megoldási javaslatot kínálni a tavaly év végén létrehozott Strict Sessions RFC, további információkért lásd a kapcsolódó szálat a levelezőlistán.

Személy szerint nagyon remélem, hogy a következő (5.5?) verzióban sikerül egy sokkal jobb, rugalmasabb és biztonságosabb infrastruktúrát adni a felhasználók kezébe, és egyúttal megszabadulni a múlt káros örökségeinek egy részétől.