Proc IDOS pouziva Cookies
Vladislav Cerny
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).
Tato vlastnost znacne pomaha serveru zvladat extremni
zatez.
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.).
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.)
Vladislav Cerny, CD s.o., DATIS o.z., Plzen, Czech Republic
e-Mail: bl...@datis.cdrail.cz
Petr Nachtmann
> 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.).
> .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.)
Takze pomoci modifikace cookies je mozne sestrelit server? :)
PN
Pavel Kolesnikov
: 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.).
[...]
: Predani neplatneho poiteru znamena havarii serveru.
: (Chvili se pointer predaval jako soucast URL -- pad serveru
: behem nekolika minut byl jistotou.)
Takze kdyby vam nahodou chtel nekdo shodit server, tak staci poslat
par dotazu obsahujicich radek "Cookie: ASPSESSIONID=nejaky_nesmysl" ??
Doufam, ze jsem vas spatne pochopil...
Pavel
Honza Pazdziora
> 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 | ade...@fi.muni.cz | http://www.fi.muni.cz/~adelton/
I can take or leave it if I please
------------------------------------------------------------------------
Matus fantomas
->> .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.)
-> Takze pomoci modifikace cookies je mozne sestrelit server? :)
no ako som pochopil ja chvilu to tak bolo, potom sa zreje urobila databaza
na prevod cookie-> pointer a je to bez problemov...
--
Matus "fantomas" Uhlar, sysadmin at NETLAB+ Kosice, Slovakia
BIC coord for *.sk; admin of netlab.irc.sk; co-admin of irc.felk.cvut.cz
Bohumil Chalupa
On Mon, 20 Jul 1998, Pavel Kolesnikov wrote:
> : Predani neplatneho poiteru znamena havarii serveru.
> : (Chvili se pointer predaval jako soucast URL -- pad serveru
> : behem nekolika minut byl jistotou.)
>
> Takze kdyby vam nahodou chtel nekdo shodit server, tak staci poslat
> par dotazu obsahujicich radek "Cookie: ASPSESSIONID=nejaky_nesmysl" ??
> Doufam, ze jsem vas spatne pochopil...
Absence odpovedi nejspis znamena, ze se na tom hooorecne pracuje. :-)
BoChal.
Petr Nachtmann
>
> no ako som pochopil ja chvilu to tak bolo, potom sa zreje urobila databaza
> na prevod cookie-> pointer a je to bez problemov...
Na to by prece stacila databaze _parametr_ v URL -> pointer...
PN
Martin....@cerge.cuni.cz
>> par dotazu obsahujicich radek "Cookie: ASPSESSIONID=nejaky_nesmysl" ??
>> Doufam, ze jsem vas spatne pochopil...
>Absence odpovedi nejspis znamena, ze se na tom hooorecne pracuje. :-)
Nevim, na cem se pracuje, ale momentalne (resp. cely den) IDOS
vraci Error ASP 0115. :-(
Kolegovi jsem se nesmirne zavdecil, kdyz jsem mu prozradil konkurencni
zdroj, ktery dnes nekdo zminil, tj. bahn.hafas.de, timto rovnez dekuji.
Martin Postulka
Vladislav Cerny
> 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.
Nedela to zadny script, nebo program (nebo ja), dela to
mechanismus ASP. ASP diky tomu zavadi stav do HTTP komunikace
a onen pointer je ulozen v pameti serveru. Prave proto, ze jak spravne
pisete,
na nic, co prijde od klienta nelze spolehnout.
A kdyz zmenite SessionID? Posluzte si, proste to bude nova
Session a spojeni se nenajde stejne jako kdyz mate Cookies vypnute.
Vypne-li si totiz nekdo Cookies, pak kazdy pozadavek na URL
z takoveho zmrzaceneho browseru zaklada novou Sesion.
VC
Vladislav Cerny
> par dotazu obsahujicich radek "Cookie: ASPSESSIONID=nejaky_nesmysl" ??
> Doufam, ze jsem vas spatne pochopil...
>
Jak chcete poslat dotaz obsahujici takovyto nesmyslny radek?
Myslite jako ze budete predstirat jinou Session?
Vladislav Cerny
>
>
To Cookie je ulozene v pameti, ne na disku.
(Tak ted uz vite, kde mate hledat)
VC
Vladislav Cerny
>
> no ako som pochopil ja chvilu to tak bolo, potom sa zreje urobila
databaza
> na prevod cookie-> pointer a je to bez problemov...
> BIC coord for *.sk; admin of netlab.irc.sk; co-admin of irc.felk.cvut.cz
No skoro. Napred to bylo soucasti dat v POSTU.
Ted je to ulozene na serveru -- pro kazdeho klienta v ramci
jeho Session.
Pokud je to i pro ostatni zajimave, doporucuji jim precist si
dokumentaci k ASP a jak je realizovana Session.
VC
Vladislav Cerny
Bohumil Chalupa <boc...@apollo.karlov.mff.cuni.cz> píše v článku
<1998072014...@ns.felk.cvut.cz>…
> > Takze kdyby vam nahodou chtel nekdo shodit server, tak staci poslat
> > par dotazu obsahujicich radek "Cookie: ASPSESSIONID=nejaky_nesmysl" ??
> > Doufam, ze jsem vas spatne pochopil...
>
> Absence odpovedi nejspis znamena, ze se na tom hooorecne pracuje. :-)
>
> BoChal.
Nebo dovolenou, kdyz konecne nastalo dvoudenni leto, ze?
VC
Vladislav Cerny
> vraci Error ASP 0115. :-(
>
> Kolegovi jsem se nesmirne zavdecil, kdyz jsem mu prozradil konkurencni
> zdroj, ktery dnes nekdo zminil, tj. bahn.hafas.de, timto rovnez dekuji.
>
> Martin Postulka
Zrejme se server podarilo nekomu shodit.
Bud se podeli o zkusenost a umozni tak opravu,
nebo mame mezi sebou skodnou, ktera nepreje ostatnim
pouzivat IDOS.
VC
Jan Yenya Kasprzak
:
: Takze pomoci modifikace cookies je mozne sestrelit server? :)
:
Vypada to, ze uz to nekdo zkousel :-)
IDOS mi pise tohle:
: error 'ASP 0115'
:
: Unexpected error
:
: /mainidos.asp
:
: A trappable error occurred in an external object.
: The script cannot continue running.
Jeste stale tady nebyl recen zadny realny argument pro pouziti
cookies na IDOSu (takovy, ktery by nebyl pouzitelny i na jine metody).
-Yenya
--
\ 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
Jan Yenya Kasprzak
: Petr Nachtmann <petr...@natur.cuni.cz> wrote:
:
: -> Takze pomoci modifikace cookies je mozne sestrelit server? :)
:
: no ako som pochopil ja chvilu to tak bolo, potom sa zreje urobila databaza
: na prevod cookie-> pointer a je to bez problemov...
No a pokud mate prevod cookie->pointer, pak vam uz nic nebrani
uplne stejne udelat prevod url->pointer nebo HIDDEN pole ve formulari
->pointer a podobne. Nebo jsem neco nepochopil?
Porad jeste nevidim, proc tam ty cookies musi byt namisto
neceho standardniho (HIDDEN pole nebo cast URL).
Honza Pazdziora
> > 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?
Vladislav Cerny
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
Vladislav Cerny
<qspvo6.de.ln@localhost>.
> No a pokud mate prevod cookie->pointer, pak vam uz nic
nebrani
> uplne stejne udelat prevod url->pointer nebo HIDDEN pole
ve formulari
> ->pointer a podobne. Nebo jsem neco nepochopil?
>
> Porad jeste nevidim, proc tam ty cookies musi byt
namisto
> neceho standardniho (HIDDEN pole nebo cast URL).
>
> -Yenya
Protoze 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.
Viz take odpoved Honzovi Pazdziorovi na jeho dotaz z 21.7.
v 9:10
VC
Vladislav Cerny
pouziti
> cookies na IDOSu (takovy, ktery by nebyl pouzitelny i na
jine metody).
>
> -Yenya
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...
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.
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
Jan Yenya Kasprzak
: Zrejme se server podarilo nekomu shodit.
: Bud se podeli o zkusenost a umozni tak opravu,
: nebo mame mezi sebou skodnou, ktera nepreje ostatnim
: pouzivat IDOS.
Jeste ze je tady ta konkurence v Nemecku (zkousel jsem,
fakt dobre). Hazet vinu na nejakou "skodnou" mi prijde dost alibisticke.
Mate (pravdepodobne) chybne napsanou aplikaci (nebo pouzivate nestabilni
OS :-) a za to nikdo zvenku nemuze.
Skoda, ze od IDOSu nejsou zdrojove texty. Myslim, ze Ceskym
draham by to zas tolik neuskodilo, a navic by nekdo napsal _stabilni_
webovou formu IDOSu. Ta co byla jeste pred nekolika mesici sice nemela
tolik vlastnosti, ale zato fungovala.
S pozdravem,
Vladislav Cerny
> "Vladislav Cerny" <bl...@datis.cdrail.cz> napsal:
> : Zrejme se server podarilo nekomu shodit.
> : Bud se podeli o zkusenost a umozni tak opravu,
> : nebo mame mezi sebou skodnou, ktera nepreje ostatnim
> : pouzivat IDOS.
>
> Jeste ze je tady ta konkurence v Nemecku (zkousel jsem,
> fakt dobre). Hazet vinu na nejakou "skodnou" mi prijde
dost alibisticke.
> Mate (pravdepodobne) chybne napsanou aplikaci (nebo
pouzivate nestabilni
> OS :-) a za to nikdo zvenku nemuze.
Pokud nekdo umyslne shazuje verejne prospesne servery,
je to skodna, at si o tom mysli kdo chce co chce.
Staci se jen podivat, kolik lidi si okamzite na cizich
ostrych serverech
chce vyzkouset jakoukoliv bezpecnostni diru, o ktere se
dozvi, se
zcela umyslnou snahou skodit.
Tato skupina lidi je SKODNOU, protoze skodi.
Je lhostejne, zda vyuziji chybu aplikace, OS, ci cehokoli
jineho.
>
> Skoda, ze od IDOSu nejsou zdrojove texty. Myslim, ze
Ceskym
> draham by to zas tolik neuskodilo, a navic by nekdo
napsal _stabilni_
> webovou formu IDOSu. Ta co byla jeste pred nekolika
mesici sice nemela
> tolik vlastnosti, ale zato fungovala.
Postupne se ke stabilite propracovavame.
Od puvodnich cca 10 min. mezi havariemi, kdy se stavovost
IDOSu realizovala zde doporucovanymi zpusoby
(INPUT HIDDEN, URL, data v POST apod.) az po stavajici,
celkem stabilni stav -- nepocitam to pondelni faux pas, kde
server vetsinu dne stal a ja o tom nevedel. V Po vecer jsme
jej
spustil a zatim bezi. Jen od dnesni pulnoci zpracoval
pres 35 000 scriptu, tak ta stabilita zas neni tak spatna.
P.S.:
Tu stbailni verzi by ste si predstavoval jak?
Zrejme ne na platforme MS IIS a ASP. Pak Vam zdrojove
texty ASP scriptu k nicemu nebudou. Potrebujete datove
soubory (ty jsou na ftp://ftp.cdrail.cz/IDOS_DATA/ volne ke
stazeni). Jaky maji vnitrni format nevim, pouzivam
rozhranni
DLL knihovny, to dostanete k dispozici, zakoupite-li si
Windows
verzi IDOSu. Jmena funkci si zjistite z DLL uz jiste sam.
Tak ted mate k dispozici vse, co potrebujete.
VC
>
> S pozdravem,
>
> -Yenya
Jan Yenya Kasprzak
:
: 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.
Pavel Kolesnikov
: Porad jeste nechapu, v cem (krome vlivu na soukromi) se cookies
: lisi od hidden polozky nebo od URL.
Ted se musim zeptat - v cem se VCETNE vlivu na soukromi lisi cookie
od hidden polozky nebo URL? Jakou ujmu na vase soukromi bude mit fakt,
ze spravci idos.datis.cdrail.cz budou moci zjistit, ze neznamy clovek
z domeny muni.cz si behem jednoho otevreni prohlizece (server pouziva
cookie bez uvedeni expirace) vyhledal ta a ta spojeni (cookie nema
ani uvedenou domenu, tudiz se neda dat do souvislosti s vasim dalsim
pohybem po WWW strankach v domene cdrail.cz)?
Maximalne muze pomozi takto ziskanych informaci byt ziskana jakasi
korelace mezi spojenimi pouzivanymi internetovou populaci obecne,
coz (kdyby si s tim cirou nahodou nekdo tu praci dal) by bylo spise
ku prospechu veci.
Pavel
Altair
>cemu nerozumim :-) Jak se pozna konec "session"? Ze po nejakou dobu
neprijde
>pozadavek od klienta?
Session v ASP je takova, ze pri pozadavku se klientovi posle cookie,
obsahujici polozku ASPSESSIONID. Skrzeva tu je uzivatel identifikovan.
Skutecna data jsou ulozena na serveru a jsou jenom identifikovana podle
cookies. Session zanika bud po dvaceti minutach, po kterych neprijde
pozadavek od klienta (cas lze samozrejme nastavit), nebo explicitne
ukoncenim v ASP.
Takze pokud bude v jednom ASPcku napsano <% Session("NejakyParametr") =
"Nejaka hodnota"%>, v druhem mohu pouzit <% Response.Write
Session("NejakyParametr") %> nebo session ukoncit <% Session.Abandon %>.
Pri pozadavku od klienta, ktery cookie nema, se vygeneruje nova session,
stejne jako pri chybnem SessionID.
Blizsi informace: news:cz.comp.microsoft.asp,
http://www.activeserverpages.com, http://localhost/iishelp/ za predpokladu,
ze mas na lokale nainstalovane IISko, coz asi nemas, takze doporucuji
active.... .com
-- Altair
Martin Mares
> od hidden polozky nebo URL?
V tom, ze URL je standardni soucasti HTTP a hidden polozky jsou standardni
soucasti HTML, kdezto cookies jsou volitelna extenze.
Have a nice fortnight
--
Martin `MJ' Mares <m...@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"DOS never says "EXCELLENT command or filename"..."
Martin Mares
> posilano browserem,
A kdo posila cookies???
Have a nice fortnight
--
Martin `MJ' Mares <m...@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"This line is umop apisdn."
Martin Mares
> Tu stbailni verzi by ste si predstavoval jak?
> Zrejme ne na platforme MS IIS a ASP.
Existuje mimo jiz citovanou zavislost na nekym jinym vyvinute
DLL knihovne jediny rozumny duvod, proc pouzivat MS IIS a ASP
a nikoliv nejaky "real operating system"?
> Pak Vam zdrojove
> texty ASP scriptu k nicemu nebudou. Potrebujete datove
> soubory (ty jsou na ftp://ftp.cdrail.cz/IDOS_DATA/ volne ke
>
> stazeni). Jaky maji vnitrni format nevim, pouzivam
> rozhranni
> DLL knihovny, to dostanete k dispozici, zakoupite-li si
> Windows
> verzi IDOSu. Jmena funkci si zjistite z DLL uz jiste sam.
> Tak ted mate k dispozici vse, co potrebujete.
Nikoliv. Windows osobne nepovazuji za rozumnou platformu pro provoz
sitovych aplikaci. Myslim si, ze kdyby Ceske drahy zverejnily format dat,
nasla by se spousta lidi, kteri by radi napsali vlastni vyhledavaci server
pod UNIXem (ja jsem jednim z nich).
[Poznamka pod carou: Neberte mne jako odpurce IDOSu, pouzivam jej pomerne
casto, ale na druhou stranu bych si dokazal predstavit, jak v nem spoustu veci
zlepsit.]
Preji krasny den
--
Martin `MJ' Mares <m...@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"A. G. Bell is alive and well in New York and still waiting for the dial tone."
Altair
>DLL knihovne jediny rozumny duvod, proc pouzivat MS IIS a ASP
>a nikoliv nejaky "real operating system"?
Nechtejte se prosim dostat do obvyklych zabomysich sporu ohledne Toho
Jedineho Spravneho Operacniho Systemu Jaky By Mel Kazdy Pouzivat.
-- Altair
Vladislav Cerny
nechapu.
Opravdu to nechapete.
Nejde o Cookie. To je jen nastroj pro vytvoreni Session
a Session vytvari stovove prostredi. Prectete si, proism,
dokumentaci k ASP.
> Stejny problem (s vytvorenim noveho okna prohlizece)
prece nastava
> i u cookies, ne? Pokud si vytvorim nove okno a v nem neco
hledam,
Pokud tedy pouzijete volbu Soubor, Nove okno, je to
stale tataz Session. Jen se spusti novy thread tehoz
browseru.
Pokud spustite dalsi instanci browseru, bude to nova
Session,
cili zcela novy uzivatel.
V obo pripadech si muzete delat co chcete, k uvolneni
pameti
dojde vzdy korektne.
> - anebo pouzije puvodni cookie, jehoz "session" (jak to
nazyvate) na
> www serveru je uz uplne jinde.
Je videt, ze se Vam to plete. Cookie nema zadnou Session.
Session nema zadne Cookie.
Pouze se pomoci Cookie a SessionID identifikuje uzivatel,
takze lze poznat, ktere relece browser -- server patri
jednomu
uzivateli. Ono totiz soucasne muze pristupovat k serveru
vice
uzivatelu a server vyrizuje jejich pozadavky v poradi, jak
prichazeji,
tedy na preskacku. Ale to bych tu uz popisoval uplne
zaklady.
> 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.
Cookie se negeneruje v zadne zavislosti na obsahu
formulare,
prenasene stranky apod. Viz vyse.
> Pokud je vas software opravdu napsany natolik spatne,
nelze
> nez se smirit s tim, ze pada.
On ale nepada (protoze pouziva Cookies a Sessions :-) ).
Pouze nekteri uzivatele maji problem, ze si vypnou Cookies,
a pak si mysli, ze server pada.
> Podle meho nazoru jste stale neuvedl
> duvod, proc by se tohle muselo delat pres cookies.
No prece proto, ze v ASP je Session implementovana pomoci
Cookies. Co je na tom, proboha, tak nepochopitelneho?
> 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?
Vazne tomu vubec nerozumite.
Nebudu Vam to tady uz dale vysvetlovat. Opravdu bude lepsi,
kdyz si o tom napred neco prectete a nebudete psat pouze
sve chybne dohady.
Session zanika po TimeOutu. Pak se samozrejme opet
korektne uvolni data z pameti, protoze pointer je diky
Session
stale platny.
> 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.
To je furt o tom samem.
Tak znovu:
Zmodifikovane Cookies pouze serveru oznami neexistujici
SessionID.
> _SAMOZREJME_, ze data, ktera dostanete v hidden polozce,
v URL nebo
> jinde (v cookie) musite nekde validovat a prevadet treba
na nejaky
V Cookie se _ZADNA_ data (pointer) nepredava a neuchovava.
To vse je ulozeno NA SERVERU.
Pochopte to uz!
> Porad jeste nechapu, v cem (krome vlivu na soukromi) se
cookies
> lisi od hidden polozky nebo od URL.
> 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).
Kdyz Vam dam zdrojaky, tak uz toho moc programovat
nemusite ne?
Ono je jedna vec mit silna slova a druha vec je pak
podeprit
nejakym cinem.
> Zaroven by se
> zverejneni zdrojaku IDOSu urcite kladne projevilo jednak
na kvalite
> jeho kodu a jednak na obecnem nazoru na Ceske Drahy.
Zajimavy nazor.
> -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.
Musim s epriznam, ze mne uz to moc nebavi a zacinam
povazovat vysvetlovani neceho, cehoz princim si muze kazdy
precist v dokumentaci za ztratu casu.
> \ Jan "Yenya" Kasprzak <kas at fi.muni.cz>
http://www.fi.muni.cz/~kas/
Vladislav Cerny
bl...@datis.cdrail.cz
Vladislav Cerny
<1998072217...@ns.felk.cvut.cz>…
> Zdravim,
>
> Existuje mimo jiz citovanou zavislost na nekym jinym
vyvinute
> DLL knihovne jediny rozumny duvod, proc pouzivat MS IIS a
ASP
> a nikoliv nejaky "real operating system"?
To je tak akorat na FlameWar typu
"Ktery OS je lepsi".
Duvodu je vice, vcetne historickych.
ASP poskytuje z hlediska vyvojare mnoho
uzitecnych vlastnosti pro podobne aplikace
jako stvorenych.
> Nikoliv. Windows osobne nepovazuji za rozumnou
platformu pro provoz
> sitovych aplikaci. Myslim si, ze kdyby Ceske drahy
zverejnily format dat,
> nasla by se spousta lidi, kteri by radi napsali vlastni
vyhledavaci server
> pod UNIXem (ja jsem jednim z nich).
Abych pravdu rekl, ja ten format take neznam.
Ale zkuste pozadavek uplatnit napr. u Ing. Rakusana,
rak...@datis.cdrail.cz (sedi o cca 120 km dale).
Je vsak temer jiste, ze Vam nevyhovi.
CD garantuje platnost dat a ta se pomerne casto meni.
Naposledy ted ze So na Ne v noci.
Jiny provozovatel by tuto garanci poskytnout nemohl
a nabizel by neplatne informace.
> [Poznamka pod carou: Neberte mne jako odpurce IDOSu,
pouzivam jej pomerne
> casto, ale na druhou stranu bych si dokazal predstavit,
jak v nem spoustu veci
> zlepsit.]
Sem s namety.
Nikdo nevymysli nic idealne, uvitam namety na
zlepseni IDOSu (vim, ze mame nektere rozdiskutovane).
>
> Preji krasny den
> --
> Martin `MJ' Mares <m...@ucw.cz>
http://atrey.karlin.mff.cuni.cz/~mj/
Vladislav Cerny
Vladislav Cerny
> > posilano browserem,
>
> A kdo posila cookies???
Browser. Ale Cookies neobsahuje zadna aplikacni
data, neni je tedy treba na aplikacni urovni osetrovat.
Navic Cookies nemuze prostym pouzivanim a
manipulaci s okny uzivatel modifikovat, narozdil
jiz drive mnou popsanem zpusobu ovlivneni platnosti
dat predavanych browserem zpet serveru.
Uschovavani dat na strane klienta (a to jsou metody
INPUT HIDDEN, soucast URL nebo POST dat) je nespolehlive.
Kdyz se server ulozi data sam u sebe a eviduje si,
kteremu uzivateli patri je to spolehlivejsi.
To evidenci si zajistuje prave pomoci Cookies, pomosi
nichz s evytvari relace mezi browserem a serverem
(Session).
Vladislav Cerny
Vladislav Cerny
<3o36p6.ri.ln@localhost>.
>
> : Tu stbailni verzi by ste si predstavoval jak?
> : Zrejme ne na platforme MS IIS a ASP. Pak Vam zdrojove
> Bohuzel jste neodhadl platformu, na ktere bych tohle
realizoval.
> Samozrejme by to byl nejaky UN*X a Apache. Tam by mi
jeden neplatny
Jak to ze ne?
Napsal jsem
> : Zrejme __ne__ na platforme MS IIS a ASP. Pak Vam
zdrojove
a UNIX je snad platforma jina nez MS IIS a ASP?
> Mimochodem, konecne mi nekdo vysvetlil, co je to ta
"session",
> o ktere mluvite.
Tak to se mi skutecne ulevilo.
Ja uz ztracel nadeji, ze se mi to podari.
> Pro ostatni, kteri sleduji svet Nove Technologie
> ze stejne bezpecne vzdalenosti, jako ja: ASP poskytuje
pry programatorovi
> nejake "stavove" rozhrani, ktere si samo implementuje
pomoci cookies
> a samo "nejak" resi ukonceni "session" po nejakem
timeoutu. Je to pry
> celkem transparentni k pouzivani, ale ma to tu nevyhodu,
ze programatori,
> kteri nevedi, co presne za tim je, pak nevi, ze totez lze
udelat i pomoci
> hidden polozky nebo zmeny URL. Nemaji k dispozici
implementaci v nejake
> knihovne, takze tato moznost (po technicke strance uplne
stejna) pro ne
> neexistuje. Ach jo.
Tak ted uz to zase vypada, ze jste to jeste nepochopil.
Opravdu si prectete tu dokumentaci, ozrejmi se Vam pojmy
"nejake", "nejak", "samo".
>
> S pozdravem
>
> -Yenya
Vladislav Cerny
Hynek Med
> Abych pravdu rekl, ja ten format take neznam. Ale zkuste pozadavek
> uplatnit napr. u Ing. Rakusana, rak...@datis.cdrail.cz (sedi o cca
> 120 km dale). Je vsak temer jiste, ze Vam nevyhovi. CD garantuje
> platnost dat a ta se pomerne casto meni. Naposledy ted ze So na Ne v
> noci. Jiny provozovatel by tuto garanci poskytnout nemohl a nabizel by
> neplatne informace.
Taz databaze je zrejme pouzivana na http://bahn.hafas.de/, a to diky tomu,
ze DB jsou clenem nejake unie zeleznic, ktere si navzajem vymenuji data
jizdnich radu v elektronicke forme. Myslim ze by nebyl problem ta data
poskytovat timto kanalem komukoliv jinemu.
> Sem s namety. Nikdo nevymysli nic idealne, uvitam namety na zlepseni
> IDOSu (vim, ze mame nektere rozdiskutovane).
Jestli mohu take navrhnout nejake namety.. Podivejte se na
http://bahn.hafas.de/.. Zvlast hezky je tam tisk do PostScriptu a moznost
vytvoreni "jizdniho radu" stanice.
Hynek
Martin....@cerge.cuni.cz
>Ale zkuste pozadavek uplatnit napr. u Ing. Rakusana,
>rak...@datis.cdrail.cz (sedi o cca 120 km dale).
>Je vsak temer jiste, ze Vam nevyhovi.
>CD garantuje platnost dat a ta se pomerne casto meni.
>Naposledy ted ze So na Ne v noci.
>Jiny provozovatel by tuto garanci poskytnout nemohl
>a nabizel by neplatne informace.
Co ma co garance platnosti dat delat s utajovanim jejich struktury.
To je nekde stanoveno v predpisech, ze CD nesmi ta data poskytnout,
nebo ze aspon je musi poskytovat tak, aby z nich nebyl zadny uzitek.
Takovy predpis bych si rad precetl a rad bych videl, kdo je pod nim
podepsany.
Jinak mi to pripada jako nejapna vymluva.
Pardon, pardon, ale je to tak.
Martin Postulka
Petr Nachtmann
> si tim vyslouzil zarazeni do nejakych spamovacich databazi. Proto mam
???
Vladislav Cerny
<1998072309...@ns.felk.cvut.cz>…
> Tady je to podle meho nazoru logicky vykloubene. Proc se
vytvareji data
> pro uzivatele? Pri hledani v jizdnich radech je podle
meho nazoru jedinou
> smysluplnou identifikaci pozadavku odkud, kam a zhruba v
kolik se jede. Je
> uplne jedno, zda se pta Hurvinek nebo Manicka, ze ktereho
> okna/pocitace/site/statu je dotaz polozen.
> Hledani je podle mne DOST bezstavove: server dostane
dotaz na spojeni s
> vyse uvedenymi identifikacnimi priznaky, alokuje si
datove struktury,
> vyhleda odpoved, posle ji, datove struktury zase zrusi a
tim konci.
Nevim, zda jste cetl cely thread.
Vyhledavaci algoritmus je realizovan .DLL
knihovnou. Jeji autori po dlouholete zkusenosti
s postupnym vyvojem IDOSu pro MS-DOS a pote
i Windows, ktery pouziva shodnou .DLL pouzivaji
tento mechanizmus, ktery zvysuje efektivitu
vyhledavani. Maji zrejme zjisteno, ze uzivatele
po vyhledani spojeni pozaduji casto Predchazejici/
Nasledujici. Je zbytecne provadet znovu vypoctove
narocne vyhledani, staci si podrzet v pameti
jistou datovou strukturu obsahujici nejaky
predvyhledany polotovar. Ten pak umoznuje rychle
dohledat Nasl./Predch. spojeni.
DLL nabizi primo funkce, ktere toto dohledaji
na zaklade predaneho paramnetru - pointeru na dat.
strukturu.
Z tohot stavu je nutne vyjit pri navrho scriptu.
Proto je hledani stavove.
> Pokud
> za chvili prijde dotaz na spojeni se stejnymi koncovymi
body, ale casem o
> neco pozdejsim, on si ho nebude davat do zadne
souvislosti s tim
> predchozim (ostatne - kdo vi odkud prisel?).
Server to diky Session vi zcela bezpecne.
> Aby se zvysila efektivita,
> daji se nalezene vysledky ukladat do nejakeho cache
prostoru, aby se
> prace investovana do hledani dala recyklovat pri
pripadnych doplnujicich
> dotazech.
Ano, presne toto vyse popsany mechanizmus vlastne dela.
Ta cache jsou vlastne datove struktury v pameti obsahujici
predvyhledana data o spojeni.
>Z hlediska vykonnosti by asi bylo optimalni, aby trvale
bezel
> nejaky specializovany vyhledavaci server, ktery bude mit
zakladni datove
> struktury alokovany trvale, nebude se starat o WWW
zalezitosti a bude jen a
> jen hledat.
V podstate to tak je.
DLL tvori vyhledavaci server, na ktery se obraceji
scripty, ktere realizuji WWW rozhrani k IDOSu.
> Pokud datove struktury udrzujete pro uzivatele, podle
meho nazoru
> snizujete efektivitu, protoze podobny dotaz od jednoho
uzivatele nemuze
> vyuzivat datove struktury, vysledky a mezivysledky od
jineho.
Vyuziva je pri dohledani Nasl./Predch. spojeni
vyzadaneho stejnym uzivatelem.
> Navic zrejme
> data pro session udrzujete az do jejiho konce, cili vice
nez ctvrt hodiny
> potom, co uzivatel presel na jiny server (nebo klient
svuj odchod nejak
> ohlasi?).
Implicitni cas je 20 min. To je pro nase potreby
zbytecne dlouho -- aktualni nastaveni je 5 min.
Vzhledem k tomu, ze do Session v pameti serveru
se uklada jen nekolik cisel, neznamena to nijakou
dalsi zatez pro server, ani pametovou, ani vykonnostni.
Typicky je aktivnich max. nekolik set Sessions.
Nejvetsim problemem je "vytlacit" vsechna data
k uzivatelum. Server jede na vyhrazene lince
128 kb/s, ale datove toky dosahuji az 150 kb/s.
Rada paketu se musi zahazovat a opakovat.
Brzy bude premisten na vyhrazenou linku 256 kb/s.
Vykonostne se procesor poflakuje na 10% - 30%.
Pamet neni naalokovana ani vsechna fyzicka, ke
swapovani nedochazi.
> Opravdu si myslite, ze jste schopen klientovi zabranit v
tom, aby Vam
> poslal co chce? Klienta snadno vyrobim pomoci
> telnet pocitac 80
> a zadavam si dotaz, jaky se mi zlibi. Spis je potreba se
smirit s tim, ze
> musite kontrolovat vse, co Vam klient posle.
Jisteze vsechny vstupy jsou osetreny.
Data si kontroluje aplikace, Cookies ne,
protoze samotna aplikace s Cookies nepracuje.
Ta jsou soucasti mechanizmu vytvoreni stavu
v IIS ASP, proto si je zpracovava/osetruje
IIS ASP.
> Jiste, proc vymyslet zehlicku, kdyz mame parni valec.
> Mimochodem - jiste jste si vsiml, ze nemalo lidi (vcetne
mne - alespo na
> zaklade toho, co jsem se tu o nem zatim dozvedel) tu
povazuje za
> principialne nespravne prave to soucasne reseni.
Jestlize vyjdu z pouziti DLL, ktera vyzaduje
stav, nic jineho mi nezbyva, nez zavest stav
i do vyssi vrstvy - WWW scriptu.
> Ke zverejneni dat pro jizdni rady:
> Zvereneni dat ve formatu pro konkretni aplikaci je sice
lepsi nez nic, ale
> povazuji to jen za prvni krok. Myslim, ze by bylo velmi
vhodne zverejnit
> data ve vseobecne srozumitelnem formatu (vhodne
strukturovany textovy
> soubor). Alespon doufam, ze chcete, aby Internet prispel
k vetsimu
> vyuzivani sluzeb CD. Navic jde o jednorazovou praci -
vyrobit nejaky
> chroustac, ktery ze stavajici podoby jizdnich radu
(databaze?) vyrobi onu
> textovou. A ten pak uz jen spustit pri kazde zmene.
Navrhuji tento namet prednest napr. v diskusnim
foru CD, protoze jej ctou zodpovedni lide z CD,
kteri mohou o podobnych vecech rozhodovat.
> K susenkam obecne: Nechutnaji mi. Na serverech, ktere
navstevuji,
> nepotrebuji personalizaci. Nechci, aby si o mne nekdo
zjistoval, kudy
> susenky jiz cca rok vypnute a nevzpominam si, ze bych kdy
narazil na
> nejake fatalni potize. Pouze par serveru (spocital bych
je na prstech
> jedne ruky a shodou okolnosti oba pochazely z domeny .cz)
se mnou odmitlo
> komunikovat a rozesli jsme se jako pratele :-)
Obavam se, ze casem jich bude stale vice.
> Je to samozrejme trochu pretlacovana. Extremni kridlo
uzivatelu ma susenky
> vypnute a radeji ozeli server, nez by je zapnulo.
Extremni kridlo
> webmasteru vyrabi prave tyto "drsne" servery a radeji
ozeli uzivatele, nez
> by mu povolilo pristup bez susenek. Ted jde o to, kdo se
bude citit vice
> poskozen a kdo vydrzi dele. Mne se zatim bez susenek zije
docela dobre.
Vzhledem k tomu, ze Cookies jsou nedilnou soucasti
ASP a IIS a to je produkt MS a vsichni zname
marketingovy (a ostatne i obchodni) uspech teto firmy,
je mozne, ze dojde na moji opredchozi vetu.
> Preji vsem pekny den
>
> Pavel Satrapa Technical University of
Liberec
Taktez.
Vladislav Cerny
Vladislav Cerny
<1998072310...@ns.felk.cvut.cz>.
>
> Co ma co garance platnosti dat delat s utajovanim jejich
struktury.
>
> To je nekde stanoveno v predpisech, ze CD nesmi ta data
poskytnout,
> nebo ze aspon je musi poskytovat tak, aby z nich nebyl
zadny uzitek.
> Takovy predpis bych si rad precetl a rad bych videl, kdo
je pod nim
> podepsany.
>
> Jinak mi to pripada jako nejapna vymluva.
No placete sice hezky, ale na nespravnem hrobe.
Neznam predpisy CD ohledne jizdniho radu.
S dotazy tykajici se CD se musite obratit primo
na CD.
Ale muj dojem je, ze struktura dat nema nic spolecneho
s povinnosti zverejnovat jizdni rady. Samozrejme se mohu
mylit.
Vladislav Cerny
Michal Krsek
paklize jsem dobre pochopil cely problem se cookies a sessions, tak se obe
pouziva k tomu, aby mel clovek svuj vysledek rychleji.
Takze paklize si dovolim mit vlastni nazor, je na kazdem, aby se rozhodl,
vycka-li o nekolik (mili)sekund dele bez cookies nebo prijme cookies a
vysledek bude mit o nekolik (mili)sekund drive.
Pripadne z ruznych duvodu ten server vubec nepouzije (jezdi autobusem, nema
rad servery s cookies, nema rad Windows NT pripadne nema rad Microsoft, nema
Internet ani GSM a dalsi duvody).
Michal
P.S: Pro me je to jasny vysledek celeho problemu.
Martin Postulka
>From: "Vladislav Cerny" <bl...@datis.cdrail.cz>
>Organization: CD s.o. DATIS o.z. Plzen
>CD garantuje platnost dat a ta se pomerne casto meni.
>Naposledy ted ze So na Ne v noci.
>Jiny provozovatel by tuto garanci poskytnout nemohl
>a nabizel by neplatne informace.
ftp://ftp.cdrail.cz/IDOS_DATA/Cti.mne (zkracena citace)
>************************************************
>Dulezite upozorneni:
> CD se zprostuji odpovednosti uhrady ev. skod, ktere by >cestujicim
>mohly vzniknout v dusledku chybnych udaju poskytnutych JR IDOS.
>*************************************************
To je pochopitelne naprosto prirozena a obvykla soucast kazdeho
licencniho ujednani, ale co mely znamenat ty reci o nemoznosti
zprostredkovat garanci platnosti dat treti strane.
Snad by se dalo chapat, ze si CD stanovi podminky spoluprace,
ale takhle to vypada, ze kdyz nekdo nechce, je to horsi, nez kdyz
nemuze.
--
Martin....@cerge.cuni.cz CERGE-EI
network administrator P.O.Box 882
tel:(4202) 24230140 Politickych veznu 7
fax:(4202) 24211374 111 21 Praha 1
Martin Postulka
>Ale muj dojem je, ze struktura dat nema nic spolecneho
>s povinnosti zverejnovat jizdni rady.
Mate pravdu v tom, ze jsem do toho nemel plest predpisy,
ktere ani jedne neovladame. Ani ja jsem netvrdil, ze CD
ma povinnost zverejnit strukturu dat.
Proto ocituji z predchoziho prispeveku, abychom si rozumneli.
>Abych pravdu rekl, ja ten format take neznam.
>>Ale zkuste pozadavek uplatnit napr. u Ing. Rakusana,
>>rak...@datis.cdrail.cz (sedi o cca 120 km dale).
>>Je vsak temer jiste, ze Vam nevyhovi.
>>CD garantuje platnost dat a ta se pomerne casto meni.
>>Naposledy ted ze So na Ne v noci.
>>Jiny provozovatel by tuto garanci poskytnout nemohl
>>a nabizel by neplatne informace.
>Co ma co garance platnosti dat delat s utajovanim jejich struktury.
Muzete zduvodnit, proc se vam nehodi, aby se daty zabyval nekdo jiny.
Muzete rict, ze mi do toho nic neni.
Nemusite rikat vubec nic.
Ale vas argument o garanci dat (viz vyse) mi pri vsi snaze
neni vubec jasny.
Dekuji predem za vysvetleni.
Jan Yenya Kasprzak
: Browser. Ale Cookies neobsahuje zadna aplikacni
: data, neni je tedy treba na aplikacni urovni osetrovat.
: Navic Cookies nemuze prostym pouzivanim a
: manipulaci s okny uzivatel modifikovat, narozdil
: jiz drive mnou popsanem zpusobu ovlivneni platnosti
: dat predavanych browserem zpet serveru.
Tohle porad nechapu. Ten stav, co si ta DLL knihovna pamatuje,
slouzi k tomu, abych mohl rychle vyhledavat nasledujici/predchozi
spojeni, a mozna jeste k necemu dalsimu. Jak se to ale projevi, pokud
si pustim nove okno, v tom se nekam ve vyhledavani dostanu, a pak se
stejnym cookie v jinem okne pokracuji ve vyhledavani od puvodniho
mista? Pokud to je napsane spravne, tak by tam mela byt nejaka validace
"cookie" (nebo stav DLL knihovny) versus data ve formulari. A pokud by toto
bylo odlisne, musi se vytvorit nova "session". Nebo ne?
: Uschovavani dat na strane klienta (a to jsou metody
: INPUT HIDDEN, soucast URL nebo POST dat) je nespolehlive.
: Kdyz se server ulozi data sam u sebe a eviduje si,
: kteremu uzivateli patri je to spolehlivejsi.
: To evidenci si zajistuje prave pomoci Cookies, pomosi
: nichz s evytvari relace mezi browserem a serverem
: (Session).
Porad mluvime o tom stejnem. Server si _samozrejme_ bude sva data
pamatovat u sebe, a jako index do tech dat pouzije cookie (jak to doposud je)
nebo hidden polozku nebo cast URL. Jedna vec je, ze ASP object "Session()"
tohle neumi s nicim jinym nez s URL, a druha vec je, jestli tohle vubec
technicky jde. Podle me ano.
K dalsimu vasemu mailu:
: CD garantuje platnost dat a ta se pomerne casto meni.
: Naposledy ted ze So na Ne v noci.
Cemu tohle vadi? Neni prece problem zaridit si denni mirror
ftp.datis.cdrail.cz (nebo neceho podobneho) a data brat z IDOS.[1-3]
takto ozrcadleneho. Predpokladam, ze CD nezverejnuje zmeny presne ten den,
kdy vlaky zacnou skutecne jezdit jinak, nez je v minule verzi IDOS.[1-3].
-Yenya
--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/
Jan Yenya Kasprzak
: paklize jsem dobre pochopil cely problem se cookies a sessions, tak se obe
: pouziva k tomu, aby mel clovek svuj vysledek rychleji.
Ne. Debata je o tom, lze-li na miste cookies se stejnym vysledkem
pouzivat cast URL nebo hidden polozku ve formulari. A to zrejme nelze,
protoze IDOS je napsany v ASP nad IIS, ktery implementuje Session nad
cookies, i kdyz by to zrejme stejne dobre slo pomoci ostatnich dvou
metod (aspon zatim tady nepadl zadny argument o tom, proc by to neslo).
: Takze paklize si dovolim mit vlastni nazor, je na kazdem, aby se rozhodl,
: vycka-li o nekolik (mili)sekund dele bez cookies nebo prijme cookies a
: vysledek bude mit o nekolik (mili)sekund drive.
Bohuzel takhle ruzove to neni. Pokud nemate cookies, IDOS vubec
nevyhleda spojeni a nezmeni kodovani cestiny. Nejde o par milisekund,
ale o to, jestli vubec tu sluzbu dostanu, nebo ne. Pokud by slo
o par milisekund, a jeste ke vsemu na vrub serveru IDOSu, vubec by me to
nevzrusovalo.
Martin Mares
[Ac vim, ze pokracovanim v tomto threadu jeste vice zneprijemnuji zivot tem,
jez vubec nezajima, pokusim se alespon na vsechno reagovat najednou, takze
prosim omluvte, ze micham prispevky jednotlivych autoru.]
> To je tak akorat na FlameWar typu "Ktery OS je lepsi".
> Duvodu je vice, vcetne historickych. ASP poskytuje z hlediska vyvojare mnoho
> uzitecnych vlastnosti pro podobne aplikace jako stvorenych.
Ano, jako stvorenych, nicmene (coz je primarni tema teto debaty) implementovanych
IMNSHO dosti neprimerenym zpusobem.
[...]
> Abych pravdu rekl, ja ten format take neznam.
> Ale zkuste pozadavek uplatnit napr. u Ing. Rakusana,
> rak...@datis.cdrail.cz (sedi o cca 120 km dale).
> Je vsak temer jiste, ze Vam nevyhovi.
> CD garantuje platnost dat a ta se pomerne casto meni.
> Naposledy ted ze So na Ne v noci.
> Jiny provozovatel by tuto garanci poskytnout nemohl
> a nabizel by neplatne informace.
Jestlize CD zverejni sva data na verejnem FTP-serveru a budou je tam
aktualizovat, ostatni mohou tato data trivialne mirrorovat a tak se dozvidat
o vsech zmenach.
Co se garance platnosti dat tyce, mam jeste v zive pameti, kdyz jsem
na zacatku lonskeho cervence vyhledaval IDOSem spojeni z Prahy do Kralovic
u Rakovnika a dostal jsem odpoved, o ktere jsem o par hodin pozdeji zjistil,
ze ani jeden z vlaku, ze kterych se spojeni skladalo, neexistoval. Toto berte
nikoliv jako invektivu proti IDOSu, nybrz jako dukaz toho, ze zadne garance,
at jiz poskytovane kymkoliv, nemohou byt 100%ni.
> Sem s namety.
> Nikdo nevymysli nic idealne, uvitam namety na
> zlepseni IDOSu (vim, ze mame nektere rozdiskutovane).
Mym zakladnim nametem bylo zverejneni dat.
[...]
> Opravdu to nechapete.
> Nejde o Cookie. To je jen nastroj pro vytvoreni Session
> a Session vytvari stovove prostredi. Prectete si, proism,
> dokumentaci k ASP.
Nerad bych hodnotil, co znaji ostatni ucastnici teto konference, ale rekl bych,
ze toto jest zde vseobecne znamym faktem. Osobne bych spise doporucil studium
dokumentace od HTTP, zejmena pak RFC 2068 a RFC 2109, ktera podle meho nazoru
vrhaji dosti svetla na to, nakolik je diskutovane pecivo vhodne pouzivat.
> On ale nepada (protoze pouziva Cookies a Sessions :-) ).
> Pouze nekteri uzivatele maji problem, ze si vypnou Cookies,
> a pak si mysli, ze server pada.
Muj ciste subjektivni nazor (mozna zkresleny pouzitou `metodou mereni')
jest ze za posledni dva mesice byl IDOS dole vicekrat nez za predchozi rok
dohromady.
> > Podle meho nazoru jste stale neuvedl
> > duvod, proc by se tohle muselo delat pres cookies.
>
> No prece proto, ze v ASP je Session implementovana pomoci
> Cookies. Co je na tom, proboha, tak nepochopitelneho?
Otazku lze tedy preformulovat na "... proc by se tohle muselo delat
pres ASP sessions?".
[...]
> Kdyz Vam dam zdrojaky, tak uz toho moc programovat nemusite ne?
Pokud to budou zdrojaky knihovny na vyhledavani spojeni, pak je jeste
nutne napsat cely WWW interface...
> Ono je jedna vec mit silna slova a druha vec je pak podeprit
> nejakym cinem.
Pokud mi kdokoliv da budto zminovane zdrojaky nebo popis formatu dat, mile
rad je cinem podepru.
[...]
> Nevim, zda jste cetl cely thread.
> Vyhledavaci algoritmus je realizovan .DLL
> knihovnou.
[... smik, smik, smik, tisici a prvy popis knihovny bych jiz nerad citoval ...]
Ano, ja pouze mluvil o tom, ze tento zpusob interfacu vyhledavaciho serveru
je daleko mene vhodny pro prakticke pouziti nez cache zavisla na _kontextu_,
ktera sdili uchovavane informace mezi _vsemi_ uzivateli, coz ma principialne
vyssi efektivitu.
> Ano, presne toto vyse popsany mechanizmus vlastne dela.
> Ta cache jsou vlastne datove struktury v pameti obsahujici
> predvyhledana data o spojeni.
Ano, ale nevidim duvod, proc by tyto struktury nemohly byt asociovany
se samotnym _textem_ pozadavku misto se session, ke ktere patri.
> Navrhuji tento namet prednest napr. v diskusnim
> foru CD, protoze jej ctou zodpovedni lide z CD,
> kteri mohou o podobnych vecech rozhodovat.
Jiz se na tom pracuje...
[...]
> CD vydavaji zmeny jizdniho radu. Ty zmeny jsou pravidelne i nepravidelne
> (viz povodne) vydavane. Nekdo, samozrejme CD musi zajistit aktualnost
> databaze. A ted mi prosim reknete, jak by to zajistily v pripade, ze tady
> bude nejakych 5-10 serveru poskytujicich stejne sluzby na nezavisle
> (organizacni) platforme.
Viz mirroring zminovany vyse.
> Ja davam prednost tomu, aby tady byl jeden server.
Uvedomte si, ze pokud tu bude vice (slusne synchronizovanych!) serveru, bude
to daleko spolehlivejsi a lide, kteri budou potrebovat _rychle_ vyhledat nejake
spojeni si nebudou tak rvat vlasy, kdyz zrovna onen unikatni server nebude
pro ne pouzitelny (at jiz proto, ze zrovna spadl ci proto, ze provider,
na nejz jsou drazni servery pripojeny ma speficke nazory na peering a linka
do sveta mu zrovna spadla [nenarazim na konkretni situace]).
Have a nice fortnight
--
Martin `MJ' Mares <m...@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"In accord to UNIX philosophy, PERL gives you enough rope to hang yourself." -- Larry Wall
Pavel Satrapa
Ja mam pocit, ze Vy jste necetl (nebo nepochopil) ani cely muj dopis.
Snazil jsem se v nem naznacit, jak by to asi melo fungovat a ze stavajici
reseni neni prilis dobre, protoze nerespektuje logiku problemu. Kdyz
brutalne naroubujete jednouzivatelske reseni z MS DOS/Win do
viceuzivatelskeho Web serveru, tezko to dopadne dobre. Pak samozrejme
musite pracne vyrabet stavovost na urovni WWW a vyleze Vam reseni, ktere
je zbytecne slozite a navic neefektivni, protoze vysledky prace pro
jednoho uzivatele se nijak nezohlednuji pri praci pro uzivatele jineho.
Pri pristupu typu "datove struktury a algoritmy mne nezajimaji, ja tady
mam cernou skrinku (DLL), kterou zpristupnim z WWW" zkratka budete porad
zehlit tim parnim valcem.
Podle meho soudu by bylo potreba vyjit ze stavajicich hledacich algoritmu
v onom kouzelnem DLL, ale prepsat top-level podprogramy, ktere je
pouzivaji, aby respektovaly viceuzivatelske prostredi. To znamena
- pri hledani vychazet jen ze stanic a casu (pripadne dalsich informaci
typu s prestupem/bez prestupu apod.)
- sdilet vysledky (cache)
- zabranit redundancim (aby se paralelne nepocitalo totez pro ruzne
uzivatele)
Chapu, ze tento pristup je pracnejsi, nicmene porad si jeste myslim, ze
spravce serveru je tady od toho, aby poskytoval uzivatelum sluzby co
nejlepsi, nikoli takove, ktere daji nejmene prace.
A pokud se tyce zverejneni jizdnich radu: Jiz tady bylo nekolikrat receno,
ze to lze osetrit vhodnymi licencnimi podminkami. Ja si dokazi docela
dobre predstavit, ze zde vzniknou nejake alternativni servery s jizdnimi
rady CD a pokud se ukaze, ze nektery je podstatne lepsi nez ten stavajici,
CD se s nim mohou dohodnout a dat mu punc oficialniho serveru
jizdnich radu. Bude to vyhodne pro oba: CD usetri penize a onen
poskytovatel si zvysi prestiz a navstevnost.
> Vzhledem k tomu, ze Cookies jsou nedilnou soucasti
> ASP a IIS a to je produkt MS a vsichni zname
> marketingovy (a ostatne i obchodni) uspech teto firmy,
> je mozne, ze dojde na moji opredchozi vetu.
http://www.netcraft.com/Survey/ tomu moc nenasvedcuje. Nicmene problem
neni v tom, jaky SW pouzivate. Jde o to neprebirat nove technologie jen
proto, ze existuji a ze jsou nove a pripadne pohodlne pro spravce. Kdyz se
programuje aplikace takto vyznamneho dosahu, mela by se myslim jejimu
navrhu venovat adekvatni pece.
Preji vsem pekny vikend
!!! The phone and fax number has been changed !!!
----------------------------------------------------------------------
Pavel Satrapa Technical University of Liberec
E-Mail: Pavel....@vslib.cz Dept. of Information Technology
Phone: +420-48-535-2374 Halkova 6, 461 17 Liberec
Fax: +420-48-535-2229 Czech Republic
----------------------------------------------------------------------
Vladislav Cerny
vysledkem
> pouzivat cast URL nebo hidden polozku ve formulari. A to
zrejme nelze,
> protoze IDOS je napsany v ASP nad IIS, ktery implementuje
Session nad
> cookies, i kdyz by to zrejme stejne dobre slo pomoci
ostatnich dvou
> metod (aspon zatim tady nepadl zadny argument o tom, proc
by to neslo).
Myslim, ze vysvetleni, proc by to neslo, padlo.
Resp. ono by to slo, ale z principu by to jaksi
nebylo ono - ne vzdy by to fungovalo.
Musite vzdy uvazovat predem neznamy pocet soucasne
pristupujicich uzivatelu a predem neznamym poctem
soucasne otevrenych kopii okna prohlizece, ktere se
serveru jevi jako jedno.
> Bohuzel takhle ruzove to neni. Pokud nemate cookies,
IDOS vubec
> nevyhleda spojeni a nezmeni kodovani cestiny. Nejde o par
milisekund,
> ale o to, jestli vubec tu sluzbu dostanu, nebo ne. Pokud
by slo
> -Yenya
Ano, je to tak. Pokud nejsou povoleny Cookies,
dostane zobrazovaci script stejny neplatny pointer
na data jako v prip. ze spojeni nebylo nalezeno.
Vyhledavaci funkce nevraci zadna data o spojeni,
ale pouze pointer na datovou strukturu v pameti.
Ten se predava bezpecne (tj. pres Session,
takze ten pointer neopusti server) do
zobrazovaciho scriptu, ktery vola jine funkce vracejici
vlastni informace o spojeni na zaklade predaneho pointeru.
Neni mozne zadat predat pointer do browseru aby ten
jej nasledne vratil. Kazdy druhy stoural bude zkouset,
coto udela, bude-li tam posilat nahodne/zmenene hodnoty.
Vladislav Cerny
Vladislav Cerny
článku <35B732...@cerge.cuni.cz>…
> Vyhnul jste se odpovedi sice elegantne, ale vyhnul.
>
> >Ale muj dojem je, ze struktura dat nema nic spolecneho
> >s povinnosti zverejnovat jizdni rady.
Ano vyhnul, protoze kdyz o necem nevim,
tak o tom nemluvim a nepisu.
Jak jsem jiz napsal, tyto zalezitosti
(garance za data, povinnosti, ceny,
formaty apod.) neznam a soucasne jsme uvedl,
kam se obratit pro odpoved.
Ja se za Vas ptat nebudu.
> Muzete zduvodnit, proc se vam nehodi, aby se daty zabyval
nekdo jiny.
> Muzete rict, ze mi do toho nic neni.
> Nemusite rikat vubec nic.
Rikam (opet), ze to nevim a proto to nemohu
zduvodnit.
Zeptejte se jinde, urcite se Vam dostane
kvalifikovane odpovedi, proc na tom CD nema zajem.
Vladislav cerny
Vladislav Cerny
> > To je tak akorat na FlameWar typu "Ktery OS je lepsi".
> > Duvodu je vice, vcetne historickych. ASP poskytuje z
hlediska vyvojare mnoho
> > uzitecnych vlastnosti pro podobne aplikace jako
stvorenych.
>
> Ano, jako stvorenych, nicmene (coz je primarni tema
teto debaty) implementovanych
> IMNSHO dosti neprimerenym zpusobem.
Neodporuji.
> Co se garance platnosti dat tyce, mam jeste v zive
pameti, kdyz jsem
> na zacatku lonskeho cervence vyhledaval IDOSem spojeni z
Prahy do Kralovic
> u Rakovnika a dostal jsem odpoved, o ktere jsem o par
hodin pozdeji zjistil,
> ze ani jeden z vlaku, ze kterych se spojeni skladalo,
neexistoval. Toto berte
> nikoliv jako invektivu proti IDOSu, nybrz jako dukaz
toho, ze zadne garance,
> at jiz poskytovane kymkoliv, nemohou byt 100%ni.
Ono je mozne, vzhledem k zreknuti se zodpovednosti
za zpusobene skody, ze CD ty data negarantuje, nevim.
Opet na to by dokazal jednoznacne a odpovedne odpovedet
nekdo jiny.
> > Sem s namety.
> Mym zakladnim nametem bylo zverejneni dat.
Bohuzel k tomuto tematu s enemuho vyjadrit.
Zkusil jste jiz uplatnit Vas dotaz/pozadavek
na mnou uvedenych mistech/adresach, ktera
vedou k lidem schopnych odpovedi?
> ze toto jest zde vseobecne znamym faktem. Osobne bych
spise doporucil studium
> dokumentace od HTTP, zejmena pak RFC 2068 a RFC 2109,
ktera podle meho nazoru
> vrhaji dosti svetla na to, nakolik je diskutovane pecivo
vhodne pouzivat.
Z tohoto hlediska mate jiste pravdu.
Na druhe strane je plno jinych veci, ktere nejsou
zcela v souladu s RFC a jsou vice nez bezne
(treba CP1250 na Webech?).
Problem pak neni jen pouziti takovych technologii,
ale i respektovani RFC firmami, ktere masove poskytuji
nastroje primo na takto spornych technologiich postavene.
> > On ale nepada (protoze pouziva Cookies a Sessions :-)
).
> > Pouze nekteri uzivatele maji problem, ze si vypnou
Cookies,
> > a pak si mysli, ze server pada.
>
> Muj ciste subjektivni nazor (mozna zkresleny pouzitou
`metodou mereni')
> jest ze za posledni dva mesice byl IDOS dole vicekrat nez
za predchozi rok
> dohromady.
Ano, byl.
Mimo jine to bylo take hlavne proto,
ze Cookies a Session bylo nahrazeno
necim jinym, jiz zde doporucovanym.
> Otazku lze tedy preformulovat na "... proc by se tohle
muselo delat
> pres ASP sessions?".
Protoze to je v ASP nejvhodnejsi nastroj.
Ano, muzete ted namitnout "a proc by se to muselo
delat v ASP".
No vlastne nemuselo, ale je to tak jiz udelano.
K DLL knihovne je od treti firmy dodano i rozhrani
pro ASP.
Stavajici reseni vyhovuje vetsine uzivatelu, minimalne
tem, co pouzivaji IE nebo NN a nezakazou si Cookies.
Proc, kdyz jsou Cookies tak spatne, vznikaji vyvojove
nastroje, ktere je pouzivaji? Proc je podporuji WWW
servery? Proc je podporuji browsery?
> Pokud to budou zdrojaky knihovny na vyhledavani
spojeni, pak je jeste
> nutne napsat cely WWW interface...
Zdroje od te DLL nema ani CD.
Zkuste pozadat nejakou SW firmu, at Vam jen tak
poskytne zdrojove texty. Asi s Vama vybehnou.
Proc tedy tak suverene zadate, aby zdrojove texty
poskytlo CD?
> Pokud mi kdokoliv da budto zminovane zdrojaky nebo
popis formatu dat, mile
> rad je cinem podepru.
Se zdrojakama to vidim zcela nepruchodne.
Spis mozna, mozna format dat. Uz jste se
nekdo zkusil zeptat?
> Ano, ale nevidim duvod, proc by tyto struktury nemohly
byt asociovany
> se samotnym _textem_ pozadavku misto se session, ke ktere
patri.
Protoze pozadavku, vzhledem k mnozstvi a poctu
hodnot, kterych mohou vstupni parametry nabyvat,
je temer nekonecne mnozstvi.
Neni mozne vygenerovat do pameti/na disk nebo
kamkoli vsechny mozne dotazy (bud v predstihu,
nebo prubezne) a pak v nich lovit opetovne
pozadovany.
> > Navrhuji tento namet prednest napr. v diskusnim
> > foru CD, protoze jej ctou zodpovedni lide z CD,
> > kteri mohou o podobnych vecech rozhodovat.
>
> Jiz se na tom pracuje...
No konecne. Alespon opustime rovinu
dohadu a neznalosti problematiky na obou
stranach. Sam jsme zvedav na dalsi vyvoj.
Vladislav Cerny
Petr Nachtmann
Petr Nachtmann
> ).
> > > Pouze nekteri uzivatele maji problem, ze si vypnou
> Cookies,
> > > a pak si mysli, ze server pada.
Porad me nikdo nepresvedcil, ze je nutne pro ucely vyhledavani doplnovat
do bezestavoveho HTTP nejakou stavovost. Je hezke drzet si v pameti
mezivysledky, ktere se mohou hodit pozdeji, ale koneckoncu tyto vysledky
mohou byt uzitecne i pri zpracovani dotazu od uplne jineho uzivatele.
Problem vidim v tom, ze IDOS je pro CD cernou skrinkou
(jednouzivatelskou!) a ze CD simuluji windowsi GUI pomoci ASP.
Na druhou stranu algoritmy typu "najdi nejkratsi trasu" jsou IMHO
vseobecne zname (metoda kriticke cesty?), takze by stacilo zverejnit data
IDOSu a jejich format.
> > Muj ciste subjektivni nazor (mozna zkresleny pouzitou
> `metodou mereni')
> > jest ze za posledni dva mesice byl IDOS dole vicekrat nez
> za predchozi rok
> > dohromady.
>
> Ano, byl.
> Mimo jine to bylo take hlavne proto,
> ze Cookies a Session bylo nahrazeno
> necim jinym, jiz zde doporucovanym.
Ale bylo to zrejme nahrazeno nejakym ne zcela idealnim zpusobem. Neni
prece mozne, aby server bylo mozno sestrelit nespravnym URL.
Udrzovat session musi internetovy obchod, Hotmail apod.
Vyhledavaci sluzba (at uz vyhledava vlaky, e-mailove adresy lidi nebo
neco jineho) session udrzovat nemusi. Proto treba AltaVista prenasi
vstupni parametry dalsi stranky vysledku pres URL. Nektere jine servery
tak cini pomoci metody POST aktivovane tlacitkem.
> > Otazku lze tedy preformulovat na "... proc by se tohle
> muselo delat
> > pres ASP sessions?".
>
> Protoze to je v ASP nejvhodnejsi nastroj.
> Ano, muzete ted namitnout "a proc by se to muselo
> delat v ASP".
ASP snad apriorne _nevyzaduje_ sessions?
> No vlastne nemuselo, ale je to tak jiz udelano.
> K DLL knihovne je od treti firmy dodano i rozhrani
> pro ASP.
> Stavajici reseni vyhovuje vetsine uzivatelu, minimalne
> tem, co pouzivaji IE nebo NN a nezakazou si Cookies.
>
> Proc, kdyz jsou Cookies tak spatne, vznikaji vyvojove
> nastroje, ktere je pouzivaji? Proc je podporuji WWW
> servery? Proc je podporuji browsery?
V nekterych pripadech jsou cookies uzitecne (treba pri vyuzivani Hotmailu
z AOL - u AOL se dynamicky meni IP adresa uzivatele, coz bez cookies
vedlo k chybove hlasce "Intrusion detected").
Ale cookies v IDOSu mi pripominaji uzivani sroubovaku misto dlata.
> > Pokud to budou zdrojaky knihovny na vyhledavani
> spojeni, pak je jeste
> > nutne napsat cely WWW interface...
>
> Zdroje od te DLL nema ani CD.
Neni to chyba? V tom pripade vlastne nemohou CD zarucit spravnost
vlastnich vysledku vyhledanych v IDOSu bezicim na nadrazi.
PN
Jan Yenya Kasprzak
zaver (za slova "nekolik minut experimentu"), zjisti tam, ze IDOS
nefunguje ani s cookies. ]
"Vladislav Cerny" <bl...@datis.cdrail.cz> napsal:
: Bohuzel k tomuto tematu s enemuho vyjadrit.
: Zkusil jste jiz uplatnit Vas dotaz/pozadavek
: na mnou uvedenych mistech/adresach, ktera
: vedou k lidem schopnych odpovedi?
Pracujeme na tom - uvidime, ceho se dockame.
[...]
: Na druhe strane je plno jinych veci, ktere nejsou
: zcela v souladu s RFC a jsou vice nez bezne
: (treba CP1250 na Webech?).
I Microsoft sam od CP1250 ustupuje - napriklad v Polsku s timto
kodovanim neprorazili. Je-li neco spatne nebo nestandardni a pouziva
se to, at si to lide pouzivaji. Ale at po me nechteji, abych tvrdil,
ze je to tak spravne.
: 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).
Perl a CGI snad mate i na NT.
: Stavajici reseni vyhovuje vetsine uzivatelu, minimalne
: tem, co pouzivaji IE nebo NN a nezakazou si Cookies.
Dalsi z argumentu, na ktery se dalo jiz delsi dobu
cekat. Pouzivame urcite rozsireni standardu, a ti, kteri toto
rozsireni nemaji, nas nezajimaji. Stejne je jich mensina. Ach jo.
Ale kdyby to aspon neslo udelat jinak, jenze ono to jde, jen vy
(nebo ASP) to nechcete/neumite.
: Proc, kdyz jsou Cookies tak spatne, vznikaji vyvojove
: nastroje, ktere je pouzivaji? Proc je podporuji WWW
: servery? Proc je podporuji browsery?
Protoze v nekterych konkretnich typech aplikaci se bez cookies
neobejdete (coz je pripad tech cookies, ktere trvaji delsi dobu).
Tohle ale neni pripad IDOSu ani volby kodovani cestiny. Zde se bez
cookies obejit lze.
:
: Zdroje od te DLL nema ani CD.
: Zkuste pozadat nejakou SW firmu, at Vam jen tak
: poskytne zdrojove texty. Asi s Vama vybehnou.
: Proc tedy tak suverene zadate, aby zdrojove texty
: poskytlo CD?
Proc ne, kdyz zdrojove texty poskytuje i takove firmy
jako Netscape nebo SunSoft (ta druha s urcitymi omezenimi) ...
: Se zdrojakama to vidim zcela nepruchodne.
: Spis mozna, mozna format dat. Uz jste se
: nekdo zkusil zeptat?
:
Ano. Uvidime, co dostaneme za odpoved.
>> Ano, ale nevidim duvod, proc by tyto struktury nemohly byt asociovany
>> se samotnym _textem_ pozadavku misto se session, ke ktere patri.
:
: Protoze pozadavku, vzhledem k mnozstvi a poctu
: hodnot, kterych mohou vstupni parametry nabyvat,
: je temer nekonecne mnozstvi.
: Neni mozne vygenerovat do pameti/na disk nebo
: kamkoli vsechny mozne dotazy (bud v predstihu,
: nebo prubezne) a pak v nich lovit opetovne
: pozadovany.
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.
Stejne porad nechapu, jak resite situaci, kdy si uprostred
vyhledavani otevru nove okno a vyhledavam v nem uplne jine spoje.
Pak jde cely efekt session do kytek, ne? Zatimco pokud by "session"
byla ve forme cache nekolika (treba i nekolika stovek) posledne vyhledavanych
pozadavku, cela vec by fungovala.
Jak to tedy funguje, pokud vyhledavam v jednom okne spojeni
z Prahy do Bratislavy a ve druhem z Brna do Koprivnice?
[... nekolik minut experimentu ...]
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.
Preji prijemny vikend,
-Yenya
PS.: Pokud uz zalamujete text, ktery citujete, dejte take pred kazdy
zalomeny radek prislusny pocet znaku ">" nebo ":", at lze odlisit
citovany text od vami psaneho.
Antonín Foller
> 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_.
Opravdu by bylo dobre zjistit si, _co_ je to vlastne session a proc ji
ma _kazdy_ browser implementovanou (nebo znate takovy browser, ktery session
nema?) a jak funguje. A ze uz ji neni potreba implementovat pomoci URL, kdyz
uz ji vsechny browsery maji.
A ze by ji slo jen stezi implementovat pomoci URL a uz vubec ne pomoci
hidden polozky (Zkuste dat hidden polozku treba do GIF obrazku, chtel bych
na to videt priklad :-)))).
>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.
Tohle je pravda a presne takhle session funguji u vsech browseru.
Myslim, ze je to hezka chyba IDOSu.
Hezky den preje
Antonin Foller
Přibáň
unixovych teoretiku a drzim palce.
Cizi programy se krasne kritizuji...
Zdravi Pavel z Plzne.
Vladislav Cerny píše ve zprávě <01bdb6f4$0b769c40$1a090c0a@CIT0000PLZ00026>…
Hynek Med
[IDOS down]
> Ano, byl.
> Mimo jine to bylo take hlavne proto,
> ze Cookies a Session bylo nahrazeno
> necim jinym, jiz zde doporucovanym.
Ja to nechapu. Bahn.hafas.de je bezpochyby mnohem lepsi aplikace (umi toho
vic, ma vetsi databazi a podle meho dojmu je i rychlejsi). Navic je mozna
dokonce take postavena na Windows/NT, na coz usuzuju z toho, ze v URL jsou
.exe, i kdyz server je Apache, coz mne ponekud mate -- mozna nejaky
passthrough? Kazdopadne ASP ani Cookies nepouziva a vubec (posle mych
zkusenosti) nepada, ackoliv zjevne obsluhuje vic pozadavku. Tak v cem je
problem?
> Proc, kdyz jsou Cookies tak spatne, vznikaji vyvojove
> nastroje, ktere je pouzivaji? Proc je podporuji WWW
> servery? Proc je podporuji browsery?
Proc, kdyz Windows 95 pomerne casto padaji, si je tolik lidi kupuje? Proc
lidi vrazdi, kdyz je to nespravne? Takoveto otazky bohuzel nemaji smysl.
> Zdroje od te DLL nema ani CD.
> Zkuste pozadat nejakou SW firmu, at Vam jen tak
> poskytne zdrojove texty. Asi s Vama vybehnou.
> Proc tedy tak suverene zadate, aby zdrojove texty
> poskytlo CD?
Trendy se meni. Software, ke kteremu se dodavaji i zdrojaky je stale vic,
a je v sirsi mire pouzivan. Podivejte se na Netscape, nebo na ruzne
projekty podporovane IBM (napr. Vmailer -- www.vmailer.org).
> Protoze pozadavku, vzhledem k mnozstvi a poctu
> hodnot, kterych mohou vstupni parametry nabyvat,
> je temer nekonecne mnozstvi.
> Neni mozne vygenerovat do pameti/na disk nebo
> kamkoli vsechny mozne dotazy (bud v predstihu,
> nebo prubezne) a pak v nich lovit opetovne
> pozadovany.
Ale je mozne cachovat samotne odpovedi na dotazy.. Tim mimochodem zvysite
efektivitu zpracovani, protoze kdyz Manicka i Hurvinek z prikladu Pavla
Satrapy hledaji totez spojeni, jeden z nich dostane odpoved rychleji, nez
pri pouziti systemu se Sessions.
Na druhou stranu, aby to vsechno nevyznelo tak negativne -- chapu, ze
zaplatovat stary system se muze zdat lepsi nez se snazit vybudouvat system
novy..
Hynek
Pavel Kolesnikov
: Ja to nechapu. Bahn.hafas.de je bezpochyby mnohem lepsi aplikace (umi toho
: vic, ma vetsi databazi a podle meho dojmu je i rychlejsi). Navic je mozna
: dokonce take postavena na Windows/NT, na coz usuzuju z toho, ze v URL jsou
trosku off-topic poznamka:
$ telnet Bahn.hafas.de 23
Trying 194.77.20.23...
Connected to Bahn.hafas.de.
Escape character is '^]'.
Linux 2.0.29 (www1.hacon.de) (ttyp0)
www1 login:
telnet> Connection closed.
takze NT asi ne :)
krome toho ten Apache je 1.2.4, ale Apache pod windows
az v rade 1.3.x
pavel
Hynek Med
> I Microsoft sam od CP1250 ustupuje - napriklad v Polsku s timto
> kodovanim neprorazili. Je-li neco spatne nebo nestandardni a pouziva
> se to, at si to lide pouzivaji. Ale at po me nechteji, abych tvrdil,
> ze je to tak spravne.
Mimochodem, ve zminenem Polsku centralni news server pro skupiny pl.*
prispevky ve znakove sade CP1250 automaticky canceluje. Podobna situace je
v ostatnich vychodoevropskych zemich..
Hynek
Vladislav Cerny
<1998072413...@ns.felk.cvut.cz>…
> Na druhou stranu algoritmy typu "najdi nejkratsi trasu"
jsou IMHO
> vseobecne zname (metoda kriticke cesty?), takze by
stacilo zverejnit data
> IDOSu a jejich format.
No obavam se, ze vyhledavani vlak. spojeni
je o necem jinem, nez hledani nejkratsi cesty
v grafu. Ne uplne jine, ale slozitejsi.
Ono takove nejkratsi spojeni s 8 prestupy
a cekacima dobama na prestupech delsima
nez vlastni jizda je neco jineho, nez rychle
spojeni pomoci jednohoprestupu, ktere ale
neni nejkratsi cestou.
> Vyhledavaci sluzba (at uz vyhledava vlaky, e-mailove
adresy lidi nebo
> neco jineho) session udrzovat nemusi. Proto treba
AltaVista prenasi
> vstupni parametry dalsi stranky vysledku pres URL.
Nektere jine servery
> tak cini pomoci metody POST aktivovane tlacitkem.
Tim parametrem ale neni pointer do pameti.
> > Zdroje od te DLL nema ani CD.
>
> Neni to chyba? V tom pripade vlastne nemohou CD zarucit
spravnost
> vlastnich vysledku vyhledanych v IDOSu bezicim na
nadrazi.
Nevim, co preswne CD zarucuje.
Nicmene jsou tady i smluvni zavazky.
(Jste SW firma? Zkusili jste prodat neco
nefungujiciho? Co na to zakaznik?)
Jiste je v zajmu one treri firmy, aby algoritmy
hledali spravne.
VC
Vladislav Cerny
<s32ap6.1h.ln@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?
>
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
Vladislav Cerny
Neberu to jako boj, ale jako osvetu.
S pozdravem
Vladislav Cerny
Přibáň <otz...@mvcr.cz> píąe v článku
<6pbvn5$7...@news.mvcr.cz>.
Pavel Kolesnikov
: 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.
V predchozich prispevcich jste nejak vyslovoval (ano, porad dokola)
imho zahadnou tezi o shazovani serveru v dusledku prace s neplatnym
pointerem, nijak z toho nevyplynulo, proc bezpecnejsi identifikator
sessny predavat v cookie ASPSESSIONID ci jak se jmenuje nebo uplne
tentyz retezec predavat jako soucast URL?
:> Perl a CGI snad mate i na NT.
Tohle byl vazne trosku ulet :)
: 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:
Asi jste necetl pozorne, nebyla rec o shazovani IDOSu, ale
o jeho funkcnosti.
Podivejte, ja nemam nic proti cookies, davaji programatorovi
pomerne silny nastroj jak uchovavat informace o uzivateli, ale
pokud je pouzijete tak, ze mi v jejich dusledku aplikace podava
spatne vysledky, tak pravdepodobne nejsou pouzity vhodnym zpusobem.
A jestli pri hledani spojeni z A do B dostanu spojeni z C do D jen
proto, ze jsem ho mezitim vyhledaval v jinem okne, tak to za spravny
vysledek povazovat nemohu).
: Autor prave proti sve vuli dokazal, ze implementovane
: Session perfektne funguji a vse se chova tak, jak je ocekavano.
Autor dokazal, ze implementovane sessions funguji tak, jak
popisujete, ale bohuzel nikoli tak, jak by vyhovovalo uzivateli.
Proste znemoznuje ve dvou oknech prohlizece dohledavat dalsi/predchozi
spojeni u dvou ruznych trati. Ne kazdy clovek je zvykly pracovat
takhle multitaskove, ale je to rozhodne malinke minus.
: Kdyby to bylo udelano pomoci HIDDEN nebo
: pres cast URL, predal byste neplatny pointer
: a server by byl pravdepodobne jiz shozen.
Uz zase neplatny pointer :) - predpokladam, ze ona ASP cookie
neobsahuje zadny pointer (tudiz jejim falsovanim server
neshodim). Je problem tentyz retezec predavat jinak nez
prostrednictvim cookies?
Pavel
Petr Nachtmann
> je o necem jinem, nez hledani nejkratsi cesty
> v grafu. Ne uplne jine, ale slozitejsi.
>
> Ono takove nejkratsi spojeni s 8 prestupy
> a cekacima dobama na prestupech delsima
> nez vlastni jizda je neco jineho, nez rychle
> spojeni pomoci jednohoprestupu, ktere ale
> neni nejkratsi cestou.
Samozrejme, soucasti nejkratsiho spojeni je i doba stravena prestupy atd.,
ale to uz je myslim vyreseno.
> > Vyhledavaci sluzba (at uz vyhledava vlaky, e-mailove
> adresy lidi nebo
> > neco jineho) session udrzovat nemusi. Proto treba
> AltaVista prenasi
> > vstupni parametry dalsi stranky vysledku pres URL.
> Nektere jine servery
> > tak cini pomoci metody POST aktivovane tlacitkem.
>
> Tim parametrem ale neni pointer do pameti.
Coz je jedine dobre.
BTW, na stanici metra Muzeum je pocitac s dotykovou obrazovkou, ktery
hleda nejlepsi spojeni v ramci prazske MHD. Nevim, jak to ten program
dela, ale hledani je dabelsky rychle. Videl jsem predtim obdobny
komercni program na VSE, pocital hodne pomalu. Takze nezavisly prohledavac
jizdnich radu by urcite neuskodil.
PN
Petr Nachtmann
> : Se Sessoin v ASP je to velmi bezpecne, jinak
> : to je velme nebezpecne. Viz texty
> : v predchozich prispevcich.
>
> V predchozich prispevcich jste nejak vyslovoval (ano, porad dokola)
> imho zahadnou tezi o shazovani serveru v dusledku prace s neplatnym
> pointerem, nijak z toho nevyplynulo, proc bezpecnejsi identifikator
> sessny predavat v cookie ASPSESSIONID ci jak se jmenuje nebo uplne
> tentyz retezec predavat jako soucast URL?
Me by to taky zajimalo.
> :> Perl a CGI snad mate i na NT.
>
> Tohle byl vazne trosku ulet :)
IMHO existuje (komewrcni) implementace Perlu pro NT, ktera skrtipty
zkompiluje, takze to bezi lepe a radostneji.
PN
dex...@deltax.cz
navrhuji diskusi ukoncit s nasledujicimi zavery:
1. Nejruznejsi implementace maji svoje vyhody a nevyhody, proprietary a
stavova reseni vzdy omezuji komunitu uzivatelu.
2. Zvolena implementace byla programatorsky nejjednodussi za tu cenu, ze se
nekdo muze citit ohrozen
3. Zverejneni dat je mimo kompetence diskutujicich. CD by to udelat mohly,
ale je to vec jejich uvahy, zda v takovem pripade vice vydelaji na jizdnem,
nebo v obracenem svou pritomnosti na Inetu. Treba by tim mohla byt mensi ta
dotace ;) . Pokud se nekomu podari zjistit stanovisko CD, doufam, ze to
napise do konference.
4. Je otazka, kdo by zaplatil novy vyvoj tak, aby to bylo krasnejsi.
Jelikoz SW (zrejme) pise komercni firma, je otazka kdo to zaplati vzdy az
ta prvni.
Ucastnikum vasnivych debat navrhuji, aby mi vynadali na moji adresu a
neobtezovali ostatni ucastniky konference 50 prispevky denne, zvlast kdyz
se opakuji.
David Exner
dex...@deltax.cz
DELTAX Systems, a.s., Na Pankraci 30, 140 00 Praha 4, Czech Republic
tel. +420-2-61001214, fax +420-2-61001222
Vladislav Cerny
<6phpdp$ju5$1...@rhino.cis.vutbr.cz>…
> Vladislav Cerny <bl...@datis.cdrail.cz> wrote:
> : Autor prave proti sve vuli dokazal, ze implementovane
> : Session perfektne funguji a vse se chova tak, jak je
ocekavano.
>
> Autor dokazal, ze implementovane sessions funguji tak,
jak
> popisujete, ale bohuzel nikoli tak, jak by vyhovovalo
uzivateli.
> Proste znemoznuje ve dvou oknech prohlizece dohledavat
dalsi/predchozi
> spojeni u dvou ruznych trati. Ne kazdy clovek je zvykly
pracovat
> takhle multitaskove, ale je to rozhodne malinke minus.
Je to tak implementovano.
Jestli to je prirozene, nebo neni,
je vec nazoru. Dve ruzne instance (okna)
prohlizece jsou jakoby dva ruzni uzivatele
a tam lze kombinovat prohledavani libovolne.
Dve okna tehoz prohlizece se proste jevi jako
jeden uzivatel a pak se nerozlisuje, do
ktereho okna dostane vysledek -- to je v moci
uzivatele, jak s nimy nalozi.
Jinak jsou nesmyslna tvrzeni, ze to ukazuje,
ze IDOS neni udelan multiuzivatelsky. Zkuste
kritizivaneho jevu dosahnout se skutecne dvema
(vice) uzivateli -- tedy ze dvou ruznych stroju.
Ono staci dva spustene prohlizece na jednom stroji.
Ale dve okna jednoho prohlizece proste nejsou
dva ruzni uzivatele. To je treba si uvedomit.
Pokud uzivatel neni zvykly pracovat multitaskove,
jak pisete (a zrejme tim myslite, ze si otevre nove
okno tehoz prohlizece misto noveho spusteni tehoz),
pak skutecne nepracuje multitaskove a vysledek
tomu odpovida. To je zcela korektni chovani Cookies,
Session, ASP, IDOSu, OS, klienta, serveru, vseho,
jinak by vznikl chaos.
Samozrejme, pokud by IDOS nepracoval se Session,
pak by se to chovalo, jak byste si pral.
> Uz zase neplatny pointer :) - predpokladam, ze ona ASP
cookie
> neobsahuje zadny pointer (tudiz jejim falsovanim server
> neshodim). Je problem tentyz retezec predavat jinak nez
> prostrednictvim cookies?
Ano, Cookie od ASP obsahuje jen ID Session,
zadna jina data aplikace.
Predavat nejake podobne ID jinak, nez pres
Cookies problem neni, ale proc to delat jinak,
kdyz tento mechanizmus je jiz soucasti ASP
a pracuje zcela transparentne i pro vyvojare.
Pouzil jsme to (a ta treti firma), protoze je
to dano v ASP k dispozici.
Mozna toto je ten pravy dotaz a odpoved, po
ktere se to stale vola. Ja odpovidal vzdy na
to, proc neni vhodne _data_ aplikace (pointer)
predavat jinak.
Domahali-li se ostatni odpovedi na Vami polozenou
otazku, pak se omlouvam, ze jsme ji vcas nepochopil
a odpovidal na neco jineho.
Snad tedy ostatni uspokoji odpoved, ze IDOS
pouziva Cookies pro uchovani Session ID, protoze
je s tim v ASP pocitano, je to tam pro tuto potrebu
a neni to nutne programovat, MS to dal takto
k dispozici, protoze tim uspokojil potrebu rady
aplikaci (vyvojaru) na Webu a pouzili jsme to
i my.
Vladislav Cerny
Vladislav Cerny
> BTW, na stanici metra Muzeum je pocitac s dotykovou
obrazovkou, ktery
> hleda nejlepsi spojeni v ramci prazske MHD. Nevim, jak to
ten program
> dela, ale hledani je dabelsky rychle. Videl jsem predtim
obdobny
> komercni program na VSE, pocital hodne pomalu. Takze
nezavisly prohledavac
> jizdnich radu by urcite neuskodil.
OnIDOS na WWW je take rychly. Jakekoliv spojeni
nalezne bezne za 0.3 s, max. do 1 sec.
Cekani u prohlizece, ktere vypada na to, ze server
je liny, je zpusobeno cekanim na protlaceni dat.
A to jeste navoleno pouziti slozitejsiho
(a tim kvalitnejsiho) algoritmu vyhledavani.
Vladislav Cerny
Pavel Kolesnikov
: Je to tak implementovano.
: Jestli to je prirozene, nebo neni,
: je vec nazoru.
Prominte, ale v dusledku teto implementace
uzivatel muze obdrzet data naprosto neodpovidajici
odeslanemu pozadavku.
: Pokud uzivatel neni zvykly pracovat multitaskove,
: jak pisete (a zrejme tim myslite, ze si otevre nove
: okno tehoz prohlizece misto noveho spusteni tehoz),
Omlouvam se za nejasnost - tu "multitaskovost" jsem
myslel pouze ve smyslu vykonavat vice cinosti najednou -
napriklad vyhledavani dvou ruznych spojeni zaroven.
(a protoze tohle clovek obvykle nedela, tak na Yenyou
popsany jev obvykle nenarazi).
: Samozrejme, pokud by IDOS nepracoval se Session,
: pak by se to chovalo, jak byste si pral.
Ale ne, at si pracuje se sessions, ale tento priklad
byl krasnou ukazkou toho, ze u vyhledavani spojeni
by bylo rozumne vazat session nikoli s uzivatelem,
ale pouze s jednim oknem prohlizece - jinymi slovy
nepredavat ID session pomoci cookie, ale jako
soucast URL ci jako hidden polozku.
: Predavat nejake podobne ID jinak, nez pres
: Cookies problem neni, ale proc to delat jinak,
: kdyz tento mechanizmus je jiz soucasti ASP
: a pracuje zcela transparentne i pro vyvojare.
Prave onen priklad s dvemi okny mi prijde rozumny
duvod, proc si dat neco prace navic a delat to
jinak.
Pavel
Vladislav Cerny
<1998072712...@ns.felk.cvut.cz>…
> Vazeni,
> navrhuji diskusi ukoncit s nasledujicimi zavery:
> 1. Nejruznejsi implementace maji svoje vyhody a nevyhody,
proprietary a
> stavova reseni vzdy omezuji komunitu uzivatelu.
> 2. Zvolena implementace byla programatorsky nejjednodussi
za tu cenu, ze se
> nekdo muze citit ohrozen
> 3. Zverejneni dat je mimo kompetence diskutujicich. CD by
to udelat mohly,
> ale je to vec jejich uvahy, zda v takovem pripade vice
vydelaji na jizdnem,
> nebo v obracenem svou pritomnosti na Inetu. Treba by tim
mohla byt mensi ta
> dotace ;) . Pokud se nekomu podari zjistit stanovisko CD,
doufam, ze to
> napise do konference.
> 4. Je otazka, kdo by zaplatil novy vyvoj tak, aby to bylo
krasnejsi.
> Jelikoz SW (zrejme) pise komercni firma, je otazka kdo to
zaplati vzdy az
> ta prvni.
>
> dex...@deltax.cz
Za svoji osobu souhlasim ve vsech bodech.
Vladislav Cerny
Bohumil Chalupa
On Mon, 27 Jul 1998, Vladislav Cerny wrote:
> > Na druhou stranu algoritmy typu "najdi nejkratsi trasu" jsou IMHO
> > vseobecne zname (metoda kriticke cesty?), takze by stacilo zverejnit data
> > IDOSu a jejich format.
>
> No obavam se, ze vyhledavani vlak. spojeni
> je o necem jinem, nez hledani nejkratsi cesty
> v grafu. Ne uplne jine, ale slozitejsi.
>
> Ono takove nejkratsi spojeni s 8 prestupy
> a cekacima dobama na prestupech delsima
> nez vlastni jizda je neco jineho, nez rychle
> spojeni pomoci jednohoprestupu, ktere ale
> neni nejkratsi cestou.
Zkousel jste uz nekdo porovnavat spojeni vyhledana idosem a hafasem?
Zkuste najit spojeni v sobotu 1. 8. od sedmi rano z Prahy do Telc~e.
Kazdy vam vrati neco jineho. Pri te prilezitosti mi doslo, ze
s inovaci IDOSu se nekam vytratila moznost zvolit kratsi cestu
s vetsim poctem prestupu. Na hafasu jsem ovsem nic podobneho
take nenasel. Na tomto konkretnim spojeni je to totiz zajimave,
protoze jedno z tech spojeni se lisi mezi temi dvema vyhledavaci
tim, ze jednim zajedete az do Veseli nad Luznici, kdezto druhym
si za cenu jednoho prestupu navic cestu ponekud zkratite (na km
a tedy i Kc). Cas je stejny, vyjizdite a dojizdite totiz stejnym
vlakem. (Hadejte, ktery hledac najde tu kratsi cestu?)
To je spojeni v 7:13 (fuj, to je brzo).
Dalsi spojeni behem dne najde pak kazdy server uplne jina.
Mozna by byla zajimava ruzna kriteria (metriky :-) ) pro urcovani
"nejlepsiho spojeni":
- pocet prestupu presneji nez jen primo x s prestupem,
- cas jizdy (straveny ve vlaku),
- celkova doba cesty (vcetne cekani na prestup),
- vzdalenost v km (to je skoro cena, ale ne presne - viz dale),
- cena jizdenky vcetne priplatku za priplatkove vlaky.
Na hafasu mi chybi kilometry. Aspon jsem je nenasel.
Zdravi
Bohumil Chalupa