[Bug]: unauthenticated abuse reports don't hit the throttle

[ioanarusiczki]

What happened?

I'm trying to test a couple of throttles on -dev for Fastly

I tried from AMO dev frontend, without authentication, and after 20 + attempts I've noticed that I can continue sending reports.

So I tried the following: sent 20+ requests from https://httpie.io/app for https://addons-dev.allizom.org/api/v5/abuse/report/addon/?lang=en-US with a Session id -> I get a 429 {"detail": "Request was throttled. Expected available in 85984 seconds."} Once I remove the authentication I can continue sending new reports.

Same is reproducible on -stage.

What did you expect to happen?

I should hit a 429 without authentication too.

Is there an existing issue for this?

• [X] I have searched the existing issues

┆Issue is synchronized with this Jira Task

[diox]

Weird that it would happen on stage - can't be related to fastly if that's the case - need to investigate.

[diox]

@ioanarusiczki If you are testing from a third party service like https://httpie.io/app that would explain the problem: there is no guarantee they'd be using the same IP for all requests. You can see the IP used by making a request to https://addons-dev.allizom.org/services/client_info and looking at the REMOTE_ADDR (it's not enabled on stage, but it can confirm that httpie.io is not using the same IP for all requests)

[ioanarusiczki]

I used to test this making unauthenticated requests with abuse report add-on endpoint from Postman and I remember hitting throttle but I left third party apps aside and tried using the frontend:

• 20 reports on a user -> I am hitting the throttle

• then I could not continue reporting a rating or a collection because I hit the throttle after the 20+ reports on the user

But when I try reporting an extension or a theme I can continue reporting. Same scenario applied on stage has the same results so I think the problem is only with the addon abuse reports endpoint when user is unauthenticated.

[diox]

We chatted about this and discovered it was caused by extensions.addonAbuseReport.url not being set correctly.

Digging further though:

• On dev, throttling does seem broken atm specifically for services.addons-dev.allizom.org requests only. Probably related to Fastly changes, need to investigate more. It's possible we're not passing the REMOTE_ADDR correctly, or that the cache is simply separate for services endpoint (so submitting abuse against other types would not count towards the limit for submitting abuse against add-ons).
• Everywhere, for add-on abuse only, sometimes we get "An unexpected error occurred" instead of the "Request was throttled" error, but the report isn't posted anyway. That's a minor UX issue, probably related to how we send the report through Firefox sendAbuseReport API.

[diox]

With https://github.com/mozilla/addons/issues/14929 fixing the first item from my comment above we should be ok now.

[ioanarusiczki]

Verified on -dev and filed the other problem https://github.com/mozilla/addons/issues/14959

I see the 429 with browser toolbox