Proc IDOS pouziva Cookies

[Honza Pazdziora]

"Vladislav Cerny" <black at datis.cdrail.cz> writes:

> Pro zajem nekolika tazatelu uvadim:
>
> Co se tyce vyhledavani spojeni, zde je nutne mit povolene
> Cookies
> z principialniho duvodu. Po vyhledani prvniho spojeni se
> udrzuje pro
> kazdeho uzivatele urcita datova struktura v pameti serveru
> po celou
> dobu platnosti Session a to umoznuje velmi rychle dohledat
> predchozi
> a nasledujici spojeni (volby pres tlacitka na strance
> nalezenych spojeni).

V pameti serveru nebo v nejake perzistentni pameti, predpokladam
relacni databazi. A tam snad neni problem otestovat, jestli dane cislo
session existuje nebo ne -- pokud ano -- dobre, pokud ne, tak se
proste predpoklada zacatek noveho hledani.

> Tato vlastnost znacne pomaha serveru zvladat extremni
> zatez.

Hmmm, nevim, jestli je vhodne to delat primym propojenim session na
interni session v te aplikaci. Spis bych to delal nejakou "cachi", kde
by k parametrum od klienta byly prirazeny pointery do tech datovych
struktur.

> Obejit jejich nutnost jinym zp. neni mozne, protoze v ramci
> vytvorene
> Session se udrzuje krome jineho i pointer na tuto datovou
> strukturu
> a neni mozne pri jejim uvolnovani spolehat na udaj
> odeslany,
> nebo neodeslany, nebo zmodifikovany z browseru
> (editace URL, otevreni dalsiho okna browseru,
> nejasnost, kdy lze pamet jiz uvolnit apod.).

Asi nerozumim presne: na zadny udaj odeslany z browseru neni mozno
spolehat -- HTTP je bezestavovy protokol, vzdy a znovu je nutno
validovat vsechny vstupy.

> Vlastni vyhledavaci algoritmus je realizovan pomoci .DLL
> knihovny
> treti strany (data a knihovna jsou shodne napr. i pro
> Windows verzi
> IDOSu pro samostatne PC) a ta poskytuje mnozinu
> primitivnich
> funkci, nad niz je vybudovane WWW rozhrani jako vyssi
> funkcni celek
> pomoci ASP scriptu. Ty musi respektovat konvence volani
> funkci
> .DLL a neni mozne v jejich ramci kontrolovat napr. platnost
> pointeru.
> Predani neplatneho poiteru znamena havarii serveru.
> (Chvili se pointer predaval jako soucast URL -- pad serveru
> behem
> nekolika minut byl jistotou.)

A v cem se principialne lisi pointer predany v URL od pointeru
predaneho v parametrech od pointeru predaneho v cookies? Co se tyce
spravnosti a schopnosti shodit server, myslim. Vzdyt predat muzu
cokoli -- samozrejme v okenku URL se prepisu snaz, ale existuje treba
POST. Pokud _neni mozno_ neco kontrolovat, tak take neni mozno
dopustit, aby to byl udaj, ktery jde primo od uzivatele -- vzdyt to
jsou v podstate nahodna data.

Takze pokud to shrnu: rikate, ze cookies jsou na idosu potreba proto,
ze si v nich uklada interni pointer na session. V cookies to je proto,
ze to server dostal zpatky a v URL ci parametrech to nemuze byt proto,
aby tam lide nemohli dat jinou hodnotu, nez ktera je spravna, protoze
pred tim, nez se to preda tomu DLL neni mozno platnost toho pointeru
nijak validovat.

Moje odpoved zni: pokud to opravdu chcete udelat stabilne, nemuzete
spolehat na zadny udaj, ktery prijde od klienta. Nejrozmumnejsi se mi
opravdu jevi interni preklad parametru na ten pointer, kde si osetrite
paramtery, ktere jeste pointer nemaji.

S pozdravem,

--
------------------------------------------------------------------------
 Honza Pazdziora | adelton at fi.muni.cz | http://www.fi.muni.cz/~adelton/
                   I can take or leave it if I please
------------------------------------------------------------------------