Przygotowałem pierwszą część wyjaśnienia zadania, dostępne jest ono tutaj. Jak do tej pory nadal tylko dwie osoby uporały się z zadaniem, nie widzę też by zadanie próbował rozwiązywać ktoś więcej, a szkoda. Głównym celem tego zadania jest ponowne pokazanie, że użytkownik może i będzie modyfikował dane, nad którymi ma kontrolę. Przykłady z ceną przekazywana w polach hidden są oklepane, dlatego w tym przypadku wykorzystałem przechowywanie stanu sesji po stronie klienta. Wybrałem ten przypadek, ponieważ niektóre frameworki pozwalają na przechowywanie całości lub części danych po stronie klienta, nie zawsze domyślnie właściwie chroniąc dane przechowywane w ten sposób. Czasami nie jest to istotne, a czasami wręcz przeciwnie...
Środa, listopada 25. 2009
Jeśli chodzi o powody korzystania z tego typu rozwiązań, to głównie spotykałem się z tłumaczeniem odnośnie wydajności właśnie, przy czym chodziło bardziej o pamięć - gdzieś te dane sesji muszą być trzymane. Tworząc wiele nowych sesji można przeprowadzić DoS i może być to łatwiejsze, niż ten sam DoS poprzez operację serializowania/deserializowania danych. Z drugiej strony rosną wówczas wymagania co do łącza.
Przychodzi mi do głowy jeszcze jedna zaleta trzymania sesji po stronie klienta - kompletna dowolność który serwer będzie obsługiwał klienta. Zwykle jest tak, że nawet jeśli jest jakiś klaster kilku serwerów jeden klient trafia do tego samego serwera, właśnie po to, by dane sesji były dostępne. Można to oczywiście rozwiązać inaczej (inny sposób składowania sesji po stronie "serwera"), ale może to być trochę skomplikowane i kosztowne. Przerzucenie utrzymywania stanu sesji na klienta może być wówczas uzasadnione, może go odtworzyć dowolny serwer.
Mimo wszystko jakoś trzymanie sesji po stronie klienta nie do końca do mnie przemawia.