Skip to content

Draft: Guard ArkoseLabs challenge behind a user-agent check

Paul Gascou-Vaillancourt requested to merge arkose-labs-captcha-user-agent-guard into master

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

  1. Export the GITLAB_QA_USER_AGENT environment variable.

    export GITLAB_QA_USER_AGENT="GITLAB_QA_USER_AGENT"

  2. In the same terminal tab, restart your GDK.

    gdk restart

  3. Sign out of your test instance and navigate to the sign-in page.

  4. 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.

  5. In the Network tab, spoof your User agent to whatever you've exported as the GITLAB_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.

Edited by Paul Gascou-Vaillancourt

Merge request reports