Osszekeveredo session adatok

Internet: PHP, CGI, stb.

http://www.hwsw.hu/hirek/44756/apple-iphone-4-okostelefon-at-t.html

Ugy nez ki nekem gyenge a fantaziam. TFH. normalisan megtervezett rendszer. Megis milyen esetben fordulhat elo olyan, hogy terheles hatasara osszekeverednek session adatok vagy csak en nem latok relaciot a ketto kozott? Magyaran hogyan kell elbaszni hozza a rendszert, hogy ez osszejohessen, mert AFAIK szinte minden ma hasznalt webes progarmozasi nyelv kore epitett infrastruktura ad valamilyen session kezeles implementaciot.

  • 774 megtekintés

( wladek1 | 2010. 06. 24., cs – 20:24 )

Hacsak nem akarták ujra feltalálni a spanyol viaszt...másképp nem nagyon lehet. (Bár egy kollégám md5 alapu sessionid -nél találkozott már két user esetén ugyanazzal a sessionid -vel. Nade csak nem?)

'lekene sslje'

azenoldalamponthu

Leggyakrabban az szokott lenni a session keveredés oka, hogy átgondolatlanul vezetnek be cache (például reverz proxy) réteget - megelőzendő a várt nagy fogalom adta terhelést, ez pedig nagyobb terhelés - vagyis átlapolódó kiszolgálások - esetén adatkeveredéshez vezet.

További ok, hogy valahol singleton van a rendszerben, amely elegendően kis ideig, de lehetőséget ad arra, hogy a kérések egymás adatait felülírhassák. Ha olyan helyen van ilyen kódrészlet, amelyben a kérések 0,1 százalék időt töltenek, akkor rossz esetben a probléma 1000 egyidejű kérés esetén jön elő, amelyet nem biztos, hogy tesztelnek.

Ezen túl van sok-sok egyéb lehetőség, amely ezt a jelenséget okozhatja, de a legtöbb webes keretrendszer eléggé jól véd az ilyesmi ellen, akkor van probléma, ha a használt keretrendszer nem tud valami fontos dolgot, és a fejlesztési idő rövidsége okán nem megoldást készítenek rá, hanem workaround-ot, amely okozhat session keveredést.

Egyébként elég gyakori, hogy nem tesztelnek üzemszerű terheléssel, hanem műterhelést adnak a rendszernek és egyszerű req/s mérőszámot jegyzőkönyveznek, aztán az élet más terhelést hoz... :)
--
http://wiki.javaforum.hu/display/FREEBSD