I discovered while using this library that the current XSRF protections do not allow for a GET request sent by the browser on protected routes, due to requiring the presence of the XSRF token in a header. This is a problem for applications that are not SPAs and send GET requests to the server to retrieve a new HTML page. In these situations, the common pattern is to skip XSRF checks on GET requests.
For example, links in my application trigger GET requests when clicked, and without writing a custom onclick handler for links (which I would rather not do, as I am using raw HTML templates), there is no place to write the logic to grab the XSRF cookie and add it to the request as a header.
I discovered while using this library that the current XSRF protections do not allow for a GET request sent by the browser on protected routes, due to requiring the presence of the XSRF token in a header. This is a problem for applications that are not SPAs and send GET requests to the server to retrieve a new HTML page. In these situations, the common pattern is to skip XSRF checks on GET requests.
For example, links in my application trigger GET requests when clicked, and without writing a custom onclick handler for links (which I would rather not do, as I am using raw HTML templates), there is no place to write the logic to grab the XSRF cookie and add it to the request as a header.
I have opened a PR to address this issue.