Proc IDOS pouziva Cookies

[Vladislav Cerny]

Jan "Yenya" Kasprzak <kas at fi.muni.cz> pí¹e v èlánku
<s32ap6.1h.ln at localhost>.
> : Mimo jine to bylo take hlavne proto,
> : ze Cookies a Session bylo nahrazeno
> : necim jinym, jiz zde doporucovanym.
>
> 	Jinymi slovy ze to autori neumeli naprogramovat
dostatecne
> robustne bez cookies a session. To je ale tvrzeni vyrazne
odlisne
> od tvrzeni, ze to bez cookies nejde. Pokud mi jeste
neverite,
> klidne napisu priklad takove "session", implementovane
pomoci URL
> nebo input hidden a nekde to vystavim (vcetne zdrojovych
textu, ovsem).

Mluvime o necem jinem.
Prece nemusim psat stale dokola to same.
Se Sessoin v ASP je to velmi bezpecne, jinak
to je velme nebezpecne. Viz texty
v predchozich prispevcich.

> Perl a CGI snad mate i na NT.

Coze? CGI? To myslite vazne, ze by to server
utahl, kdyby mel pokazde zakladat novy proces?
Tady nejde o server, kam obcas nekdo nahodou zavita.
Tady se musi preferovat vykon, vykon, a az pak vykon.

> 	Proc ne, kdyz zdrojove texty poskytuje i takove firmy
> jako Netscape nebo SunSoft (ta druha s urcitymi
omezenimi) ...

No pred potopenim (Netscape) je holt
dobra jakakoli zachrana.

> 	Nikdo nemluvi o vygenerovani _vsech_ kombinaci
pozadavku.
> Martin jen navrhuje, aby se "predpocitana" data (to jest
ta, ktera
> si nyni uchovavate v ramci Session pro konkretniho
klienta) byla dostupna
> nikoliv jednomu klientovi na zaklade cookie, ale vsem
klientum,
> kteri se zrovna v ten okamzik dotazou na podobny spoj.
Tim jednak
> odstranite cookies (a jakoukoli stavovost), a jednak
jeste vice
> zrychlite vyhledavani.

Autori jiste tuto moznost zvazili.
A jiste ji zamitli proto, ze hitu do takoveto cache by
bylo minimum. Dotazy na spojeni jsou velmi ruznoroda
a zrejme se, diky mnozstvi ruznych podminek, poctu
stanic a vlivu poznamek spojeni (ne vse jede ve vsechny
dni stejne), malokdy opakuji.

> 	Jak to tedy funguje, pokud vyhledavam v jednom okne
spojeni
> z Prahy do Bratislavy a ve druhem z Brna do Koprivnice?
>
> 	Opravdu _zajimave_ - doporucuji. Otevrete si dve okna
> Netscapu na http://idos.datis.cdrail.cz a postupujte
stridave v obou
> oknech takto:
>
> - v prvnim zadejte z Brna do Koprivnice, ve druhem z
Prahy do Bratislavy.
> - az se to dotahne, stisknete v prvnim okne vyhledat. Az
operace skonci,
> 	stisknete Vyhledat i v druhem okne. Pockejte, az operace
skonci.
> - nyni se objevi v obou oknech dotazy, ktere Brno, Prahu,
Bratislavu
> 	ci Koprivnici mate na mysli. Stisknete v prvnim okne
vyhledat,
> 	pockejte az se dotahnou stranky se spoji, a udelejte
totez
> 	ve druhem okne.
> - Nyni v prvnim okne stisknete "vyhledat dalsi spojeni".
Objevi se vam
> 	spoje z Prahy do Bratislavy namisto z Brna do
Koprivnice.
>
> 	Situace je jeste horsi, nez jsem si myslel. Neni to tak,
ze
> pomoci hidden polozky nebo casti URL lze _take_
implementovat session,
> ono to totiz pomoci cookies _nejde_. Nyni nelze nez
prohlasit, ze IDOS
> na WWW nefunguje ani s cookies a ze by bylo dobre WWW
rozhrani
> prepracovat. Vypada to, ze autori WWW rozhrani porad
mysli v intencich
> jednouzivatelskych systemu.

Je videt, ze jste to opet nepochopil, a nepamatujete si
ani co jsme drive psal. Takze pro Ty, kteri se tesili, ze
tady
bude navod, jak shodit IDOS:

Autor prave proti sve vuli dokazal, ze implementovane
Session
perfektne funguji a vse se chova tak, jak je ocekavano.
Preci jsme jiz drive psal, ze dve okna _tehoz_ prohlizece
(tedy dva ruzne thready stejneho procesu) se jevi stale
jako jeden prohlizec. Stavajici reseni pomoci Cookies a
Session
to spravne rozpozna a podle toho se chova.
Pokud si _spustite_ samostatne dva browsery, bude se vse
chovat jako u dvou ruznych uzivatelu a tedy tak, jak autor
ve sve neznalosti ocekaval.

Kdyby to bylo udelano pomoci HIDDEN nebo
pres cast URL, predal byste neplatny pointer
a server by byl pravdepodobne jiz shozen.

Uz je to jasne, proc je stavajici reseni
se Session a Cookies bezpecnejsi???
Vzdyt jste prave o tom podal dukaz!

Vladislav Cerny