These secondary requests will redirect through our IAM because no session cookie is present. The IAM redirects back to the original domain with a payload so that the login session can be resumed. A new Set-Cookie header is sent in the response with the new session cookie.
This causes the framework to issue a new CSRF token (that is part of the session cookie) which is different from the old one that was already rendered into a hidden form input. The browser stores this new token and includes it when it POSTs the form. The token in the body of the request is now different from the one in the cookies, causing the CSRF check to fail.
We have tried different devices (Android, Windows, MacBook, and iPads) on different versions. The problem only occurs with Safari on iPad/MacBook running version 16.4, 16.4.1, or 16.5 beta. The problem cannot be reproduced using Chrome on iPad. Furthermore, the problem does not occur with private browsing in Safari.
Some things we ruled out:
- Same behaviour on devices managed by MDM and on open devices.
- PlayFramework version is now updated to the latest 2.8 version.
- Using a separate cookie for the CSRF token (instead of the play session cookie) does not make a difference either.
- Modifying the Cache-Control header to cache responses more aggressively or not at all does not help.
Has anyone also experienced this or similar problems?
I am observing this strange behaviour, too. When I tick the box for "Disable Caches" in the Network window of the Web Inspector, Cookies are sent to the server, always. (Tested on my Mac with Safari Version 16.4 (186184.108.40.206.22))