Web aplikace a uživatelé – Udržování kontextu

   Webové aplikace jsou dnes již zažitým prostředkem pro prodej, monitorování, reportování ale i zábavu. Ať už jsou ale určeny k jakémukoliv účelu, jejich primárním úkolem bývá zobrazit uživateli nějaká data a umožnit mu je modifikovat a to pokud možno v závislosti na uživateli v jehož kontextu je akce prováděna.

   Jedním z nejdůležitějších úkolů většiny webových aplikací tedy je rozeznat uživatele a jeho práva, udržovat kontext a podle práv zpřístupňovat, odmítat nebo znepřístupňovat akce.

   HTTP je ale protokol nestavový, tedy mezi jednotlivými požadavky uživatele neexistuje žádné pojítko. Každý požadavek je zpracováván izolovaně od jiných a prakticky nezáleží na čase jeho zpracování. Není ani poskytnuta informace o identitě uživatele. Jak v takovém prostředí zařídit tak složitou akci?

   Nejlepší řešení bývá zpravidla jednoduché a toto pravidlo se odrazilo i zde. K informacím, které uživatel vědomě odesílá je zpravidla přidána sada informací, které uživatele pomohou identifikovat. Citlivé informace potřebné pro udržení kontextu jsou ukládány do session a uživatel se identifikuje pouze identifikátorem session. Při vstupu do zpracování jeho požadavku je na základe identifikátoru navázána session a o její data je pak rozšířena sada vstupních informací.

Schéma Zde

   Průběh zpracovávání požadavku tedy vypadá následovně. Uživatel vykoná akci, která způsobí odeslání dat na server, například stiskne tlačítko pro odeslání. Toto odeslání dat je však pouze dalším požadavkem na stránku na serveru. Tento požadavek má jako parametry vstupní data z formuláře. Browser tedy projde formulář a zapíše data do požadavku. Těsně před odesláním se projde seznam cookies a ty z položek, které mají být odesílány na cílový server, jsou zapsány také do dat požadavku. Výsledný balík je odeslán na server přes komunikační médium tedy zpravidla internet. Na serveru jsou data přijata a z nich je vytvořena kolekce vstupních dat. V této kolekci je nalezen identifikátor pro session. Server tedy projde seznam aktivních session a data z nalezené session jsou přidána ke kolekci vstupních dat. Pak server spustí samotné zpracování dat, jehož výsledkem je nová HTML stránka obsahující data, někdy nastavení nových hodnot do cookies a případně i nový identifikátor session.

   V závislosti na použitém jazyce se může skutečné zpracování v detailech měnit jako třeba načítání session z paměti nebo z disku, formát a název cookie s identifikátorem session a případně i kapacita session. Ani jednu z těchto informací však uživatel nepocítí.

Kdy použít session a kdy cookies?
   Obecně platí pravidlo, že vše, co je „drahé“ získat a váže se k uživateli by mělo spadnout do jednoho z těchto dvou kontainerů. Pokud není k dispozici jiné lepší řešení. Kterou položku ale kam zařadit?

Session
   Práci spojenou se session nese server. Data v session lze považovat za bezpečná, protože nikdy neopouští server, přesnějí nikdy nejsou ze serveru odesílána k uživateli. Server je ale zatěžován neustálou serializací (čili ukládáním) a deserializací (tedy načítáním) dat pro danou session při každém požadavku klienta. Pokud se nám na serveru pohybují tisíce lidí, může tato zátěž už být nezanedbatelná a nevhodná implementace těchto mechanismů může být nakonec pomyslným jazýčkem vah, který způsobí, že se server tiše odebere do věčných lovišť. Proto by data v session měla být rozumně volena a neměla by být pokud možno moc velká. Pokud už nejsou daná data třeba měla by být zahozena aby nadále nezatěžovala zbytečně server. Většinou postačí alespoň vynulování daného klíče, pokud nelze odebrat ze session rovnou celý klíč.

Cookies
   Práci spojenou s cookies nese klient, ale nelze zapomenout na přenosovou linku, protože data cookies pendlují mezi serverem a klientem v každém klientském požadavku. Nebezpečí těchto dat je v tom, že jednak se nesmíme spoléhat, že nám klient tato data poskytne (prostě jen nechce), nebo dokonce data mohl modifikovat. Velmi nevhodným řešením tedy je posílat uživateli v cookies seznam jeho práv a tímto seznamem se pak řídit. Toto řešení je sice jednoduché a funkční, nicméně bezpečnost je minimální a poskytujeme zde rozsáhlou příležitost k napadení serveru. Naopak vhodnou položkou pro cookie je nějaké uživatelsky specifické nastavení, jako třeba zvolený skin stránek apod. Pokud nám jej uživatel nedodá, prostě zobrazíme defaultní skin, pokud požaduje skin, který neznáme, zobrazíme prostě defaultní.