Roztrzaskałem się o to trochę za długo. Jak uniemożliwić użytkownikowi przeglądanie stron witryny po wylogowaniu za pomocą FormsAuthentication.SignOut? Spodziewałbym się, że to zrobi:

FormsAuthentication.SignOut();
Session.Abandon();
FormsAuthentication.RedirectToLoginPage();

Ale tak nie jest. Jeśli wpiszę adres URL bezpośrednio, mogę nadal przeglądać tę stronę. Od jakiegoś czasu nie używałem własnych zabezpieczeń, więc zapominam, dlaczego to nie działa.

Użytkownicy mogą nadal przeglądać Twoją witrynę, ponieważ pliki cookie nie są usuwane podczas połączenia FormsAuthentication.SignOut()i są uwierzytelniane przy każdym nowym żądaniu. W dokumentacji MS jest napisane, że ciasteczko zostanie wyczyszczone, ale tak nie jest, błąd? Dokładnie tak samo jest z Session.Abandon()ciasteczkiem.

Powinieneś zmienić swój kod na ten:

FormsAuthentication.SignOut();
Session.Abandon();

// clear authentication cookie
HttpCookie cookie1 = new HttpCookie(FormsAuthentication.FormsCookieName, "");
cookie1.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie1);

// clear session cookie (not necessary for your current problem but i would recommend you do it anyway)
SessionStateSection sessionStateSection = (SessionStateSection)WebConfigurationManager.GetSection("system.web/sessionState");
HttpCookie cookie2 = new HttpCookie(sessionStateSection.CookieName, "");
cookie2.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie2);

FormsAuthentication.RedirectToLoginPage();

HttpCookieznajduje się w System.Webprzestrzeni nazw. Dokumentacja MSDN .

Wykorzystanie dwóch z powyższych postów autorstwa x64igor i Phila Haseldena rozwiązało ten problem:

1. x64igor podał przykład wykonania wylogowania:

• Najpierw musisz wyczyścić plik cookie uwierzytelniania i plik cookie sesji , przekazując z powrotem puste pliki cookie w odpowiedzi na wylogowanie.

  public ActionResult LogOff()
  {
      FormsAuthentication.SignOut();
      Session.Clear();  // This may not be needed -- but can't hurt
      Session.Abandon();
  
      // Clear authentication cookie
      HttpCookie rFormsCookie = new HttpCookie( FormsAuthentication.FormsCookieName, "" );
      rFormsCookie.Expires = DateTime.Now.AddYears( -1 );
      Response.Cookies.Add( rFormsCookie );
  
      // Clear session cookie 
      HttpCookie rSessionCookie = new HttpCookie( "ASP.NET_SessionId", "" );
      rSessionCookie.Expires = DateTime.Now.AddYears( -1 );
      Response.Cookies.Add( rSessionCookie );

2. Phil Haselden podał powyższy przykład, jak zapobiegać buforowaniu po wylogowaniu:

• Musisz unieważnić pamięć podręczną po stronie klienta za pośrednictwem odpowiedzi .

      // Invalidate the Cache on the Client Side
      Response.Cache.SetCacheability( HttpCacheability.NoCache );
      Response.Cache.SetNoStore();
  
      // Redirect to the Home Page (that should be intercepted and redirected to the Login Page first)
      return RedirectToAction( "Index", "Home" ); 
  }

Wydaje mi się, że nie masz poprawnie skonfigurowanej sekcji autoryzacji web.config w programie. Poniżej przykład.

<authentication mode="Forms">
  <forms name="MyCookie" loginUrl="Login.aspx" protection="All" timeout="90" slidingExpiration="true"></forms>
</authentication>
<authorization>
  <deny users="?" />
</authorization>

Najważniejsze jest to, że mówisz „Jeśli wpiszę adres URL bezpośrednio ...”.

Domyślnie w ramach uwierzytelniania formularzy przeglądarka buforuje strony dla użytkownika. Tak więc, wybierając adres URL bezpośrednio z listy rozwijanej w polu adresu przeglądarki lub wpisując go, MOŻE uzyskać stronę z pamięci podręcznej przeglądarki i nigdy nie wracać do serwera w celu sprawdzenia uwierzytelnienia / autoryzacji. Rozwiązaniem tego problemu jest zapobieganie buforowaniu po stronie klienta w zdarzeniu Page_Load każdej strony lub w funkcji OnLoad () strony bazowej:

Response.Cache.SetCacheability(HttpCacheability.NoCache);

Możesz także zadzwonić:

Response.Cache.SetNoStore();

