Skip to content

Conversation

@psibean
Copy link
Contributor

@psibean psibean commented May 8, 2025

validateOnReuse behaviour was incorrect, it was always "intentionally incorrect", but it had not previously been made apparent on why this may have been problematic.

This corrects the behaviour.

The problem:

Even when validateOnReuse is set to false (its default value), it doesn't prevent validation, it only prevents an error from being thrown. This means any GET requests which expect the existing token to be used but do not include the CSRF token in the request such that getTokenFromRequest will return it, this causes an invalidation and a new token to be generated.

Up until now, this behaviour had been intentional, but this is not the desired behaviour.

This PR fixes that.

psibean added 2 commits May 9, 2025 08:39
Prior to this fix, if you set validateOnReuse to false, this only
prevented the error from being thrown, it did not actually
prevent validation from happening. This means if you were to
make a GET request without including the token in the request
and you were hoping to have the existing CSRF token included
in the response, it wasn't really possible, a new one would be
generated every time. It should not be necessary to included
the CSRF token in GET requests.

Now when validateOnReuse is false, the existing CSRF token
will be reused from the CSRF token cookie, without prior
validation. This is a semi breaking change, but it is a correction
of expected behaviour.
@psibean psibean merged commit bcaf1c3 into main May 8, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants