We recently carried out an upgrade from 4.0.x straight to 4.2.x but unfortunately the CSRF token format change in ~4.0.7 was not detected during testing which has resulted in a bunch of previously cookied users not being able to submit forms. We’re now in a situation where we can’t roll-back as the recent logins will then start failing instead.
Is there a simple way to check/validate the CSRF cookie on GETs and force a cookie update rather than wait for a POST which then results in a failure?
We’ve temporarily disabled CSRF middleware for now but this is obviously not ideal.
@beng in case this is still actual, you may want to overwrite the way the CSRF token is generated to have them identical to the Cake3 way in a self-made CsrfProtectionMiddleware. It is not ideal, but the recent changes regarding this not being retro compatible, I had the same issue as the one you mention. Better than disabling the CSRF middleware.
/**
* @inheritDoc
*/
protected function _verifyToken(string $token): bool
{
return true;
}
/**
* @inheritDoc
*/
public function createToken(): string
{
return hash('sha512', Security::randomBytes(static::TOKEN_VALUE_LENGTH), false);
}
You could create a middleware that attempts to validate the CSRF token against the new format, and issue a new token if the format isn’t correct on GET requests. This method is how the CsrfMiddleware verifies a token as being one issued by the application in the new format. If this check fails you could unset the cookie, and let the CsrfMiddleware issue a new token.