Już wcześniej z tym walczyłem.

Oto analogia do tego, co się wydaje ... Nowy użytkownik, Joe, przychodzi do witryny i loguje się za pośrednictwem strony logowania przy użyciu uwierzytelniania za pomocą formularzy. ASP.NET generuje nową tożsamość dla Joe i przekazuje mu plik cookie. To ciasteczko jest jak klucz do domu i dopóki Joe wróci z tym kluczem, może otworzyć zamek. Każdy gość otrzymuje nowy klucz i nowy zamek do użycia.

Kiedy FormsAuthentication.SignOut() wywołaniu system każe Joe zgubić klucz. Zwykle to działa, ponieważ Joe nie ma już klucza, nie może wejść.

Jednak jeśli Joe kiedykolwiek wróci i to zrobi ma tego utraconego klucza, jest on niech widok!

Z tego, co wiem, nie ma sposobu, aby powiedzieć ASP.NET, aby zmienił zamek w drzwiach!

Sposób, w jaki mogę z tym żyć, polega na zapamiętywaniu imienia Joe w zmiennej sesji. Kiedy się wylogowuje, opuszczam sesję, więc nie mam już jego imienia. Później, aby sprawdzić, czy może wejść, po prostu porównuję jego Identity.Nazwa z tym, co ma bieżąca sesja, a jeśli się nie zgadzają, nie jest on prawidłowym gościem.

Krótko mówiąc, w przypadku witryny internetowej NIE polegaj na niej User.Identity.IsAuthenticatedbez sprawdzania zmiennych sesji!

Po wielu poszukiwaniach w końcu to zadziałało. Mam nadzieję, że to pomoże.

public ActionResult LogOff()
{
    AuthenticationManager.SignOut();
    HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);
    return RedirectToAction("Index", "Home");
}

<li class="page-scroll">@Html.ActionLink("Log off", "LogOff", "Account")</li>

To działa dla mnie

public virtual ActionResult LogOff()
    {
        FormsAuthentication.SignOut();
        foreach (var cookie in Request.Cookies.AllKeys)
        {
            Request.Cookies.Remove(cookie);
        }
        foreach (var cookie in Response.Cookies.AllKeys)
        {
            Response.Cookies.Remove(cookie);
        }
        return RedirectToAction(MVC.Home.Index());
    }

Wydaje się, że opublikowany kod powinien poprawnie usuwać token uwierzytelniania formularzy, więc możliwe jest, że dane foldery / strony nie są w rzeczywistości chronione.

Czy potwierdziłeś, że strony nie są dostępne przed zalogowaniem?

Czy możesz opublikować ustawienia web.config i kod logowania, którego używasz?

Pisałem klasę bazową dla wszystkich moich stron i doszedłem do tego samego problemu. Miałem kod podobny do następującego i nie działał. Poprzez śledzenie kontrola przechodzi z instrukcji RedirectToLoginPage () do następnego wiersza bez przekierowywania.

if (_requiresAuthentication)
{
    if (!User.Identity.IsAuthenticated)
        FormsAuthentication.RedirectToLoginPage();

    // check authorization for restricted pages only
    if (_isRestrictedPage) AuthorizePageAndButtons();
}

Dowiedziałem się, że są dwa rozwiązania. Albo zmodyfikować FormsAuthentication.RedirectToLoginPage (); być

if (!User.Identity.IsAuthenticated)
    Response.Redirect(FormsAuthentication.LoginUrl);

LUB zmodyfikować plik web.config przez dodanie

<authorization>
  <deny users="?" />
</authorization>

W drugim przypadku podczas śledzenia formant nie dotarł do żądanej strony. Został natychmiast przekierowany do adresu URL logowania przed osiągnięciem punktu przerwania. Dlatego metoda SignOut () nie jest problemem, jest to metoda przekierowania.

Mam nadzieję, że to może komuś pomóc

pozdrowienia

Właśnie wypróbowałem niektóre z sugestii tutaj i chociaż mogłem użyć przycisku wstecz w przeglądarce, kiedy kliknąłem opcję menu, token [Autoryzuj] dla tego [ActionResult] odesłał mnie z powrotem do ekranu logowania.

Oto mój kod wylogowania:

        FormsAuthentication.SignOut();
        Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
        Response.Cache.SetExpires(DateTime.Now.AddSeconds(-1));
        HttpCookie cookie = HttpContext.Request.Cookies[FormsAuthentication.FormsCookieName];
        if (cookie != null)
        {
            cookie.Expires = DateTime.Now.AddDays(-1);
            Response.Cookies.Add(cookie);
        }

