Proc IDOS pouziva Cookies

[Vladislav Cerny]

> > > 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,
> >
> > Zrejme myslite session ve smyslu vyhledavani.
> > Ne, v Cookies se uklada jen a pouze SessionID.
>
> A jaky je pak principialni problem to Session ID ukladat
v parametru
> skriptu treba pri POST? Jenom to, ze v ASP se na tento
parametr pak
> nekokazete dostat?

Ne.
Uz jsem to tady popisoval.
Vami navrhovane reseni je shodne s tim, kdy se do POST da
primo onen pointer. Je jedno, jestli prijde neplatny
pointer,
nebo neplatne SessionID.
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...

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,
PROTO byly
zavedeny Sessions v ASP, PROTO je IDOS pouziva.
Kazde jine reseni je principialne nespravne, nebo minimalne
zbytecne
komplikovane protoze tady je na to nastroj (Cookies a
Session).
Navrhy na zmenu principu s vyuzivanim dat. struktur v
pameti a pointeru
jsou take nepouzitelne -- viz drive: jednotna DLL i pro PC
verzi, treti firma
apod.

S pozdravem
Vladislav Cerny