2013-07-19 12 views
11

Moje badania wskazują, że jeśli utworzę plik cookie i nie ustawię daty wygaśnięcia, wygasa ona po zamknięciu przeglądarki.Plik cookie wygasa, gdy sesja przeglądarki kończy się

Więc stworzyłem cookie takiego:

Response.Cookies.Set(new HttpCookie("MyKey", "X")); 

Ale kiedy zamknąć przeglądarkę, a następnie otwórz go ponownie, następujące wyrażenie równa się prawda:

Request.Cookies["MyKey"] != null 

Jak mogę mieć ciasteczko wygaśnie kiedy kończy się sesja przeglądarki?

Uwaga: Dla moich celów używanie statycznych danych zamiast plików cookie wydaje się idealne. Ale rozumiem, że ASP.NET może zostać uruchomiony ponownie z różnych powodów, a to może wyciągnąć dywanik spod bieżącego użytkownika, jeśli utracę to ustawienie.

+0

Chcesz mieć ciasteczko na serwerze wygasają po zakończeniu sesji przeglądarki? Jak sprawdzić wartość 'Request.Cookies [" MyKey "]' po zamknięciu przeglądarki? – Stobor

+0

Chcę cookie na kliencie, a nie na serwerze. Sprawdzam wartość pliku cookie po zamknięciu przeglądarki po ponownym otwarciu przeglądarki i ponownym załadowaniu strony. –

+0

Ciekawe, czy w grze znajduje się jakaś nieudokumentowana wartość domyślna - umieść punkt przerwania na lub po "Response.Cookies.Add" i sprawdź aktualne wartości ustawionych plików cookie, aby upewnić się, że wygasanie jest ustawione (lub nie jest ustawione) zgodnie z oczekiwaniami. Sprawdź również rzeczywiste pliki cookie w przeglądarce, aby upewnić się, że wygasanie jest ustawione (lub nie jest ustawione) zgodnie z oczekiwaniami. –

Odpowiedz

15

Wydaje się, że problem jest opisany STOBER. Możesz ustawić plik cookie wygasający na końcu sesji przeglądarki, ustawiając właściwość HttpCookie.Expires na DateTime.MinDate lub nie ustawiając jej wcale.

Jednak przynajmniej z ustawieniami Chrome dla pick-up-where-you-left-off, wygląda na to, że sesja przeglądarki niekoniecznie kończy się po zamknięciu przeglądarki. Po zamknięciu i ponownym otwarciu przeglądarka Chrome jest uruchamiana od miejsca, w którym została przerwana, tak jakby sesja nigdy się nie zakończyła. Obejmuje to dalsze korzystanie z plików cookie wygasających z końcem sesji.

Próbowałem tego samego kodu na FireFox. Zamknięcie i ponowne otwarcie przeglądarki spowodowało wygaśnięcie pliku cookie, zgodnie z oczekiwaniami.

Tak więc, chociaż istnieją pewne ogólne zasady, ostatecznie zachowanie to zależy wyłącznie od przeglądarki.

0

Po prostu ustaw właściwość Expires instancji HttpCookie na DateTime.MinDate, a wygasa ona po zakończeniu sesji przeglądarki.

Jednak, to faktycznie nie bezpieczny sposób chronić coś z ciasteczek, ponieważ ciasteczka są rzeczywiście ważne dla historii. Zależy to od implementacji klienta, jeśli pliki cookie są odrzucane lub nie. Jeśli jakaś zła osoba przechwyci twoje ciasteczka, będzie miała do nich dostęp na zawsze.

Zobacz także: MSDN - Cookie.Expires Property

+0

Ustawienie daty wygaśnięcia na "DataTime.MinDate" ma taki sam efekt jak nie ustawienie daty wygaśnięcia. W Chrome (przynajmniej z określonymi ustawieniami) oznacza to, że plik cookie nie wygasa po zakończeniu sesji przeglądarki. (A przynajmniej "sesja przeglądarki" nie kończy się, gdy przeglądarka jest zamknięta.) –

0

Możesz złapać to na następnym Session_start wydarzeniu. Jeśli masz już uwierzytelnionego użytkownika od razu po rozpoczęciu zupełnie nowej sesji, musisz zdobyć tę informację z nieaktualnego pliku cookie. Po prostu usuń informacje o użytkowniku i pozwól, aby przekierowania logowania zajmowały się resztą.

Coś takiego w global.asax.cs:

protected void Session_start() 
{ 
    // starting a session and already authenticated means we have an old cookie 
    var existingUser = System.Web.HttpContext.Current.User; 
    if (existingUser != null && existingUser.Identity.Name != "") 
    { 
     // clear any existing cookies 
     IAuthenticationManager authMgr = System.Web.HttpContext.Current.GetOwinContext().Authentication; 
     authMgr.SignOut("MyCookieType") 

     // manually clear user from HttpContext so Authorize attr works 
     System.Web.HttpContext.Current.User = new ClaimsPrincipal(new ClaimsIdentity()); 
    } 

} 
  • Kod może się nieco różnić w zależności od tego, jak jesteś uwierzytelniania użytkowników

Patrz także:

Powiązane problemy