Draft: Guard ArkoseLabs challenge behind a user-agent check
What does this MR do and why?
Replaces the HTTP header check with a user-agent check to determine whether or not ArkoseLabs should be initialized.
Additional context
During the implementation of this new CAPTCHA challenge, we have learned that QA tests are incompatible with such challenges and that GitLab has put some mechanisms in place to bypass such challenges during automated test runs.
Our understanding was that challenges were only being shown when the X-GitLab-Show-Login-Captcha
HTTP header was set and that this header would be omitted from response headers if the user-agent matched the QA's user-agent. We made this assumption based on discussion in Slack and on this issue: !6228 (merged).
After testing this on staging, we realized that the header was not being set consistently. It seems to be only added in specific cases that prevented the new challenge from ever showing up. This made our previous attempt at guarding the challenge inefficient: !83903 (merged).
After some discussions, we've agreed that we should check the user-agent directly. The user-agent that QA tests use is unique and secret, so this should provide a consistent and safe approach of bypassing the challenge to not block test runs.
How to set up and validate locally
-
Export the
GITLAB_QA_USER_AGENT
environment variable.export GITLAB_QA_USER_AGENT="GITLAB_QA_USER_AGENT"
-
In the same terminal tab, restart your GDK.
gdk restart
-
Sign out of your test instance and navigate to the sign-in page.
-
At this point, the ArkoseLabs sign-in component should be loaded.
- You can verify this by typing something in the username field and blurring it. You should see a network request being made to
/api/v4/users/asd/captcha_check
.
- You can verify this by typing something in the username field and blurring it. You should see a network request being made to
-
In the
Network
tab, spoof your User agent to whatever you've exported as theGITLAB_QA_USER_AGENT
environment variable and refresh the sign-in page.- Blurring the username field after having typed something in it should not trigger an API request anymore.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.