Identity verification development

For information on this feature that are not development-specific, see the feature documentation.

Feature flags

Because of the many registration paths and multiple verification stages, identity verification has several feature flags.

Before you enable these features, ensure hard email confirmation is enabled and Arkose is configured properly.

Feature flag name Description
identity_verification Turns on email verification for all registration paths
identity_verification_phone_number Turns on phone verification for medium risk users for all flows (the Arkose challenge flag for the specific flow and the identity_verification flag must be enabled for this to have effect)
identity_verification_credit_card Turns on credit card verification for high risk users for all flows (the Arkose challenge flag for the specific flow and the identity_verification flag must be enabled for this to have effect)
arkose_labs_signup_challenge Enables Arkose challenge for all flows, except the Trial and OAuth flows
arkose_labs_trial_signup_challenge Enables Arkose challenge for the Trial flow (the arkose_labs_signup_challenge flag must be enabled as well for this to have effect)
arkose_labs_oauth_signup_challenge Enables Arkose challenge for the OAuth flow

Logging

You can triage and debug issues raised by identity verification with the GitLab production logs.

View logs associated to a user and email verification

To view logs associated to the email stage for a user:

  • Query the GitLab production logs with the following KQL:

    KQL: json.controller:"IdentityVerificationController" AND json.username:replace_username_here
    

Valuable debugging information can be found in the json.action and json.location columns.

View logs associated to a user and phone verification

To view logs associated to the phone stage for a user:

  • Query the GitLab production logs with the following KQL:

    KQL: json.message: "IdentityVerification::Phone" AND json.username:replace_username_here
    

On rows where json.event is Failed Attempt, you can find valuable debugging information in the json.reason column such as:

Reason Description
invalid_phone_number Either there was a typo in the phone number, or the user used a VOIP number. GitLab does not allow users to sign up with non-mobile phone numbers.
invalid_code The user entered an incorrect verification code.
rate_limited The user had 10 or more failed attempts, so they were rate-limited for one hour.
related_to_banned_user The user tried a phone number already related to a banned user.

View Telesign SMS status update logs

To view logs of Telesign status updates for an SMS sent to a user:

  1. Get a telesign_reference_id value for an SMS sent to a specific user:

    json.message: "IdentityVerification::Phone" AND json.username:<username>`
    
  2. Search for status update logs associated with telesign_reference_id value:

    json.message: "IdentityVerification::Phone" AND json.event: "Telesign transaction status update" AND json.telesign_reference_id:replace_ref_id_value_here`
    

Status update logs include the following fields:

Field Description
telesign_status Delivery status of the SMS. See the Telesign documentation for possible status codes and their descriptions.
telesign_status_updated_on A timestamp indicating when the SMS delivery status was last updated.
telesign_errors Errors that occurred during delivery. See the Telesign documentation for possible error codes and their descriptions.

View logs associated to a user and credit card verification

To view logs associated to the credit card stage for a user:

  • Query the GitLab production logs with the following KQL:

    KQL: json.message: "IdentityVerification::CreditCard" AND json.username:replace_username_here
    

On rows where json.event is Failed Attempt, you can find valuable debugging information in the json.reason column such as:

Reason Description
rate_limited The user had 10 or more failed attempts, so they were rate-limited for one hour.
related_to_banned_user The user tried a credit card number already related to a banned user.

View logs associated with high-risk users

To view logs associated with the credit card stage for high-risk users:

  • Query the GitLab production logs with the following KQL:

    json.controller:"SubscriptionsController" AND json.action:"payment_form" AND json.params.value:"cc_registration_validation"
    

Code walkthrough

For a walkthrough and high level explanation of the code, see Identity Verification - Code walkthrough.

QA Integration

For end-to-end production and staging tests to function properly, GitLab allows QA users to bypass identity verification.

Additional resources

The Anti-abuse team owns identity verification. You can join our channel on Slack: #g_anti-abuse.

For help with Telesign: