Re: michani http requestu
... jak to vlastně dopadlo? Zajímá mě, kde byl zakopaný pes. Petr 2010/9/9 Oto Buchta ta...@buchtovi.cz 2010/9/9 Tomas Beranek beranek.to...@gmail.com: 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, ta...@buchtovi.cz, http://tapikuv.blogspot.com
Re: michani http requestu
On 10/15/2010 08:51 AM, Petr Franta wrote: ... jak to vlastně dopadlo? Zajímá mě, kde byl zakopaný pes. Petr Ja to tipujem na ten firewall / proxy. :-) -- Dusan
Re: michani http requestu
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 :-) dik T. 2010/9/8 Oto Buchta ta...@buchtovi.cz Dne 8. září 2010 17:53 Karel Tejnora ka...@tejnora.cz napsal(a): A jak přiděluje tomcat session? Nemůže ho plést, že nerozená remote IP? Těžko - remoteIP je pro něj IMHO naprosto irelevantní. Opravdu to vidím na problém s instanční proměnnou nebo nějakým jiným sdíleným objektem. Během paralelního běhu dvou požadavků je onomu objektu dvakrát přiřazena hodnota. Aplikaci dejte na pomalý stroj a paralelně na něj posílejte sto požadavků. Šak ono se to nějak projeví. -- Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com
Re: michani http requestu
2010/9/9 Tomas Beranek beranek.to...@gmail.com: 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, ta...@buchtovi.cz, http://tapikuv.blogspot.com
michani http requestu
zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T.
Re: michani http requestu
Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele… Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T.
RE: michani http requestu
Nemuze to no byt spis nejake thread safety issue? Myslim jako napr. to, ze v servletu doGet() nastavim nejakou instancni promennou servletu, nejak s ni pracuju a pak dalsi zavolani z jineho klienta mi ji prenastavi na neco jineho zatimco prvni thread predpoklada, ze ji nikdo nezmenil? Je treba si uvedomit, ze JEE kontainer ma napr. jen jednu (nebo nekolik malo) instanci servletu a ta pak obsluhuje VSECHNY requesty. Nevim, jestli to same plati pro Struts actions, ale neprekvapilo by me to. Tom From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf Of Tomas Beranek Sent: Wednesday, September 08, 2010 10:13 AM To: konference@java.cz Subject: michani http requestu zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T.
Re: michani http requestu
jaky typ autentizace pouzivate? Jedine co me napada, ze se uzivatelske jmeno a heslo drzi v nejake thread local promenne, ktera se po vyrizeni pozadavku nesmaze. To same vlakno potom zpracovava toho uzivatele B. 2010/9/8 Tomas Beranek beranek.to...@gmail.com: zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T. -- S pozdravem Roman Dagi Pichlik /* http://dagblog.cz/ Blog pro kodery */
Re: michani http requestu
Struts standardně vytváří jednu action třídu pro všechny requesty, takže se dá říct, že definice atributu action třídy private int i = 0; je to samé jako, když napíšete private static int i = 0; protože třída je v paměti pouze jednou. Pokud tedy uchováváte lokální data uživatele v atributech action třídy, může to být problém. Také může být problém se špatně nastavenou Cache. Petr F. Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T.
Re: michani http requestu
autentizace klasickej FORM method POST ten thread to asi nebude, nikam se nic neuklada. a hlavne mezi prihlasenim uzivatele A a uzivatele B se mezitim prihlasilo dalsich 20 ruznych klientu korektne. je divne, ze se to stava vzdy jen z browseru, ktere jsou v mobilu. diky za rady. T. Dne 8. září 2010 10:23 Filip Jirsák fi...@jirsak.org napsal(a): Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele... Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T.
Re: michani http requestu
Možná by pomohlo si pustit http tunel a mrknout se na komunikaci mezi klientem a serverem. Po prozkoumání oněch špatných dotazů bude asi jasno, protože se přesně ví co jde na server a co server vrátí. 2010/9/8 Tomas Beranek beranek.to...@gmail.com autentizace klasickej FORM method POST ten thread to asi nebude, nikam se nic neuklada. a hlavne mezi prihlasenim uzivatele A a uzivatele B se mezitim prihlasilo dalsich 20 ruznych klientu korektne. je divne, ze se to stava vzdy jen z browseru, ktere jsou v mobilu. diky za rady. T. Dne 8. září 2010 10:23 Filip Jirsák fi...@jirsak.org napsal(a): Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele… Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T.
Re: michani http requestu
Mozna by zatim stacilo jen logovat requesty spolu s remoteAddr a parametry. Az nastane ten problem, tak zjistit, jestli ten HTTP FORM request byl spravnej nebo ne. 2010/9/8 Petr Franta petr.fra...@gmail.com: Možná by pomohlo si pustit http tunel a mrknout se na komunikaci mezi klientem a serverem. Po prozkoumání oněch špatných dotazů bude asi jasno, protože se přesně ví co jde na server a co server vrátí. 2010/9/8 Tomas Beranek beranek.to...@gmail.com autentizace klasickej FORM method POST ten thread to asi nebude, nikam se nic neuklada. a hlavne mezi prihlasenim uzivatele A a uzivatele B se mezitim prihlasilo dalsich 20 ruznych klientu korektne. je divne, ze se to stava vzdy jen z browseru, ktere jsou v mobilu. diky za rady. T. Dne 8. září 2010 10:23 Filip Jirsák fi...@jirsak.org napsal(a): Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele... Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T. -- Ondra Medek
Re: michani http requestu
To spíš vypadá na problém v synchronizaci (pomíchají se dva souběžné požadavky), než že by byl problém v tom, že data zůstanou přiřazená k vláknu a to pak použije jiný klient. Klasický požadavek z počítače je asi vykonán rychle, takže se nesejdou dva souběžně, ale požadavek z mobilu může být vykonáván déle (pomalejší připojení), takže je větší pravděpodobnost, že v jeho průběhu se vykoná ještě jiný požadavek. Zkuste si logovat začátky a konce požadavků, které vlákno je zpracovává a např. session ID (identifikace klienta). Taky si zkuste nasimulovat několik souběžných (třeba umělým zpomalením) požadavků. S pozdravem Filip Jirsák 2010/9/8 Tomas Beranek beranek.to...@gmail.com: dik ale tohle asi nebude mozne, problem je ze se to stava asi tak 1x za 2 mesice a denne je tu obrovsky traffic, a nejsem schopnej to nasimulovat :-( T. Dne 8. září 2010 10:50 Petr Franta petr.fra...@gmail.com napsal(a): Možná by pomohlo si pustit http tunel a mrknout se na komunikaci mezi klientem a serverem. Po prozkoumání oněch špatných dotazů bude asi jasno, protože se přesně ví co jde na server a co server vrátí. 2010/9/8 Tomas Beranek beranek.to...@gmail.com autentizace klasickej FORM method POST ten thread to asi nebude, nikam se nic neuklada. a hlavne mezi prihlasenim uzivatele A a uzivatele B se mezitim prihlasilo dalsich 20 ruznych klientu korektne. je divne, ze se to stava vzdy jen z browseru, ktere jsou v mobilu. diky za rady. T. Dne 8. září 2010 10:23 Filip Jirsák fi...@jirsak.org napsal(a): Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele… Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T.
Re: michani http requestu
remoteAddr bohuzel nevidim, protoze aplikace je za aplikacnim firewallem, kterej mi tuhle info neda. a do logu si vypisuju, co mi ten FORM posila v username a tam je u uzivatele B username A a pak se na nej prihlasi, takze predpokladam, ze i heslo je z uzivatele A. (heslo z bezp. duvodu logovat nechci) vypada to jako kdyby cestou, asi nekde v tomcatu se request uzivatele B vymenil za request uzivatele A, ale jak rikam je to rozdil treba minuty a mezitim se tam prihlasi dalsich 20 lidi uplne normalne. jeste me napadlo, jestli to nemuze delat nejaka proxy na strane mobilniho providera, ci neco jako mobile opera proxy. kdyz si to tak ctu po sobe, tak me jeste napadlo, ze by to mohl delat ten apliakacni firewall. T. 2010/9/8 Ondra Medek xmed...@gmail.com Mozna by zatim stacilo jen logovat requesty spolu s remoteAddr a parametry. Az nastane ten problem, tak zjistit, jestli ten HTTP FORM request byl spravnej nebo ne. 2010/9/8 Petr Franta petr.fra...@gmail.com: Možná by pomohlo si pustit http tunel a mrknout se na komunikaci mezi klientem a serverem. Po prozkoumání oněch špatných dotazů bude asi jasno, protože se přesně ví co jde na server a co server vrátí. 2010/9/8 Tomas Beranek beranek.to...@gmail.com autentizace klasickej FORM method POST ten thread to asi nebude, nikam se nic neuklada. a hlavne mezi prihlasenim uzivatele A a uzivatele B se mezitim prihlasilo dalsich 20 ruznych klientu korektne. je divne, ze se to stava vzdy jen z browseru, ktere jsou v mobilu. diky za rady. T. Dne 8. září 2010 10:23 Filip Jirsák fi...@jirsak.org napsal(a): Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele... Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T. -- Ondra Medek
Re: michani http requestu
BTW. A remoteAddr neni ani v X-Forwarded-For? http://en.wikipedia.org/wiki/X-Forwarded-For 2010/9/8 Tomas Beranek beranek.to...@gmail.com: remoteAddr bohuzel nevidim, protoze aplikace je za aplikacnim firewallem, kterej mi tuhle info neda. a do logu si vypisuju, co mi ten FORM posila v username a tam je u uzivatele B username A a pak se na nej prihlasi, takze predpokladam, ze i heslo je z uzivatele A. (heslo z bezp. duvodu logovat nechci) vypada to jako kdyby cestou, asi nekde v tomcatu se request uzivatele B vymenil za request uzivatele A, ale jak rikam je to rozdil treba minuty a mezitim se tam prihlasi dalsich 20 lidi uplne normalne. jeste me napadlo, jestli to nemuze delat nejaka proxy na strane mobilniho providera, ci neco jako mobile opera proxy. kdyz si to tak ctu po sobe, tak me jeste napadlo, ze by to mohl delat ten apliakacni firewall. T. 2010/9/8 Ondra Medek xmed...@gmail.com Mozna by zatim stacilo jen logovat requesty spolu s remoteAddr a parametry. Az nastane ten problem, tak zjistit, jestli ten HTTP FORM request byl spravnej nebo ne. 2010/9/8 Petr Franta petr.fra...@gmail.com: Možná by pomohlo si pustit http tunel a mrknout se na komunikaci mezi klientem a serverem. Po prozkoumání oněch špatných dotazů bude asi jasno, protože se přesně ví co jde na server a co server vrátí. 2010/9/8 Tomas Beranek beranek.to...@gmail.com autentizace klasickej FORM method POST ten thread to asi nebude, nikam se nic neuklada. a hlavne mezi prihlasenim uzivatele A a uzivatele B se mezitim prihlasilo dalsich 20 ruznych klientu korektne. je divne, ze se to stava vzdy jen z browseru, ktere jsou v mobilu. diky za rady. T. Dne 8. září 2010 10:23 Filip Jirsák fi...@jirsak.org napsal(a): Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele... Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T. -- Ondra Medek -- Ondra Medek
Re: michani http requestu
to mi bohuzel vraci null :-( 2010/9/8 Ondra Medek xmed...@gmail.com BTW. A remoteAddr neni ani v X-Forwarded-For? http://en.wikipedia.org/wiki/X-Forwarded-For 2010/9/8 Tomas Beranek beranek.to...@gmail.com: remoteAddr bohuzel nevidim, protoze aplikace je za aplikacnim firewallem, kterej mi tuhle info neda. a do logu si vypisuju, co mi ten FORM posila v username a tam je u uzivatele B username A a pak se na nej prihlasi, takze predpokladam, ze i heslo je z uzivatele A. (heslo z bezp. duvodu logovat nechci) vypada to jako kdyby cestou, asi nekde v tomcatu se request uzivatele B vymenil za request uzivatele A, ale jak rikam je to rozdil treba minuty a mezitim se tam prihlasi dalsich 20 lidi uplne normalne. jeste me napadlo, jestli to nemuze delat nejaka proxy na strane mobilniho providera, ci neco jako mobile opera proxy. kdyz si to tak ctu po sobe, tak me jeste napadlo, ze by to mohl delat ten apliakacni firewall. T. 2010/9/8 Ondra Medek xmed...@gmail.com Mozna by zatim stacilo jen logovat requesty spolu s remoteAddr a parametry. Az nastane ten problem, tak zjistit, jestli ten HTTP FORM request byl spravnej nebo ne. 2010/9/8 Petr Franta petr.fra...@gmail.com: Možná by pomohlo si pustit http tunel a mrknout se na komunikaci mezi klientem a serverem. Po prozkoumání oněch špatných dotazů bude asi jasno, protože se přesně ví co jde na server a co server vrátí. 2010/9/8 Tomas Beranek beranek.to...@gmail.com autentizace klasickej FORM method POST ten thread to asi nebude, nikam se nic neuklada. a hlavne mezi prihlasenim uzivatele A a uzivatele B se mezitim prihlasilo dalsich 20 ruznych klientu korektne. je divne, ze se to stava vzdy jen z browseru, ktere jsou v mobilu. diky za rady. T. Dne 8. září 2010 10:23 Filip Jirsák fi...@jirsak.org napsal(a): Zdravím, neukládáte něco do LocalThread proměnných a nezapomínáte to mazat? Uživatel pak vyfasuje vlákno s údaji jiného uživatele... Případně může jít o jiný problém se synchronizací, kdy si vlákna navzájem přepisují data. S pozdravem Filip Jirsák Dne 8. září 2010 10:13 Tomas Beranek beranek.to...@gmail.com napsal(a): zdravim, mam problem a absolutne nechapu co s tim resp. ani nevim pricinu. aplikace bezi na jboss 5.1 + struts 1.2.9 obcas se stane, ze klient, ktery pouziva nejaky mobilni prohlizec(ted naposledy NetFront 3.4) se prihlasi na uplne jineho klienta :-( v logu je videt nasledujici. 1.klientA se prihlasi napr.z MSIE dostane sessionID AAA 2.za 50 vterin se prihlasi klient B z mobilu dostane sessionID BBB, ale je videt ze v prihlasovacim formulari odeslal data toho uzivatele A, tedy se prihlasi jako on. kazdy ma jinou session, ale formularova data posila jako kdyby je cestou nekde ukradl (prohodil) behem dne se ten uzivatel z mobilu i nekolikrat prihlasi normalne sam na sebe. diky za kazdou podnetnou radu T. -- Ondra Medek -- Ondra Medek
Re: michani http requestu
A jak přiděluje tomcat session? Nemůže ho plést, že nerozená remote IP?
