Skip to content

Move ::Abuse workers to ::AntiAbuse bounded context

What does this MR do and why?

Related to https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/850

This MR is the first step in the refactor to move the workers that are under ::Abuse to ::AntiAbuse. The code in the ::Abuse workers has been moved to new workers with the same name in ::AntiAbuse and the ::Abuse workers perform methods have been updated to call the perform methods in ::AntiAbuse. The process to rename workers is described here.

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.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

All the workers should still behave as expected.

Abuse::TrustScoreWorker

[31] pry(main)> user = User.last
[32] pry(main)> Abuse::TrustScoreWorker.perform_async(user.id, :spamcheck, 0.5, 'correlation id')
[33] pry(main)> user.abuse_trust_scores.last
=> #<AntiAbuse::TrustScore:0x00007fb0587174f0 id: 75, user_id: 116, score: 0.5, created_at: Tue, 27 Aug 2024 21:20:16.295171000 UTC +00:00, updated_at: Tue, 27 Aug 2024 21:20:16.295171000 UTC +00:00, source: "spamcheck", correlation_id_value: "correlation id">

Abuse::SpamAbuseEventsWorker

[36] pry(main)> params = { user_id: user.id, title: 'spam title', description: 'spam desc', source_ip: '1.1.1.1', user_agent: 'UA', noteable_type: 'Issue', verdict: 'BLOCK' }
[37] pry(main)> Abuse::SpamAbuseEventsWorker.perform_async(params)
[38] pry(main)> AbuseReport.last.abuse_events
=> [#<AntiAbuse::Event:0x00007fb05b55ac40
  id: 1,
  user_id: 116,
  created_at: Tue, 27 Aug 2024 21:32:27.656198000 UTC +00:00,
  updated_at: Tue, 27 Aug 2024 21:32:27.656198000 UTC +00:00,
  abuse_report_id: 24,
  source: "spamcheck",
  category: "spam",
  metadata: {"title"=>"[FILTERED]", "verdict"=>"BLOCK", "source_ip"=>"1.1.1.1", "user_agent"=>"UA", "description"=>"[FILTERED]", "noteable_type"=>"Issue"}>]

Abuse::NewAbuseReportWorker

Executing this worker requires the abuse report reporter to be a gitlab employee and the abuse report to be category: "spam".

  1. To simulate a gitlab employee create a gitlab-com top-level group and ensure root is a member.
  2. If you tested the spam abuse events worker above, then the most recent abuse report category will already be spam.
  3. You may have to update the reported user to ensure they are active, which is the required state to be bannable.
  4. Executing the worker will result in the user getting banned and adding the auto_banned_by_abuse_report_id custom attribute.
[8] pry(main)> User.first.gitlab_employee?
=> true
[9] pry(main)> abuse_report = AbuseReport.last
[10] pry(main)> abuse_report.update!(reporter: User.first)
[11] pry(main)> Abuse::NewAbuseReportWorker.perform_async(abuse_report.id)
[12] pry(main)> abuse_report.user.banned?
=> true
[13] pry(main)> abuse_report.user.custom_attributes.by_key('auto_banned_by_abuse_report_id')
=> [#<UserCustomAttribute:0x00007f7de87526d8
  id: 143,
  created_at: Tue, 27 Aug 2024 21:51:48.977178000 UTC +00:00,
  updated_at: Tue, 27 Aug 2024 21:51:48.977187000 UTC +00:00,
  user_id: 116,
  key: "[FILTERED]",
  value: "24">]
Edited by Ian Anderson

Merge request reports

Loading