Piszemy aplikację mobilną iOS na cel-c, która wysyła posty do naszej aplikacji serwera ASP.NET MVC. W telefonie iPhone stos HTTP (i pliki cookie itp.) Wydają się być udostępniane w Safari. To pozostawia nas otwartych na ataki XSRF, więc jeśli się nie mylę, musimy chronić POST za pomocą tokenów przeciwdziałających fałszerstwom i chronić nasze metody kontrolerów za pomocą ValidateAntiForgeryTokenAttribute.AntiForgery.GetTokens: jaki jest cel parametru oldCookieToken?
Będę kwalifikować to pytanie, mówiąc, że nie rozumiem właściwie mechanizmu generowania i weryfikacji żetonów antykradzieży ... w szczególności termin "nonce" używany w tym kontekście jest nieco mistyczny.
Ponieważ nie dostarczamy HTML do klienta, nie możemy użyć standardu @Html.AntiForgeryToken(), więc zamiast tego musimy użyć AntiForgery.GetTokens, aby nabyć i rozpowszechnić tokeny dla naszych klientów. Ma to tajemniczy pierwszy parametr: oldCookieToken. W tej chwili ustawiłem go na null i wszystko wydaje się działać dobrze. Czy ktoś może mi powiedzieć ... jaki jest pożytek z dostarczenia starego tokena do algorytmu generującego token? Jeśli tylko jeden token zostanie wydany naszej aplikacji na iOS i ponownie użyty do wielu postów, czy to będzie problematyczne?
Cóż - uznałem to za przydatne. Nie wiesz, dlaczego nie została oznaczona jako odpowiedź. W każdym razie dzięki. –
@PaulDeen: Jest teraz :-) – spender
Uwaga: Jeśli przekażesz prawidłowy oldCookieToken, newCookieToken będzie zawsze pusty, a nie tak samo jak oldCookieToken. – Alex