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, https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/throttle.php 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: https://meta.wikimedia.org/wiki/XFF_project

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: https://www.mediawiki.org/wiki/Special:OAuthListConsumers/view/cc03c438ffef19f19b7d60a952327451

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 en.wiki), 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

https://gerrit.wikimedia.org/r/233860

See also T110249 and T110254.

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

https://gerrit.wikimedia.org/r/233860