Skip to content

Add users allow-list to git abuse rate limit settings (DB + API)

Hinam Mehra requested to merge anti-abuse/17-create-allowlist-db-and-api into master

What does this MR do and why?

Partially resolves https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/17

  1. Adds an array column git_rate_limit_users_allowlist to the application_settings table. This will store usernames of users who will be excluded from git rate-limits set by admins. Why usernames and not user ids? This is because downstream, we will use the ApplicationRateLimiter to enforce these limits, which already has accepts a users_allowlist param, which is an array of usernames.
  2. Exposes git_rate_limit_users_allowlist as part of the /application/settings API endpoint

Database Migrations

Output of db:migrate 
main: == 20220622120219 AddUsersAllowlistToGitRateLimits: migrating =================
main: -- add_column(:application_settings, :git_rate_limit_users_allowlist, :text, {:array=>true, :default=>[], :null=>false})
main:    -> 0.0038s
main: == 20220622120219 AddUsersAllowlistToGitRateLimits: migrated (0.0041s) ========
main: == 20220628050425 AddApplicationSettingsGitUsersAllowlistMaxUsernamesConstraint: migrating 
main: -- transaction_open?()
main:    -> 0.0000s
main: -- current_schema()
main:    -> 0.0006s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- execute("ALTER TABLE application_settings\nADD CONSTRAINT app_settings_git_rate_limit_users_allowlist_max_usernames\nCHECK ( CARDINALITY(git_rate_limit_users_allowlist) <= 100 )\nNOT VALID;\n")
main:    -> 0.0019s
main: -- current_schema()
main:    -> 0.0006s
main: -- execute("ALTER TABLE application_settings VALIDATE CONSTRAINT app_settings_git_rate_limit_users_allowlist_max_usernames;")
main:    -> 0.0016s
main: == 20220628050425 AddApplicationSettingsGitUsersAllowlistMaxUsernamesConstraint: migrated (0.0137s)
Output of db:rollback 
main: == 20220628050425 AddApplicationSettingsGitUsersAllowlistMaxUsernamesConstraint: reverting 
main: -- transaction_open?()
main:    -> 0.0000s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- execute("ALTER TABLE application_settings\nDROP CONSTRAINT IF EXISTS app_settings_git_rate_limit_users_allowlist_max_usernames\n")
main:    -> 0.0024s
main: == 20220628050425 AddApplicationSettingsGitUsersAllowlistMaxUsernamesConstraint: reverted (0.0187s) 

main: == 20220622120219 AddUsersAllowlistToGitRateLimits: reverting =================
main: -- remove_column(:application_settings, :git_rate_limit_users_allowlist, :text, {:array=>true, :default=>[], :null=>false})
main:    -> 0.0032s
main: == 20220622120219 AddUsersAllowlistToGitRateLimits: reverted (0.0073s) ========

db:check-migrations

db:gitlabcom-database-testing results

How to set up and validate locally

  1. Enable the feature flag git_abuse_rate_limit_feature_flag 
bundle exec rails c
> Feature.enable(:git_abuse_rate_limit_feature_flag)

  1. Generate a Personal Access Token

  2. List the current application settings of the GitLab instance. You should see git_abuse_rate_limit_feature_flag: [] returned in the response

curl --header "PRIVATE-TOKEN: <your_access_token>" "http://localhost:3000/api/v4/application/settings"
  1. Update the value of git_abuse_rate_limit_feature_flag 
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" -d "git_rate_limit_users_allowlist[]=root" "http://localhost:3000/api/v4/application/settings"

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 Hinam Mehra

Merge request reports