Missing CSRF token on post

[pocket5s]

Tokens seem to work fine with get calls, but on a post call I get a "Missing CSRF token" on a jwt_required() call. I've verified the cookies are all set by dumping out the incoming headers.

[IndominusByte]

you can check on the same issues #25 , I will fix the documentation later I'm sorry for the inconvenience 🙏

[pocket5s]

That gives me "CSRF double submit tokens do not match". that is putting the refresh token in the X-CSRF-TOKEN header.

[amiyatulu]

Check out using csrf_access_token instead of csrf_refresh_token

[pocket5s]

That worked. So why do I need that if it already a cookie and on a post and not a get?

[amiyatulu]

Check it out: https://stackoverflow.com/questions/34782493/difference-between-csrf-and-x-csrf-token An alternative approach (called the "Cookie-to-header token" pattern) is to set a Cookie once per session and the have JavaScript read that cookie and set a custom HTTP header (often called X-CSRF-TOKEN or X-XSRF-TOKEN or just XSRF-TOKEN) with that value. Any requests will send both the header (set by Javascript) and the cookie (set by the browser as a standard HTTP header) and then the server can check that value in the X-CSRF-TOKEN header matches the value in the cookie header. The idea being that only JavaScript run on the same domain would have access to the cookie, so JavaScript from another domain couldn't set this header to the right value (assuming the page is not vulnerable to XSS that would give access to this cookie). Even fake links (e.g. in a phishing email) would not work either, as even though they would appear to come from the right domain, only the cookie will be set but not X-CSRF-TOKEN header.

[IndominusByte]

That worked. So why do I need that if it already a cookie and on a post and not a get?

GET requests should also never make state changes to the system, therefore should not be required to have CSRF protection. request methods are considered "safe" if their defined semantics are essentially read-only of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.

and thank you so much @amiyatulu for sharing with us 😄 🙏

[pocket5s]

ok. yeah without documentation that is really confusing :)

[IndominusByte]

I'm sorry for the inconvenience I will fix the documentation later thank you @pocket5s 🙏

[fredrare]

Check it out: https://stackoverflow.com/questions/34782493/difference-between-csrf-and-x-csrf-token An alternative approach (called the "Cookie-to-header token" pattern) is to set a Cookie once per session and the have JavaScript read that cookie and set a custom HTTP header (often called X-CSRF-TOKEN or X-XSRF-TOKEN or just XSRF-TOKEN) with that value. Any requests will send both the header (set by Javascript) and the cookie (set by the browser as a standard HTTP header) and then the server can check that value in the X-CSRF-TOKEN header matches the value in the cookie header. The idea being that only JavaScript run on the same domain would have access to the cookie, so JavaScript from another domain couldn't set this header to the right value (assuming the page is not vulnerable to XSS that would give access to this cookie). Even fake links (e.g. in a phishing email) would not work either, as even though they would appear to come from the right domain, only the cookie will be set but not X-CSRF-TOKEN header.

Thank you very much. This is exactly what I needed for it to work.