Proc IDOS pouziva Cookies

[Jan "Yenya" Kasprzak]

"Vladislav Cerny" <black at datis.cdrail.cz> napsal:
:
: Navrhovana reseni pouzivajici jine metody jsou
: nedostatecne.
: Napr. pouzijeme reseni, kdy se do POST da
: primo onen pointer. Pak muze prijit neplatny pointer:
: Jak to muze nastat jsme rovnez popisoval:
: V jednom okne se vyhleda spojeni. Vznikne platne neco
: (pointer, session ID), rikejme tomu treba pointer. Ten bude
: soucasti
: POST dat. Udela se Nove okno prohlizece. V prvnim okne se
: pokracuje
: ve vyhledavani jinych spojeni. Obe okna maji z pohledu
: serveru shodnou
: identitu. Pro daneho uzivatele se tedy vytvori nova dat.
: struktura v pameti
: serveru s jinym spojenim na JINEM miste v pameti. Puvodni
: pointer
: je neplatny. Uzivatel ted pouzije to druhe okno a pozada o
: nasledujici
: spojeni. POSTem prijde neplatny pointer, server se pokusi
: uvolnit data
: v pameti, kde jiz data nejsou...
:
	Dekuji za trojnasobne vysvetleni :-) ale stejne to nechapu.
Stejny problem (s vytvorenim noveho okna prohlizece) prece nastava
i u cookies, ne? Pokud si vytvorim nove okno a v nem neco hledam,
a pak chci neco hledat v puvodnim okne, pak budto

- puvodni okno pouzije "nove" cookie, ktere uz mezitim stihl browser
	dostat,
- anebo pouzije puvodni cookie, jehoz "session" (jak to nazyvate) na
	www serveru je uz uplne jinde.

	V obou pripadech by se melo rozpoznat, ze data ve formulari
nesouhlasi s tim, co rika cookie, a generovat se novy cookie pro toto
okno. Stejne tak se ale muze generovat hidden polozka nebo URL.

	Pokud je vas software opravdu napsany natolik spatne, nelze
nez se smirit s tim, ze pada. Podle meho nazoru jste stale neuvedl
duvod, proc by se tohle muselo delat pres cookies.

: V pripade Cookies a Session to nastat nemuze, protoze
: na konci Session se data z pameti uvolnuji a diky tomu,
: ze Session je platna, jsou platna i data i pointer.

	Zacinam mit dojem, ze ta "session", co vy uvadite, je neco tajemneho,
cemu nerozumim :-) Jak se pozna konec "session"? Ze po nejakou dobu neprijde
pozadavek od klienta?

	Jak spravne pisete:

: Proto NENI mozne, aby cokoli, co nelze overit, bylo
: posilano browserem,
: PROTO to nemuze byt soucasti dat od browseru
: (INPUT HIDDEN, URL, POST apod.), PROTO to musi byt ulozeno
: na serveru,
: PROTO se musi preklenout bezestavovost HTTP protokolu,

	Do vyse uvedeneho "apod." lze ovsem zahrnout i cookies. Ty jsou take
posilany browserem a muze je kdokoli modifikovat. Pokud nekontrolujete
cookies, jde o security through obscurity a mate zadelano na problemy.
_SAMOZREJME_, ze data, ktera dostanete v hidden polozce, v URL nebo
jinde (v cookie) musite nekde validovat a prevadet treba na nejaky
pointer, to jest musite si na serveru drzet "cache" nekolika poslednich
"sessions". A pokud nekdo posle data (hidden polozka, URL nebo cookie),
ktera v cache nemate (anebo jejichz data nesouhlasi se zbytkem polozek
ve formulari), vytvorite proste novou "session" (poslete stranku s novym URL,
hidden polozkou, nebo cookie) a ulozite do cache.

	Porad jeste nechapu, v cem (krome vlivu na soukromi) se cookies
lisi od hidden polozky nebo od URL.

\begin{hrach na stene :-}
	Pokud byste mi dal zdrojove texty IDOSu, klidne bych neco takoveho
naprogramoval (a troufnu si rict, ze vzhledem k OS, ktery bych pouzil,
by to bylo rychlejsi a stabilnejsi, nez to co mate ted). Zaroven by se
zverejneni zdrojaku IDOSu urcite kladne projevilo jednak na kvalite
jeho kodu a jednak na obecnem nazoru na Ceske Drahy.
\end{hrach na stene :-}

-Yenya

PS.: Pevne verim, ze jsme jeste stale on-topic. Pokud ne, prosim spravce
	teto konference, aby mi dal vedet - pak bychom se presunuli nekam
	jinam. Tohle tema me celkem zajima.

--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
If there are race conditions in programs fix them. The "my programs suck fix
something else" mentality leads you to things like Java.         -- Alan Cox