Does Panda avoid race conditions on its anti-forgery token?

[rtyley]

We fixed an re-authentication issue in play-googleauth back in 2018, the issue also looks like it may affect pan-domain-authentication, to some extent:

When authenticating, the OAuth process requires that we send an anti-forgery token when redirecting to Google, and then verify that token when it comes back - in Panda, we use a random string and store it in the panda-antiForgeryToken cookie before redirecting to Google:

pan-domain-authentication/pan-domain-auth-play/src/main/scala/com/gu/pandomainauth/action/Actions.scala

Lines 131 to 135 in 7c182f8

	def sendForAuth(implicit request: RequestHeader, email: Option[String] = None) = {
	val antiForgeryToken = OAuth.generateAntiForgeryToken()
	OAuth.redirectToOAuthProvider(antiForgeryToken, email)(ec) map { res =>
	val originUrl = request.uri
	res.withCookies(cookie(ANTI_FORGERY_KEY, antiForgeryToken), cookie(LOGIN_ORIGIN_KEY, originUrl))

...when Google redirects back to us, we check if the anti-forgery token we've been called with matches the value we've stored in the panda-antiForgeryToken cookie:

pan-domain-authentication/pan-domain-auth-play/src/main/scala/com/gu/pandomainauth/action/Actions.scala

Lines 170 to 173 in cf7f3fb

	token <- decodeCookie(ANTI_FORGERY_KEY)
	originalUrl <- decodeCookie(LOGIN_ORIGIN_KEY)
	} yield {
	OAuth.validatedUserIdentity(token)(request, ec, wsClient).map { claimedAuth =>

This can experience problems if the user has many browser windows open - if all browser windows decide to reauthenticate at the same time, they will all choose different random values for panda-antiForgeryToken, each overriding the cookie, and thus when Google redirects back to us, the validation will fail.