Chociaż funkcja wstecz w przeglądarce cofnęła mnie i wyświetliła zabezpieczone menu (nadal nad tym pracuję), nie mogłem zrobić nic, co było zabezpieczone w aplikacji.

Mam nadzieję że to pomoże

Próbowałem większości odpowiedzi w tym wątku, bez powodzenia. Skończyło się na tym:

protected void btnLogout_Click(object sender, EventArgs e)
{
    FormsAuthentication.Initialize();
    var fat = new FormsAuthenticationTicket(1, "", DateTime.Now, DateTime.Now.AddMinutes(-30), false, string.Empty, FormsAuthentication.FormsCookiePath);
    Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(fat)));
    FormsAuthentication.RedirectToLoginPage();
}

Znalazłem go tutaj: http://forums.asp.net/t/1306526.aspx/1

Ta odpowiedź jest technicznie identyczna z Khosro.Pakmanesh. Publikuję go, aby wyjaśnić, czym jego odpowiedź różni się od innych odpowiedzi w tym wątku iw jakim przypadku można jej użyć.

Ogólnie, aby wyczyścić sesję użytkownika, robi

HttpContext.Session.Abandon();
FormsAuthentication.SignOut();

skutecznie wyloguje użytkownika. Jeśli jednak w tym samym żądaniu musisz sprawdzić Request.isAuthenticated(co często może się zdarzyć na przykład w filtrze autoryzacji), zobaczysz, że

Request.isAuthenticated == true

nawet po tym, jak to zrobiłeś HttpContext.Session.Abandon()i FormsAuthentication.SignOut().

Jedyne, co działało, to robienie

AuthenticationManager.SignOut();
HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);

To skutecznie ustawia Request.isAuthenticated = false.

Zaczęło się to dziać po ustawieniu właściwości uwierzytelniania> formularzy> ścieżki w Web.config. Usunięcie tego rozwiązało problem i proste FormsAuthentication.SignOut();ponowne usunięcie pliku cookie.

Może się zdarzyć, że logujesz się z jednej subdomeny (sub1.domain.com), a następnie próbujesz wylogować się z innej subdomeny (www.domain.com).

Po prostu miałem ten sam problem, gdzie SignOut () najwyraźniej nie zdołał poprawnie usunąć biletu. Ale tylko w konkretnym przypadku, gdy inna logika spowodowała przekierowanie. Po usunięciu tego drugiego przekierowania (zastąpieniu go komunikatem o błędzie) problem zniknął.

Problem musiał polegać na tym, że strona została przekierowana w złym czasie, a tym samym nie wyzwalała uwierzytelniania.

Mam teraz podobny problem i uważam, że problem w moim przypadku, jak również w przypadku oryginalnego plakatu, wynika z przekierowania. Domyślnie Response.Redirect powoduje wyjątek, który natychmiast pojawia się, dopóki nie zostanie przechwycony, a przekierowanie zostanie natychmiast wykonane. Domyślam się, że zapobiega to przekazaniu zmodyfikowanej kolekcji plików cookie do klienta. Jeśli zmodyfikujesz swój kod, aby użyć:

Response.Redirect("url", false);

Zapobiega to wyjątkowi i wydaje się umożliwiać prawidłowe przesłanie pliku cookie z powrotem do klienta.

Po prostu spróbuj wysłać zmienną sesji po naciśnięciu przycisku logowania. Na stronie powitalnej najpierw sprawdź, czy ta sesja jest pusta w ten sposób podczas ładowania strony lub zdarzenia inicjującego:

if(Session["UserID"] == null || Session["UserID"] == "")
{
    Response.Redirect("Login.aspx");
}

U mnie działa następujące podejście. Myślę, że jeśli po instrukcji „FormsAuthentication.SignOut ()” występuje błąd, SingOut nie działa.

public ActionResult SignOut()
    {
        if (Request.IsAuthenticated)
        {
            FormsAuthentication.SignOut();

            return Redirect("~/");
        }
        return View();
     }

Czy testujesz / widzisz to zachowanie przy użyciu IE? Możliwe, że IE udostępnia te strony z pamięci podręcznej. Niezwykle trudno jest zmusić IE do opróżnienia pamięci podręcznej, więc w wielu przypadkach, nawet po wylogowaniu się, wpisanie adresu URL jednej z „zabezpieczonych” stron spowoduje wyświetlenie zawartości pamięci podręcznej sprzed wcześniejszej.

