Obsluha relací u klienta nebo na serveru

[mikesznovu]

Co se myslí server-side - v následujicim kontextu?

client side (cookies) session handling
server-side session handling


Je to JWT potažmo tokeny? Pokud ano, proč jedno je  s přídomkem client a druhé server? I nacookies se dá definovat že je server based (musí mít server někde uloženy asociace »phpsessid« hodnot). (Analogie: amerika taky na gløbusu může být východ a sssr západ) 


(Mimochodem je nějak signifikantní  rozdíl v požití mezery v prvním a pomlčky v druhym?)

[Reklama]

[RDa]

Session musi udrzovat obe strany aby davala smysl.

Nechapu ze to nechapes.

[mikesznovu]

Aha,omlouvám se za nedoruzmění, vzniklo zestručněním.

Platí buď a nebo. "

Dřív to fungovalo  na způsob client side (cookies) session handling .
 Nová verze změnila session handling na
server-side session handling"

[Filip Jirsák]

Kdybyste napsal, odkud ten text kopírujete, nemuseli bychom to hádat.

Obecně platí, že stav může udržovat klient, a pak musí serveru poslat s každým požadavkem alespoň tu část stavu, který server bude potřebovat. Tohle řeší třeba JWT. Nebo stav může udržovat server, a pak klient musí udržovat nějakou identifikaci stavu a tu posílat s každým požadavkem – k tomu se používá třeba cookie se session ID.

[František Ryšánek]

... Nebo stav může udržovat server, a pak klient musí udržovat nějakou identifikaci stavu a tu posílat s každým požadavkem – k tomu se používá třeba cookie se session ID.

Stává se velmi zřídka, že chytám za slovo a opravuju místního mazáka, a dělám to nerad :-)
Tady bych si tipnul, že když nějaký komplexní stav je udržován serverem, tak klient musí pouze identifikovat sebe, klidně anonymně nějakým číslem nebo klíčkem přiděleným při navázání relace. Čemuž dál už velmi dobře odpovídá Vaše zmínka o Session ID.

[Reklama]

[Filip Jirsák]

Tady bych si tipnul, že když nějaký komplexní stav je udržován serverem, tak klient musí pouze identifikovat sebe, klidně anonymně nějakým číslem nebo klíčkem přiděleným při navázání relace. Čemuž dál už velmi dobře odpovídá Vaše zmínka o Session ID.

Je možné to udělat i tak, že klient identifikuje sebe, resp. asi by bylo vhodnější napsat uživatele). Pak třeba nemůže mít ve dvou různých záložkách prohlížeče dva různé stavy (třeba dva různé košíky). Častější bývá to, že je identifikován opravdu stav, tj. nějaký soubor údajů uložený na serveru (to, čemu se říká session, česky by se asi dalo použít relace). Pak jeden uživatel může mít víc aktivních stavů/session, tj. může být přihlášen vícekrát nezávisle na sobě. Součástí stavu obvykle bývá i informace o přihlášeném uživateli.

Ale myslím, že oba píšeme o tom samém – prostě klient posílá nějaký identifikátor, a na serveru je k tomu identifikátoru v nějaké méně či více sofistikované mapě uložena hromada údajů, které dohromady tvoří stav.

[RDa]

A pak nesmime opomenout systemy, ktere odesilaji sice referenci na stav, ale taky neco jako pocitadlo uziti - takze takove pekelni hybridni kombo, sice si dve zalozky v prohlizeci otevrete, ale jedna session se okamzite zhrouti. Zdravim timto tupe vyvojare bankovnich aplikaci, ktery neznaji "right click, open in new tab". Tohle me vzdy tak nas*re..

[L..]

Zdravim timto tupe vyvojare bankovnich aplikaci, ktery neznaji "right click, open in new tab".

Vývojáři bankovních aplikací "right click open in new tab" znají. A dokonce také znají, že tohle má za následek, že aplikace běží ve dvou tabech které pak mají různý, nesynchronní stav. Tedy se může stát, že v jednom tabu provedu akci, která způsobí, že tlačítko zobrazené ve druhém tabu přestane dávat smysl a tyto stavy je třeba ošetřovat, ideálně i nějak rozumně vůči uživateli (tj. aby nedostal hlášku "Chyba #FE778A000C" nebo "Něco se pokazilo") a to je dost práce navíc. Proto se někdy business owner aplikace rozhodne, že to radši nebude podporovat vůbec.

I když chápu, občas se ty dvě okna hodí pro nějaké proovnávání atp.

[František Ryšánek]

Děkuji za podrobná vysvětlení...
díky Vám zas o něco víc oceňuji, co je za tím práce, když mám někde v e-shopu (TME, libovolná i6) otevřeno N tabů, "ta věc" mě v každém nově otevřeném tabu chápe jako téhož už přihlášeného usera, a když přihazuju v různých tabech do košíku, tak to na serverovém konci do toho společného košíku postupně přibývá. Trochu mi vrtá hlavou, že do toho nehodí vidle "sandboxing" tabů v moderních browserech (do toho, že nový tab převezme aktivní přihlášení). Přesto přetrvává charakter "stateless" HTTP, kde browser je primárně zobrazovač downloadnutého statického textu... proto když v jednom tabu něco přihodím do košíku, v jiném paralelním tabu se ikonka košíku vpravo nahoře (počet kusů) obvykle neaktualizuje, dokud neprovedu nějakou akci. Asi je ten update navázaný na událost z mé strany.
Dovedu si představit, že by client side HTTP GUI dostávalo "unsolicited updates" ze strany serveru, ale v tom případě by na klientu musel běžet nějaký relativně tlustý "agent", který by si otevřel proti serveru další komunikační kanál (ne HTTP) a tudy by dostával "události". Nebo by musel páchat pravidelný polling. Obě varianty mají pro a proti... Je to pro mě španělská ves, tohle taky pokrývají moderní "webové frameworky"?
(A co teprve všelijaké "platební brány" a podobné 3rd-party cross-site skopičiny... to mi teprve zůstává rozum stát :-)

[RDa]

Dovedu si představit, že by client side HTTP GUI dostávalo "unsolicited updates" ze strany serveru, ale v tom případě by na klientu musel běžet nějaký relativně tlustý "agent", který by si otevřel proti serveru další komunikační kanál (ne HTTP) a tudy by dostával "události".

Vzdyt to je primitivni ukol, vytvorit ajax dotaz a server by zdrzel odpoved do doby nez by nastala nutnost akce. Je to forma weboveho multi-chatu, a to jsme tvorili uz pred dvaceti lety, predpokladam ze dnes existuji na to lepsi API nez iframe. A ono to nemusi byt tlusty klient - vetsinou vidam ze prave serverova aplikace tam posle jen kus kodu, ktery pomeni stav na klientovi (tj. v pripade ze nemate otevrenou stranku s kosikem, tak aktualizuje jen cislo vedle ikony kose).

Spis to bude mit naroky na serverovou stranu, ze tam bude otevreno tolik spojeni, kolik lidi*tabu existuje ve svete a kdyz to preroste nejake deseti-tisice tak to zacina byt opruz, ale verim ze na to taky existuje framework.

[Filip Jirsák]

Ano, long polling se používal před dvaceti lety. Dnes vskutku existují modernější technologie jako WebSockets nebo server-sent events. Na serveru nejde ani tak o framework, který všechno zachrání, ale o počet souběžně otevřených spojení. A že když si klient drží otevřené spojení k serveru, nejde to moc dohromady s bezestavovým rozvažováním zátěže mezi více serverů, které umožňuje třeba dynamicky měnit počet serverů podle zátěže nebo bezvýpadkové aktualizace.