2015-03-11 19 views
27

Mam pewne problemy z uwierzytelnianiem OWIN Cookie. Mam witrynę .Net, która ma kilka stron MVC, które używają uwierzytelniania plików cookie i zasobów WebAPI chronionych przez token na okaziciela.OWIN - Uwierzytelnianie.SignOut() prawdopodobnie nie usuwa ciasteczka

Po wylogowaniu usuwam token dostępu na kliencie, aby kolejne żądania interfejsu API nie zawierały tokenu w nagłówku, a zatem nie będą uwierzytelniane. Ta część jest w porządku.

W podobny sposób chciałbym również wylogować się, aby usunąć plik cookie wykorzystywany przez strony MVC. Zrobiłem następujące operacje na serwerze:

[Route("Logout")] 
    public IHttpActionResult Logout() 
    { 
     var ctx = Request.GetOwinContext(); 
     var authenticationManager = ctx.Authentication; 
     authenticationManager.SignOut(); 
     return Ok(); 
    } 

Jednak po wywołującego wylogowania, mogę nadal odwiedzenia strony chronionej MVC chociaż cookie byłby podobno został usunięty przez wywołanie wylogowaniu.

Wydaje się to takie proste, więc mogłem coś przeoczyć.

Dzięki,

Odpowiedz

-1

mam to do pracy. Oto co zrobiłem:

Kiedy zadzwoniłem do powyższej czynności Logout, użyłem Fiddlera, ponieważ wciąż testowałem funkcję wylogowania. Wrzuciłem punkt przerwania do środka i tak, metoda jest pomyślnie wywoływana. Wywołuje funkcję authenticationManager.SignOut(), jednak moja strona chroniona nadal działa.

Więc zamiast używania Skrzypek, postanowiłem umieścić kod w kliencie:

var token = sessionStorage.getItem(tokenKey); 
    var headers = {}; 
    if (token) { 
     headers.Authorization = 'Bearer ' + token; 
    } 

    $.ajax({ 
     type: 'POST', 
     url: '/api/Account/Logout', 
     headers: headers 
    }).done(function (data) { 
     self.result("Logout Done!"); 
    }).fail(showError); 

Przewodowa ten kod do przycisku wylogowania, i voila! Zabezpieczona strona MVC wyświetla teraz oczekiwany błąd 401 Nieautoryzowany po kliknięciu przycisku Wyloguj. Jak zwykle, zasób WebAPI również zawiera oczekiwany błąd 401.

W końcu działa, wydaje mi się, że proces użycia narzędzia Fiddler do testowania w jakiś sposób powoduje problem. Nie potrafię jednak wyjaśnić, dlaczego tak się dzieje.

Dzięki za przeczytanie.

36

Miałem podobny problem od kilku ostatnich dni. Zamiast

Request.GetOwinContext().Authentication.authenticationManager.SignOut(); 

użyć jednego (i tylko jeden) z nich:

Request.GetOwinContext().Authentication.SignOut(); 

Request.GetOwinContext().Authentication.SignOut(Microsoft.AspNet.Identity.DefaultAuthenticationTypes.ApplicationCookie); 

HttpContext.Current.GetOwinContext().Authentication.SignOut(Microsoft.AspNet.Identity.DefaultAuthenticationTypes.ApplicationCookie); 

Ten artykuł wyjaśnia, dlaczego cookies nie zostaną usunięte: http://dotnet.dzone.com/articles/catching-systemwebowin-cookie

Wiem, że moja odpowiedź nie jest najbardziej oparte na badaniach, ale prawdę mówiąc, po prostu nie mogłem znaleźć, DLACZEGO podane przez mnie przykłady kodu działają dla mnie. Po prostu wiem, że System.Web zaskakuje ciasteczka Owins, jeśli zrobisz SignOut() w inny sposób.

+1

Dzięki! Przekazywanie 'Microsoft.AspNet.Identity.DefaultAuthenticationTypes.ApplicationCookie' do' SignOut' działało dla mnie. Podpisywaliśmy ludzi z 'Session_Start()' w 'Global.asax.cs' –

