Responding to customer and partner feedback re: the Anti-XSRF helpers.

What's new:
- Programmatic configuration over various Anti-XSRF behaviors:
-> The name of the cookie to use.
-> Whether SSL is required.
-> Ability to provide a nonce or other "custom data".
- The exception message is now a little less cryptic.  It tells you exactly what check failed (e.g. the cookie 'foo' was missing, the token was meant for a different user, etc.).
- The system tries to detect if the current identity is degenerate (e.g. authenticated but without a name) and fails safe. The exception message specifies how to resolve the problem. (This check can be suppressed via config if necessary.)
- Ability to get the cookie and form token strings directly if you want more manual control.
- Built-in support for OpenID and Azure ACS (WIF).
- For most consumers, the token size is smaller.

Breaks:
- The salt / domain / path parameters are all obsolete as error. The customer can achieve the same effect by using the <httpCookies> configuration element or calling the AntiForgery.* APIs that are string-based.
- Not compatible with MVC 1 / 2 / 3. However, this system makes it easier to recover gracefully when an old token is submitted.

CR: marcind; bradwils
SR: naziml

0 files changed, 0 insertions, 0 deletions