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...
Najnowsze wpisy
- Jak powstaje elektrozłom
- Sunday, 21 July 2024
- Cluster
- Monday, 15 July 2024
- Sponsorem przebudowy placu zabaw jest...
- Sunday, 30 June 2024
- Po lewej stronie drogi
- Sunday, 19 May 2024
- Nie lubię, gdy jest płasko
- Sunday, 18 February 2024
- Nowy iPad - wrażenia z przesiadki
- Wednesday, 24 January 2024
- Jak nie wiesz, to nie wiesz
- Sunday, 14 January 2024
- Z microk8s na k3s
- Wednesday, 8 November 2023
- Rajesh Penetrator
- Saturday, 2 September 2023
- random(random())
- Tuesday, 1 August 2023
Losowe wpisy
- Encoding: ESAPI
- Sunday, 18 December 2011
- Jest "dziura". I co z tego?
- Monday, 14 November 2011
- Bootcamp VIII: wyzwanie (hint III)
- Sunday, 7 June 2009
- Bieganie jest zdrowe?
- Sunday, 7 December 2014
- Wyzwanie: browsers under attack
- Wednesday, 17 February 2010
- Wrrr! Wolę Urząd Skarbowy niż ZUS....
- Thursday, 14 June 2007
- Miałem memory leak
- Wednesday, 10 June 2009
- Rozwiązanie wyzwania: Forensic Challenge 2010 - Banking Troubles
- Thursday, 13 May 2010
- Łańcuch kontroli
- Tuesday, 10 July 2012
- Tamagotchi X: logi
- Thursday, 22 May 2008
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.