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

Loading