2012-10-01 28 views
11

na stronie internetowej zapewniamy hiperłącze (GET), które użytkownik może kliknąć, aby uwierzytelnić:ASP.NET MVC - ValidateAntiForgeryToken upływającym

@Html.ActionLink("Please Login", "MyMethod", "MyController") 

mapuje to do następującej metody kontrolera, która zwraca widoku:

[RequireHttps] 
    public ActionResult MyMethod() 
    { 
     return this.View(new MyModel()); 
    } 

Ten widok zawiera formularz, w którym użytkownik podaje swoje dane uwierzytelniające; Formularz zawiera wymagany AntiForgeryToken.

Gdy użytkownik wysyła formularz, poniższa metoda kontroler jest nazywany:

[HttpPost] 
    [RequireHttps] 
    [ValidateAntiForgeryToken] 
    public ActionResult MyMethod(MyModel model) 
    { 
     // my logic 
    } 

To doskonale działa dobrze, większość czasu ...

Jednakże, jeżeli użytkownik opuści ich przeglądarka otwarta za „znaczące” okres czasu, a następnie wykonuje następujące czynności w krótkich odstępach czasu:

  1. kliknie hiperłącze (GET), aby załadować Zaloguj formie
  2. wypełnia formularz i przedkłada

Dostają wyjątek informując ich, że Anti-Fałszerstwo żeton był albo nie dostarczone lub jest nieprawidłowy.

Nie rozumiem, dlaczego tak się dzieje: widok (zawierający formularz) jest tworzony po uśpieniu przeglądarki, więc wszystkie żetony zapobiegające fałszerstwu powinny być "świeże". Jednak coś jest ewidentnie nie tak z tym projektem, ale nie jestem pewien, jak najlepiej to naprawić.

Z góry dziękuję, jeśli masz jakieś sugestie.

Griff

+0

Chcę tylko wspomnieć, że moja aplikacja doświadczył ten problem przez kilka lat i chciałbym mieć rozwiązanie. Wypróbowałem wszystkie standardowe poprawki klucza komputera. – Jonathan

+0

Podwiń te rękawy i zanurz się w źródle. Załatwię pompę. – Nick

+0

Istnieje [artykuł] (http://stackoverflow.com/questions/5767768/troubleshooting-anti-forgery-token-problems?rq=1), który szczegółowo opisuje kroki sprawdzania poprawności tokena. Jednym z kroków jest walidacja z użytkownikiem Kontekstu - nie ma pewności, czy to mogło wyjść z etapu. Tak czy inaczej, rozwiązanie pozostaje niejasne. – DrGriff

Odpowiedz

9

mam do czynienia z tym samym problemem i choć rozumiem problemu, nie jestem pewien, ale o najlepszej rozdzielczości.

Proces Anti-ForgeryToken umieszcza wartość wejściową w formularzu z drugą wartością przechowywaną w cookie RequestVerificationToken. Oba są przekazywane do serwera, a jeśli nie pasują, błąd jest zgłaszany.

Plik cookie RequestVerficationToken ma wartość wygasania ustawioną na sesję. Tak więc, gdy użytkownik pozostawia otwartą przeglądarkę na stronie przez dłuższy czas, a następnie przesyła, znacznik czasu pliku cookie jest porównywany z wartością limitu czasu sesji na serwerze - wartość domyślna wynosi 20 minut - i po przekroczeniu została usunięta a zatem weryfikacja tokenów kończy się niepowodzeniem.

Możliwe rozwiązania, z których wszystkie mają potencjalne problemy;

  1. Umieść timer javascript na stronie i odśwież o pewnej wartości mniej niż niż limit czasu sesji.
  2. Złap wyjątek System.Web.Mvc.HttpAntiForgeryException na serwerze - i przekieruj na tę samą stronę.
  3. Zwiększ limit czasu sesji
  4. Zmienić ważności na zapobiegające fałszerstwom tokena
+1

Uwaga, jak rozumiem, klucz maszynowy służy do sprawdzania modułu Anti-ForgeryToken na serwerze i jest niezbędny do użycia w systemie internetowym (a ustawienie statycznego klucza komputera może rozwiązać problem błędu spowodowany ponownym uruchomieniem procesu roboczego na serwerze), ale nie rozwiąże to problemu związanego z wygaśnięciem pliku cookie. –

+0

Jak już powiedziałeś, wygaśnięcie ciasteczka jest powiązane z Sesją, więc rozwiązanie 3 powinno również doprowadzić do rozwiązania 4. O ile nie zastąpisz ręcznie sposobu, w jaki plik cookie jest generowany. Próbowałem rozwiązania 1 w przeszłości i nie zawsze jest ono całkowicie niezawodne, więc kombinacja 3 (jeśli to możliwe) i 2 wydaje się najlepszymi opcjami. – Rowan