Używanie plików cookie do przechowywania sesji w ASP MVC

Question

Przechowywanie całej sesji w pliku cookie było standardem w Railsach od kilku lat - czy istnieje prosty sposób na osiągnięcie czegoś podobnego w ASP MVC?

Domyślnie wszystko w Session/TempData jest przechowywane w pamięci na serwerze. W web.config można to zmienić na pamięć podręczną SQL/serwer po stronie serwera. Chciałbym móc zachować te obiekty w pliku cookie.

Wygląda na to, że mogę zaimplementować niestandardowego dostawcę magazynu stanu sesji. Czy istnieje prostsze podejście?

Answer 1

Tak, zaimplementuj custom state session-provider. I nie, Afaiku nie ma prostszego podejścia.

Ps. nie jest tak źle, jak wygląda, tzn.> połowa z odbc sample pisze do bazy danych.

Answer 2

zależy od rodzaju danych, które chcesz przechowywać w pliku cookie, jeśli chcesz po prostu do przechowywania ciąg poniższy kod zrobi:

HttpCookie cookie = new HttpCookie("username","sth"); 
      cookie.HttpOnly = true; 
      cookie.Expires = DateTime.Now.AddMonths(3); 
      HttpContext.Current.Response.Cookies.Add(cookie); 

Answer 3

Nie należy używać sesji dla tego, ale Profile zamiast. Profile używają plików cookie do łączenia komputerów z profilami itp. Klucz profilu jest przechowywany w pliku cookie i nie jest tracony podczas zamykania przeglądarki itp.

Informacja tutaj; http://odetocode.com/articles/440.aspx

Answer 4

Zdecydowanie odradzam przechowywanie całej sesji w plikach cookie. Ma złe konsekwencje dla wydajności. Rozważmy to: każde żądanie (do każdego zasobu) będzie zawierać narzut prawdopodobnie nieaktualnych danych, których potrzebujesz tylko raz lub dwa razy. W ostatecznym rozrachunku obciążenie to wpłynie na użytkowników, przepustowość i wydajność witryny.

Oto przykład:

GET/HTTP/1.1 
Host: localhost 
OtherUsefulHeaders: foo 
Cookie: YourSessionState=... 

Początkowy rozmiar żądania wynosi około 200 bajtów. Powiedzmy, że dodajesz około 100 bajtów do swojej sesji. Teraz rozmiar wynosi 300 bajtów, a narzut to ~ 30%. Dodajesz kolejne 100 bajtów, a narzut wynosi 50%. Co oznacza, że ​​z grubsza wymaga 2x czasu, aby wysłać żądanie i 2x przepustowość.

Powinieneś raczej zajrzeć do cookie-based TempData implementation, ponieważ ma znacznie mniejszy ślad i ma sens.

Answer 5

Myślę, że znacznie wydajniejsze byłoby przechowywanie identyfikatora sesji (skrótu lub czegoś innego) w pliku cookie, a następnie użycie tego identyfikatora do pobrania danych sesji z pamięci/bazy danych/dowolnej wolnej pamięci. Utrzymywanie stanu pełnej sesji w pliku cookie powoduje niepotrzebne zwiększanie przepustowości.

Pamiętaj też o bezpieczeństwie: jeśli plik cookie zawiera informacje uwierzytelniające lub inne wrażliwe dane, a użytkownik nie jest ostrożny, może zostać łatwo zhakowany przez użytkownika w celu uzyskania przywilejów lub w inny sposób zepsuć aplikację (szyfrowanie danych jest do bani też, ponieważ wtedy musisz bazować 64-kodować zaszyfrowane dane, co dalej marnuje przepustowość i czas przetwarzania). Powinieneś nigdy nie otrzymywać danych wejściowych zaufania od użytkownika.