User receiving HTTP Status 403 error Forbidden CSRFValidationFilter

We have recently upgraded to version 10.0.4 after which a user using macros to update assignees is receiving the following error : 

HTTP Status 403

— Forbidden

CSRFValidationFilter: Token provided via HTTP Request and via Cookie are not equals so we block the request !

The server understood the request but refuses to authorize it.

PPM Web Container

We have isolated the issue to be on their particular machine. 

The user has already taken the following steps to try to mitigate the issue : 

  1. Cleared history and cache/cookies. 
  2. Noticed similarities in the errors occurring. When running large batches of tickets the first 5 tickets error out, the next ticket saves correctly, and the next 4 error out. Every ticket after that, no matter how large the amount I’m trying to clear and save, will save correctly.
  3. Compared the url when opening the page with the macro and after a reload and/or after a clear and save and they are identical. They don’t see anything in the url that might be causing this.
  4. They are using Microsoft Edge and the browser issue has been ruled out.

Are there any other possible areas we can look into to resolve the issue ?

  • Suggested Answer

    0  

    Hi Manisha,

    If you get a CSRF error, it likely means that the macros used by the users are just replaying the HTTP POST calls to PPM that were initially recorded, instead of interacting with the PPM UI. As a result, the recorded POST messages will include CSRF Tokens parameters that was only valid at the time of the recording, and trying to re-submit them later in a different session will cause this error.

    I don't really have a solution for that - you're not supposed to re-submit old CSRF token - this is a protection mechanism that protects PPM users again CSRF attack, so you don't want to disable this.

    I see two possible solutions:

    1) Change the macro (or eventually use a different macro tool) that would click UI elements in a browser instead of just replaying POST HTTP requests.

    2) Update the macro script to read the new CSRF token value in their active session (you can read the value from the ppm CSRF cookie for example, or can find it in the source of the web page that's about to submit the POST request), and use that value in the CSRF parameter of the replayed POST message instead of the recorded outdated one. But whether that's possible and how to do that depends on the macro tool used, and unfortunately that's not something I can help with.