Invalid CSRF Token (4.0 > 4.2 upgrade)

Need Help
#1

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.

Thanks.

#2

@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);
}
#3

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.