Page MenuHomePhabricator

Add IP to the ratelimit exemptions
Closed, ResolvedPublic


The Wiki Education Foundation dashboard, ( started running into rate limit problems today, which will only get worse as more students start to use the system.

The edits are coming from many different users, but they all come from the same IP, and since many of these users are newcomers who are subject to the newbie IP-based rate limits, they trigger the rate limit. It sounds like the best way around this may be to add the dashboard to the exception config here:

Event Timeline

Ragesoss assigned this task to Tgr.
Ragesoss raised the priority of this task from to Needs Triage.
Ragesoss updated the task description. (Show Details)
Ragesoss subscribed.

Why is this assigned to @Tgr without him having commented here?

Also, it sounds to me like this should actually be forwarding the user's IP and get a TrustedXFF entry?

@Krenair: he asked me to file this on IRC.

<ragesoss> do you know if there are ip-based exemptions to the ratelimit for newbies?
<tgr> as for your original question, has the existing exceptions
<tgr> file a task with the IP range and rationale and I can push it in today's SWAT

@Krenair: can you point me to details on TrustedXFF?

I'm looking into it more, and I'm not sure that TrustedXFF fits. It's our app itself that is making these edits, using the OAuth permissions granted by the users, so it's not same as the proxy situation that is described here:

Can this be IP used by humans or other tools that use normal login, or is it only used by OAuth-based tools? What consumers use it exactly, do they do any kind of authentication, and what actions can be done with them? E.g. could a spammer use those tools to post an arbitrary message on a wiki?

XFF might or might not work, depending on the tool. T74501 has the details (it's about IP autoblocks but it's the same fundamental problem).

@Tgr: the only edits from this IP are ones for the current version of the main dashboard consumer:

It makes several different kinds of edits, but I don't think any of them are significant avenues of potential spam. It posts the content of free text entry fields on course pages (which are subpages of Wikipedia:Wiki_Ed on, but Wiki Ed staff monitors these pages regularly, as each new page is from a new instructor in our program and we touch base with each one before allowing them to continue.

There are no ways for a spammer to mass-post an arbitrary message in multiple places at once.

I can look into XFF, but that might take us a bit of time to implement. It'd be really useful to have an IP exception in the meantime.

14:23 < tgr> ragesoss: do you think you could make wikiedu dashboard set XFF headers?
14:24 < tgr> if it only does OAuth actions as immediate responses to a user doing something on a web interface, it should be relatively straightforward
14:24 < ragesoss> tgr: I assume it's possible, I'm just not sure how much developer time it will take.
14:25 < ragesoss> tgr: at this point, it's just immediate responses, but it's not going to stay that way.
14:26 < ragesoss> In some cases, for example, an instructor will authorize the dashboard to make automatic posts to student's talk pages if they haven't completed 
                  training by their class deadline, or if one of their edits has been flagged as potential plagiarism.

So it looks like an exception will be needed eventually anyway, and it is better to add it now because making the application set the XFF headers would take time and rate limiting would cause service interruptions in the meantime.

Change 233860 had a related patch set uploaded (by Gergő Tisza):
Exclude Wiki Education Foundation dashboard IP from rate limits

Change 233860 merged by jenkins-bot:
Exclude Wiki Education Foundation dashboard IP from rate limits

Krenair moved this task from To deploy to Done on the Wikimedia-Site-requests board.

We are preparing to move to a more reliable host, and it will need to change IPs. The new IP will be @Tgr, could you add that to the ratelimit exemptions? Thanks much! We're hoping to make this switch this Friday, if possible.

Needs a new ticket, this was marked resolved.