Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.
Śledzenie stanu użytkownika, przechowywanie jego danych jest bardzo ważnym elementem w naszych aplikacjach. Nie jest to oczywiście problem tylko aplikacji webowych ale również “okienkowych” ;) My jednak dzisiaj skupimy się na rozwiązaniach dla pierwszego typu oprogramowania ;) A konkretnie omówimy sobie następujące mechanizmy: View state, Hidden fields, Cookies oraz Query string.
Są dwa sposoby na zarządzanie informacjami. Wszystko możemy “zwalić” po stronie klienta albo przechowywać na serwerze. Podstawową różnice i ładnie to zobrazowuje poniższy rysunek:
Korzyści wynikające z przechowywania informacji po stornie klienta są następujące:
Lepsza skalowalność – kiedy informacje trzymamy na serwerze to każde, żądanie klienta obciąża pamięć serwera. Jeśli serwer ma jednocześnie obsłużyć setki użytkowników na raz, to staję się to wielkim ograniczeniem. Zrzucając to na klienta pozawalamy serwerowi obsłużyć więcej wniosków.
Obsługa wielu serwerów www – po stronie klienta żądanie może być obsłużone przez różne serwery. W tym przypadku klient zawiera informacje które są potrzebne dla serwerów aby obsłużyć to żądanie. Jeżeli byśmy nie chcieli korzystać z rozwiązania po stronie klienta to jeżeli klient chciałby się przełączyć pomiędzy serwerami w połowie sesji to ten “nowy serwer” nie musi mieć dostępu do naszych danych bo te są przecież zapisane na innym serwerze.
Natomiast trzymanie informacji po stronie serwera niesie za sobą następujące korzyści:
Większe/Lepsze bezpieczeństwo – informacje przechowywane u klienta mogą zostać przechwycone lub złośliwie zmodyfikowane. Dlatego nie poleca się trzymania po stronie klienta poufnych danych takich jak hasło, nadawania uprawnień czy statusu uwierzytelniania.
Zmniejszenie przepustowości – przechowywanie sporych informacji po stronie klienta i wysyłanie ich w tę i z powrotem może zwiększyć wykorzystanie pasma i czasu ładowania strony, potencjalnie zwiększyć koszt i ograniczyć skalowalność.
Wybór sposobu zarządzania i przechowywania informacjami, informacjami o stanie oczywiście należy do nas samych a powyższe argumenty powinny nam pomóc w wyborze. Bo wszystko jest sztuką kompromisu :) Również należy wziąć pod uwagę, że przedstawione powyżej sposoby nie są jedynymi i istnieje wybór tylko albo albo. Przejdźmy teraz do omawiania mechanizmów które pomagają nam w zarządzaniu stanem aplikacji i przechowywaniem informacji.
View State
View state jest domyślnym mechanizmem używanym w ASP.NET do przechowywania informacji pomiędzy kolejnymi żądaniami. Kiedy użytkownik wywołuje post back to wysyłany jest również view state. ASP.NET wykorzystuje view state do ponownego ustawienia wartości kontrolek. Najpierw jednak sprawdza czy któraś z tych wartości nie jest zmieniona w stosunku z przed post-back. Również załóżmy, że jest problem z obsłużeniem żądania na serwerze, wtedy trzeba zwrócić “pierwotne” wartości. W html-u stan kontrolek jest sprowadzony do ciągu znaków który wygląda następująco:
1: <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
2: value="/wEPDwULLTEzNjkxMzkwNjRkZAVvqsMGC6PVDmbCxBlPkLVKNahk" />
Jak widać dane są zakodowane, skompresowane co zapewnia większe bezpieczeństwo niż same ukryte pola. Teraz należało by powiedzieć, jak zabezpieczyć view state, jak z nim pracować itd.
View State Security Considerations
Musimy mieć świadomość, że view state jest polem ukrytym ale jego “wstępnie” zakodowana wartość jest jak najbardziej do odtworzenia. Dlatego jeśli mają zostać przesłane jakieś poufne informacje należy użyć właściwości ViewStateEncryptionMode która zaszyfruje nam dane. Aby włączyć szyfrowanie dla całej witryny musimy w web.configu dodać następujący fragment:
1: <configuration>
2: <system.web>
3: <pages viewStateEncryptionMode="Always"/>
4: </system.web>
5: </configuration>
Alternatywnie możemy zrobić to na poszczególnych stronach dodając:
1: <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_
2: Default" ViewStateEncryptionMode="Always"%>
Sam view state należy uznać za najbardziej bezpieczną metodę przechowywania i zarządzania danymi po stronie klienta. Samo szyfrowanie jest wystarczająco bezpieczne ale jednak jest to po stornie klienta…a co serwer to serwer ;)
Wyłączanie View State
Możemy wyłączyć view state. Pamiętajmy, że jest on domyślnie włączony a nie zawsze potrzebny. Zbyt wielka ilość przechowywanych danych powoduje spadek wydajności, dane są przesyłane tam i z powrotem pomiędzy przeglądarką a serwerem. Stąd możemy wyłączyć na danej stornie view state ustawiając właściwość Control.EnableViewState na false.
Odczytywanie i zapisywanie danych do View State
Zdarza się, że chcemy zachować pomiędzy kolejnymi żądaniami niestandardowe dane. Tutaj po raz kolejny przychodzi z pomocą bezpieczny i w miarę wydajny view state. Odczyt i zapis takich danych jest bardzo prosty, spójrzmy na poniższy przykład:
1: //C#
2: //writing to view state
3: this.ViewState.Add("MyData", "some data value");
4: //read from view state
5: string myData = (string)ViewState["MyData"];
Dane zapisane w view state nie są pamiętane przy każdym żądaniu. Dotyczą tylko pojedynczego post-backa danej strony. Dlatego mechanizm ten jest przydatny do przechowywania tymczasowych danych.
Nie jesteśmy również ograniczeni do przechowywania tylko ciągu znaków. W view state możemy również przechować obiekt. Przykład zachowania obiektu DateTime poniżej:
1: //C#
2: //check if ViewState object exists, and display it if it does
3: if (ViewState["lastVisit"] != null)
4: Label1.Text = ((DateTime)ViewState["lastVisit"]).ToString();
5: else
6: Label1.Text = "lastVisit ViewState not defined.";
7: //define the ViewState object for the next page view
8: ViewState["lastVisit"] = DateTime.Now;
Hidden fields
Jak wiem view state również jest ukrytym polem. Lecz tam wartość jest wstępnie szyfrowana. Tutaj ukryte pole tyczy się tylko tego, że nie widzimy bezpośrednio wartości na stornie ale jest ona ogólnie dostępna w kodzie źródłowym. Stąd klient może nią dowolnie manipulować. Pole to służy również tylko do przechowywania danych tymczasowych.
Cookies
Często potrzebujemy “śledzić” użytkownika, weryfikować dane od pierwszego wejścia po kolejne żądania, wejścia na stronę itd. Tutaj z pomocą przychodzą nam tzw. cookies czyli małe ilości danych które możemy sobie zapisać po stronie klienta. Mogą to być trwałe dane zapisane w pliku tekstowym. Dane te mają przetrwać po zamknięciu przeglądarki do ponownego jej otworzenia itp. Również cookies możemy zapisać w pamięci podręcznej przeglądarki ale dane te są tracone wraz z jej zamknięciem. Dla krótkiego zobrazowania sobie na jakiej zasadzie to działa wrzucam poniższy rysunek:
Ciasteczka są najbardziej elastycznym i niezawodnym sposobem na przechowywanie danych po stornie klienta. Ciasteczka ustawia się często na długo okres żywotności, jednak użytkownik może w każdym momencie sam je usunąć. A my tym samym tracimy wszystkie, być może dla nas ważne ustawienia ;)
Odczytywanie i zapis ciasteczek
Jest to zadania bardzo proste. Wywołujemy metodę Response.Cookies.Add w której przekazujemy obiekt HttpCookie który przechowuje kolekcje nazwa <—> dane. Coś na zasadzie słownika :)
1: Response.Cookies.Add(New HttpCookie("userId", userId))
Odczyt takiej danej:
1: Request.Cookies("userId").Value
Zapisywanie wielu wartości w cookie
Rozmiar pliku cookie zależy od przeglądarki ale maksymalnie może mieć 4 KB. Ponadto, zazwyczaj można zapisać do 20 plików cookie na stronę. Jeśli chcemy obejść ten 20 pliczków można zastosować sztuczkę dzięki której do jednej wartości przypiszemy wiele kluczy:
1: //C#
2: Response.Cookies["info"]["visit"].Value = DateTime.Now.ToString();
3: Response.Cookies["info"]["firstName"].Value = "Tony";
4: Response.Cookies["info"]["border"].Value = "blue";
5: Response.Cookies["info"].Expires = DateTime.Now.AddDays(1);
Query Strings
Query strings są powszechnie stosowane do przechowywania wartości zmiennych które np. identyfikują dany kontekst strony. Query strings są zawsze dołączone na końcu linka począwszy od znaku zapytania ?, następnie jest nazwa zmiennej i po znaku równości = wartość. Możemy umieścić wiele zmiennych, oddzielamy je wtedy znakiem &. Przykład takich linków:
http://support.microsoft.com/Default.aspx?kbid=315233
http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=hello+world
Jest to prosty sposób na przekazanie wartości pomiędzy kolejnymi żądaniami ale wielkim ograniczeniem jest tutaj jawność przesyłanych danych.
To tyle jeśli chodzi o dzisiejszy artykuł. Miłego weekendu.
