Properly handle reCAPTCHA denial responses
Description
https://gitlab.developers.cam.ac.uk/uis/devops/iam/activate-account/infrastructure/-/issues/88 introduced specific error codes and also included one for reCAPTCHA denial responses (which we set to 403). As part of https://gitlab.developers.cam.ac.uk/uis/devops/iam/activate-account/infrastructure/-/issues/92 it was discovered that this doesn't work properly. This task is to fix that.
Further details
In !105 (comment 1139212) it was found out that the problem lies with the fact that Cloud Armor, when returning a deny(403), doesn't include CORS headers. This means that the browser knows that it got a 403 response back, but it doesn't tell the application. Therefore, we can't check for a 403 response, and we can't reliably communicate back to the user that the request failed because of some reCAPTCHA issues.
Now technically, the user should never get a 403 response back anymore with the current implementation. That's because they can't submit the form if they don't pass the reCAPTCHA test. However, in case there's some error on our side, we should still implement something in case it does happen.
Suggestion from @mk2155:
Basically, to make sure we actually get a parseable response we'd probably need to forward low-captcha scores on to the API with an appropriate header set - then have the API send back a response to the frontend, and handle that. It's a lot more work though, so suggest we only do that as a subsequent improvement.
Although, this might not work or there might be better solutions.
Task list
Acceptance criteria
-
When reCAPTCHA check fails, user is presented with the correct error code