(Widziałem to zachowanie nawet wtedy, gdy logujesz się jako inny użytkownik, a IE wyświetla pasek „Witamy” u góry strony, ze starą nazwą użytkownika. Obecnie zwykle przeładowanie go zaktualizuje, ale jeśli jest trwały , nadal może to być problem z pamięcią podręczną).

Wykonanie Session.abandon () i zniszczenie ciasteczka działa całkiem nieźle. Używam mvc3 i wygląda na to, że problem występuje, gdy przechodzisz do chronionej strony, wylogowujesz się i przeglądasz historię przeglądarki. Nic wielkiego, ale wciąż trochę irytujące.

Jednak próba przeglądania linków w mojej aplikacji internetowej działa prawidłowo.

Ustawienie go tak, aby nie korzystało z pamięci podręcznej przeglądarki, może być dobrym rozwiązaniem.

W przypadku MVC działa to dla mnie:

        public ActionResult LogOff()
        {
            FormsAuthentication.SignOut();
            return Redirect(FormsAuthentication.GetRedirectUrl(User.Identity.Name, true));
        }

Chciałem dodać informacje, które pomogą zrozumieć problem. Uwierzytelnianie za pomocą formularzy umożliwia przechowywanie danych użytkownika w pliku cookie lub w ciągu zapytania adresu URL. Metodę obsługiwaną przez witrynę można skonfigurować w pliku web.config.

Według Microsoft :

Metoda SignOut usuwa informacje o biletach uwierzytelniania formularzy z pliku cookie lub adresu URL, jeśli wartość CookiesSupported ma wartość false .

Jednocześnie mówią :

Jedna z wartości HttpCookieMode, która wskazuje, czy aplikacja jest skonfigurowana do uwierzytelniania formularzy bez plików cookie. Wartość domyślna to UseDeviceProfile .

Na koniec, jeśli chodzi o UseDeviceProfile, mówią :

Jeśli właściwość CookieMode jest ustawiona na UseDeviceProfile, właściwość CookiesSupported zwróci wartość true, jeśli przeglądarka dla bieżącego żądania obsługuje zarówno pliki cookie, jak i przekierowanie z plikami cookie ; w przeciwnym razie właściwość CookiesSupported zwróci wartość false.

Składając to wszystko razem, w zależności od przeglądarki użytkownika, domyślna konfiguracja może spowodować, że pliki cookieSupported będą miały wartość true , co oznacza, że ​​metoda SignOut nie usuwa biletu z pliku cookie. Wydaje się to sprzeczne z intuicją i nie wiem, dlaczego działa w ten sposób - spodziewałbym się, że SignOut faktycznie wyloguje użytkownika w każdych okolicznościach.

Jednym ze sposobów, aby SignOut działał sam, jest zmiana trybu plików cookie na „UseCookies” (tzn. Pliki cookie są wymagane) w pliku web.config:

<authentication mode="Forms">
  <forms loginUrl="~/Account/SignIn" cookieless="UseCookies"/>
</authentication>

Zgodnie z moimi testami, wykonanie tego powoduje, że SignOut działa samoczynnie, kosztem Twojej witryny, która wymaga teraz plików cookie do prawidłowego działania.

Należy pamiętać, że WIF odmawia nakazania przeglądarce wyczyszczenia plików cookie, jeśli komunikat wsignoutcleanup z usługi STS nie pasuje do adresu URL z nazwą aplikacji z IIS, a mam na myśli WRAŻLIWE NA WIELKOŚĆ LITER . WIF odpowiada zielonym czekiem OK, ale nie znacznikiem wyśle ​​polecenia usunięcia plików cookie do przeglądarki.

Musisz więc zwrócić uwagę na rozróżnianie wielkości liter w adresach URL.

Na przykład ThinkTecture Identity Server zapisuje adresy URL odwiedzających RP w jednym pliku cookie, ale wszystkie są pisane małymi literami. WIF otrzyma komunikat wsignoutcleanup zapisany małymi literami i porówna go z nazwą aplikacji w usługach IIS. Jeśli nie pasuje, nie usuwa żadnych plików cookie, ale zgłosi OK do przeglądarki. Tak więc w przypadku tego serwera tożsamości musiałem zapisać wszystkie adresy URL w pliku web.config i wszystkie nazwy aplikacji w usługach IIS małymi literami, aby uniknąć takich problemów.

Nie zapomnij również zezwolić na pliki cookie stron trzecich w przeglądarce, jeśli masz aplikacje poza subdomeną STS, w przeciwnym razie przeglądarka nie usunie plików cookie, nawet jeśli WIF mu to powie.