Closed AlexandraMoga closed 2 years ago
We tried to do that but the new API doesn't have the same bypasses yet so it's a bit annoying. Instead, we want to add a bypass mechanism directly in the throttle classes so that it applies to everything automatically. (And we can probably keep the existing code to bypass throttling on ratings/old signing API for now)
I gave the new API:BypassThrottling
permission to the 2 groups mentioned, and started using that permission instead of the previously existing ones to bypass rate limiting everywhere on the site. And re-activated rate limiting on dev.
I've verified the new permission to successfully bypass the following throttles:
Without the permission, throttling still applies as before.
@diox
I tested the abuse reports throttles on -stage a month ago when I was writing a test case. I remembered something and checked it again with -dev:
I can send with Postman using the APIs 20 mixed requests (to report a user or an addon , authenticated with Session ID or anonymous ) then I hit the 429, Too Many requests.
Then if I try it using a browser (same PC) I can send 20 more reports for addons/users.
Should I receive a 429 per IP address after the first 20 attempts ?
Yeah it should be 20 reports per IP per day regardless of how they were posted. If you are sure this is using the same IP (no proxy/VPN/etc) then please file an issue.
@diox Just for the record, I've tried the following method to test the API throttling for abuse reports (no proxy/VPN on):
user_abuse
rate limit (recorded in this activity log)Reporting add-on for abuse via firefox failed: Error: Error submitting abuse report
which indicates that the abuse report was not posted; I've checked the admin abuse reports and there was indeed no entry created for this attempt; I've checked the activity logs and I found an ip_abuse
entry for the userip_abuse
entry as wellThere is something I've noticed though: user_abuse
throttles are set for 24 hours while IP throttles seem to last only for ~ 3 hours (I don't have the exact time because I started counting a bit later after the requests were sent and than I was already at a 2.3 hours waiting time).
Hope this helps and if @ioanarusiczki arrives to different results we can compare our findings.
Both throttles should last 24 hours. However, something to keep in mind when testing on dev: cache will be reset at each deploy! So depending on what was happening on dev when you were testing that may have had an impact.
Both throttles should last 24 hours. However, something to keep in mind when testing on dev: cache will be reset at each deploy! So depending on what was happening on dev when you were testing that may have had an impact.
I was testing on stage
@diox @AlexandraMoga
I repeated my testing on AMO stage. I sent using Postman 20 consecutive requests for an addon using a Session id -> after 20 requests with https://addons.allizom.org/api/v5/abuse/report/addon/ I hit the throttle: "detail": "Request was throttled. Expected available in 83747 seconds."
Then authenticated with the same user I tried to send a user abuse report from FF -> I cannot because I get the "Request was throttled, Expected available in 83657 seconds." Then I tried to send addon abuse reports. In this case, I can still send them .
I'm wondering if I'm doing something wrong when I set up the abuse reports for -stage env. ? Yet, if I check the admin the addon reports were sent from the browser.
Then authenticated with the same user I tried to send a user abuse report from FF -> I cannot because I get the "Request was throttled, Expected available in 83657 seconds."
When sending an abuse report from FF, that shouldn't use the authentication AFAIK. So if you get throttled at this point, this must be because of the IP - meaning everything is working as expected.
Then I tried to send addon abuse reports. In this case, I can still send them .
What do you mean by that exactly ? After waiting ?
@diox
What do you mean by that exactly ? After waiting ?
Maybe the gif would help, I'm into the same browser and I hit the 429 with Postman , then I tried from an AMO page.
What's the value for extensions.abuseReport.url
in your about:config
?
@diox https://services.addons.allizom.org/api/v4/abuse/report/addon/ extensions.abuseReport.amoDetailsURL is https://services.addons.allizom.org/api/v4/addons/addon/ extensions.webapi.testing is true (I turned it false by mistake right before making the gif)
I also checked with Browser Toolbox , after I tried again, I see the api responding
Ok. Would be interesting to test entirely with postman with services.addons.mozilla.org - trying various things until we can get simpler steps to reproduce that don't involve using the browser.
@diox Ok, I'll try with https://services.addons.allizom.org/api/v4/abuse/report/addon/
Describe the problem and steps to reproduce it:
Currently add-ons submission and API throttling is enabled only on stage. When an issue that affects this functionality is closed, we usually have to wait until the code lands in stage to be able to verify it. By enabling rate limiting on -dev, we can have such issues tested earlier.
As far as I'm aware, we currently have the following throttles:
Ratings:BypassThrottling
to a user - see https://github.com/mozilla/addons-server/pull/17673I've already raised this issue to @diox on slack and, if everyone else agrees, we can re-enable throttling on -dev.