This new middleware participates in authentication and acts as a filter
when the request doesn't include a valid CSRF token for a POST.
Any authentication middleware that you want to validate an antiforgery
token should go ahead of this middleware in the pipeline (Cookies,
IISIntegration). This also takes care of automatic auth (Windows) done by
weblistener.
Any authentication middleware that you want to ignore antiforgery should
go after this middleware in the pipeline.
To facilitate this, there are a few changes in the antiforgery API
surface. Namely we can now pass in a principal to validate tokens. You
can't pass in a principal to generate tokens - we expect you to be logged
in at that poing. Also, ValidateRequestAsync(...) now checks the HTTP verb
and won't validate GETs and such.
This code was popping up everywhere this method is called. Seems bad to
duplicate it. Really what the caller wants to know is 'is the request
valid or a potential CSRF exploit?'. This gets the API closer to that.
Some other misc cleanup
- docs for IAntiforgeryTokenGenerator
- Add HttpContext parameter where to all IAntiforgeryGenerator methods
- rename parameters on DefaultAntiforgery
Juan Naputi
Kiran Challa
Ryan Nowak
Ajay Bhargav Baaskaran
Doug Bunting
N. Taylor Mullen