2009-09-18 14 views
7

Buduję klasę do przechowywania ID użytkownika i roli użytkownika w sesji. Nie jestem pewien, jak ta klasa będzie się zachowywać, gdy w witrynie jednocześnie jest wielu użytkowników. Czy ktoś widzi z tym problem?Statyczna klasa sesji i wielu użytkowników

public static class SessionHandler 
    { 
     //*** Session String Values *********************** 

     private static string _userID = "UserID"; 
     private static string _userRole = "UserRole"; 

     //*** Sets and Gets ********************************************************** 

     public static string UserID 
     { 
      get 
      { 
       if (HttpContext.Current.Session[SessionHandler._userID] == null) 
       { return string.Empty; } 
       else 
       { return HttpContext.Current.Session[SessionHandler._userID].ToString(); } 
      } 
      set 
      { HttpContext.Current.Session[SessionHandler._userID] = value; } 

     } 
     public static string UserRole 
     { 
      get 
      { 
       if (HttpContext.Current.Session[SessionHandler._userRole] == null) 
       { return string.Empty; } 
       else 
       { return HttpContext.Current.Session[SessionHandler._userRole].ToString(); } 
      } 
      set 
      { HttpContext.Current.Session[SessionHandler._userRole] = value; } 
     } 

} 
+1

Niewłaściwe i zachęca do złych praktyk, takich jak używanie statycznych "globalnych" pomocników. Nie jest to problem techniczny, bardziej problem z mentalnością o długoterminowych skutkach. – MikeSW

Odpowiedz

6

Kod, który wysłałeś, jest dokładną repliką kodu, który tutaj mamy.

Działa już dobrze od 2 lat.

Każdy użytkownik ma dostęp do własnej sesji. Każde żądanie wysłane do serwera jest nowym wątkiem. Mimo że 2 żądanie jest jednoczesne, HttpContext.Current jest inny dla każdego z tych żądań.

3

Otrzymasz nową sesję dla każdego połączenia. Dwóch użytkowników nigdy nie będzie współużytkować sesji. Każde połączenie będzie miało własną wartość SessionID. Tak długo, jak użytkownik pozostaje na twojej stronie (nie zamyka przeglądarki itp.), Użytkownik zachowuje tę sesję od jednego żądania do następnego.

+0

Niekoniecznie ... Jeśli korzystasz z uwierzytelniania krzyżowego ... Możesz mieć nowo uwierzytelnionego użytkownika przy użyciu tej samej sesji. Już wcześniej wpadłem na ten problem. Sesja jest niezależna od uwierzytelnienia. Jeśli użytkownik może zakończyć sesję i zabić autoryzację w pierwszej lokacji ... autoryzacja zniknie z drugiej witryny, ale sesja jest oddzielna. – KingOfHypocrites

0

To zadziała dobrze dla wielu użytkowników uzyskujących dostęp do aplikacji, ponieważ będzie generowany inny identyfikator sesji dla wszystkich użytkowników korzystających z aplikacji jednocześnie. Będzie działać w podobny sposób, jeśli zdefiniujesz dwie różne zmienne sesji w systemie. To będzie jak pakowanie stanów sesji holowania za pomocą klasycznej klasy pakowania SessionHandler.

Powiązane problemy