Add identity_verification_settings column to application_settings table
What does this MR do and why?
Related to https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/work_items/851
There are currently several feature flags related to identity verification that need to be cleaned up. In preparation for that work, this MR adds the identity_verification_settings
column to the application_settings
table.
This is the list of feature flags related to identity verification that need to be cleaned up.
- arkose_labs
- arkose_labs_data_exchange
- ci_requires_identity_verification_on_free_plan
- credit_card_validation_daily_limit
- duplicate_phone_number_assume_high_risk
- hard_limit_daily_phone_verifications
- identity_verification
- identity_verification_credit_card
- identity_verification_phone_number
- opt_in_identity_verification
- require_identity_verification_for_old_users
- soft_limit_daily_phone_verifications
- telesign_intelligence
- unverified_account_group_creation_limit
Current settings that can be moved to the new column.
- arkose_labs_namespace
Current settings settings that are encrypted and cannot be moved to a jsonb column
- encrypted_arkose_labs_client_secret
- encrypted_arkose_labs_client_secret_iv
- encrypted_arkose_labs_client_xid
- encrypted_arkose_labs_client_xid_iv
- encrypted_arkose_labs_data_exchange_key
- encrypted_arkose_labs_data_exchange_key_iv
- encrypted_arkose_labs_private_api_key
- encrypted_arkose_labs_private_api_key_iv
- encrypted_arkose_labs_public_api_key
- encrypted_arkose_labs_public_api_key_iv
An alternative to this approach is to create a binary column and use attr_encrypted
to store all identity verification settings as an encrypted hash by passing marshal = true
in a single column.
Migrations
Up Migration:
main: == [advisory_lock_connection] object_id: 129040, pg_backend_pid: 4014950
main: == 20241001223628 AddIdentityVerificationSettingsJsonColumnToApplicationSettings: migrating
main: -- add_column(:application_settings, :identity_verification_settings, :jsonb, {:default=>{}, :null=>false})
main: -> 0.0022s
main: -- transaction_open?(nil)
main: -> 0.0000s
main: -- transaction_open?(nil)
main: -> 0.0000s
main: -- execute("ALTER TABLE application_settings\nADD CONSTRAINT check_identity_verification_settings_is_hash\nCHECK ( (jsonb_typeof(identity_verification_settings) = 'object') )\nNOT VALID;\n")
main: -> 0.0017s
main: -- execute("SET statement_timeout TO 0")
main: -> 0.0004s
main: -- execute("ALTER TABLE application_settings VALIDATE CONSTRAINT check_identity_verification_settings_is_hash;")
main: -> 0.0010s
main: -- execute("RESET statement_timeout")
main: -> 0.0004s
main: == 20241001223628 AddIdentityVerificationSettingsJsonColumnToApplicationSettings: migrated (0.0422s)
Down Migration
main: == [advisory_lock_connection] object_id: 128820, pg_backend_pid: 4017637
main: == 20241001223628 AddIdentityVerificationSettingsJsonColumnToApplicationSettings: reverting
main: -- remove_column(:application_settings, :identity_verification_settings)
main: -> 0.0023s
main: == 20241001223628 AddIdentityVerificationSettingsJsonColumnToApplicationSettings: reverted (0.0060s)
main: == [advisory_lock_connection] object_id: 128820, pg_backend_pid: 4017637
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.