3

Inne opcje nie dla mnie działały, jednak udało mi się rozwiązać ten problem, wykonując następujące czynności.

W Startup.cs pliku można określić, w jaki sposób plik cookie jest przechowywany:

app.UseCookieAuthentication(new CookieAuthenticationOptions 
{ 
    AuthenticationType = "ExternalCookie", 
    AuthenticationMode = AuthenticationMode.Passive, 
    CookieName = ".AspNet.SomeName", 
    ExpireTimeSpan = TimeSpan.FromMinutes(5) 
}); 

można zobaczyć w powyższym przykładzie kodu ustawić nazwę cookie „.AspNet.SomeName”.

Teraz można zniszczyć go po prostu przez ustawienie cookies upływie terminu do przeszłości:

if (HttpContext.Current.Request.Cookies[".AspNet.SomeName"] != null) 
{ 
    HttpCookie myCookie = new HttpCookie(".AspNet.SomeName"); 
    myCookie.Expires = DateTime.Now.AddYears(-1); 
    HttpContext.Current.Response.Cookies.Add(myCookie); 
} 
+0

Ale czy ciasteczko" .AspNet.SomeName "jest ciastkiem tylko HTTP? Przyczyna, jeśli nie, jest tu problem bezpieczeństwa. Używanie pliku cookie uwierzytelniania dostępnego z poziomu klienta –

+0

Usuwa jedynie plik cookie z odpowiedzi do przeglądarki użytkownika. To nie kończy ich sesji aplikacji. Może dać złudzenie, że tak się dzieje, ponieważ użytkownik nie będzie już więcej zalogowany, ponieważ ciasteczko zniknęło. Ale jeśli ktoś inny nie zaakceptował lub nie uzyskał tego ciasteczka, mógł nadal przechwytywać aktywną sesję za jego pomocą ... musisz wywołać stronę serwera AuthenticationManager.SignOut(), aby zakończyć sesję - nie ma mowy o tym. – Breeno

2

Ten pracował dla mnie. Wrzuć go do kontrolera, gdy chcesz unieważnić plik cookie. W szczególności użyłem tego do aktualizacji ról użytkownika, aby użytkownik nie musiał ręcznie wylogowywać się i ponownie włączać, aby naprawić menu, które zostały załadowane pod @if(User.IsInRole("Admin")){...}. Mam nadzieję, że to pomoże komuś - zajęło mi trochę czasu, aby to zrozumieć.

var updatedUser = await UserManager.FindByNameAsync(User.Identity.Name); 
    var newIdentity = await updatedUser.GenerateUserIdentityAsync(UserManager); 
    AuthenticationManager.SignOut(); 
    AuthenticationManager.SignIn(newIdentity); 
0

Podążyłem za wszystkimi powyższymi rozwiązaniami, ale pomyliłem się na końcu, ponieważ użytkownik się nie wylogował. Wreszcie mój problem rozwiązany przez:

Request.GetOwinContext().Authentication.SignOut(DefaultAuthenticationTypes.ApplicationCookie); 
FederatedAuthentication.SessionAuthenticationModule.SignOut(); 

Ponieważ użyłem SessionAuthenticationModule zachować roszczeń w nim, a następnie po zalogowaniu się, użytkownik może korzystać z aplikacji ze względu na istniejącą FedAut w ciasteczkach.

0
AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie); 
FormsAuthentication.SignOut(); 
Session.Abandon(); 
0

O Wyloguj ASP.NET MVC nie działa: -

miałem problem gdzie aplikacja obsługiwana w IIS w trybach produkcyjnych nie działa prawo chromem

choć został opracowany w prawo podczas - używanie hostingu Visual Studio Dev we wszystkich przeglądarkach - w trybie produkcyjnym przez IE

Miałem problemy w Startup.Auth.CS. Upewnij się, że zduplikowane konfiguracje nie występują dla następujących elementów:

app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create); 
app.UseCookieAuthentication((new CookieAuthenticationOptions(.....))