2010/9/9 Tomas Beranek <[email protected]>: > diky za tipy a rady, > ale instancni promenna to taky nebude, vim jak se chova Action v Struts. > zadne takove promenne nepouzivam. > > je tam proste jen execute(...) metoda. > > zacinam cim dal vice podezrivat ten firewall :-)
Asi takto: něco někde není RequestSafe. Chyba se projevuje tak, že dva requesty s různým sessionID obsahují stejná data. Předpokládejme tedy na chvíli, že to má opravdu na svědomí firewall. Dovolím si předpokládat, že onen firewall není session-based-loadbalancer. Co by to tedy znamenalo? a) změní se sessionID Session (ať už je to HttpSession jiný druh mapy používající sessionID) přiřazuje k požadavku příjemce, tedy servletový kontejner či jiná aplikace v servletovém kontejneru běžící. sessionID je přiřazeno vždy na základě příchozích paketů. Tyto pakety obsahují aplikační data (v daném případě data HTTP) a síťové hlavičky. Kdyby se sessionID přiazovalo pouze na základě síťových hlaviček, tak by buď všechny požadavky jdoucí ze stejné zaNATované sítě získávaly stejné sessionID (při identifikaci podle MAC adresy, IP adresy či jiného určení konkrétního počítače) a nebo by nebylo zaručeno, že stejný uživatel bude mít stále stejné sessionID (při identifikaci podle portu). Když si tedy řekneme, že nám čisté síťování nestačí, musí se použít něco, co je v datech. Aby došlo na straně přiřazení k záměně session ID, které je vyhodnocováno i na základě dat, musel by ten, kdo sessionID zamění, vědět, kde se PŘESNĚ (protože se nenahradila jen tak nějaká data, al pouze ta pro sessionID) nachází data definující sessionID, a to v obou požadavcích. To by znamenalo, že dané RequestUnsafe něco musí rozumět minimálně komunikačnímu protokolu (pokud je sessionID v URL) nebo přímo datům (cookies či POSTové proměnné) , pokud se jedná o něco v datech. Z toho plyne, že tu máme co do činění s RequestUnsafe proxy či transparent proxy v prvním případě, v druhém by navíc musela kompletně parsovat data a navíc s nimi pracovat velmi zvláštním způsobem. b) změní se data předpokládejme, sessionID je tedy správné. Potom musí něco přepsat přesně tu část dat, která odpovídá datům zaměněným. Opět tu máme něco, co rozumí datům a buď úmyslně či díky zvláštnímu a chybnému parsování nahradí v požadavku právě přesně těmi daty z jiného požadavku Musím se přiznat, že nevěřím, že by toto dělal firewall. Proto spíš vidím problém na straně aplikace, která datům rozumí a díky drobné nepozornosti mezi židlí a klávesnicí způsobí, že se data navzájem přeplácnou. Protože jde podle mého hloupého názoru opravdu o přeplácnutí dat, nikoli o záměnu sessionID -- Oto 'tapik' Buchta, [email protected], http://tapikuv.blogspot.com
