This would allow users of the framework to lock-in a stateless setup, and make sure potential state changing requests are not processed without a security review.
We currently have two anti-xsrf strategies: angular (link) and HTML (link).
The idea would be to create a third one, called "xsrfblockall" or something similar that behaves exactly like xsrfhtml but it doesn't create or inject XSRF tokens, it just rejects all state changing requests.
The short summary is:
Create a third XSRF plugin and copy the HTML-based one.
This would allow users of the framework to lock-in a stateless setup, and make sure potential state changing requests are not processed without a security review.
We currently have two anti-xsrf strategies: angular (link) and HTML (link).
The idea would be to create a third one, called "xsrfblockall" or something similar that behaves exactly like
xsrfhtml
but it doesn't create or inject XSRF tokens, it just rejects all state changing requests.The short summary is:
Commit
implementationBefore
implementation to just reject if the request is state changing.