[06:27:28] Hi. any one here? [06:35:25] kanashimi: how can we help? [06:35:51] I have a bot in the toolserver. It uses nodejs to run the task. [06:36:02] I find that form today midnight (2019-07-26 00:01 UTC), I can't execute my bot anymore. [06:36:12] https://phabricator.wikimedia.org/T229084 [06:36:29] My bot also runs daily job on several wikis. It's very troublesome for me. [06:36:30] May someone help me? Thank you. [06:37:41] Hmm, i don't know that much about toolforge job server, hopefully someone else can help you [06:37:50] You might also try asking at #wikimedia-cloud channel [06:38:25] bawolff thank you. [08:31:06] [[Tech]]; 114.5.132.22; /* Do Wikimedia sites have sitemaps? */; https://meta.wikimedia.org/w/index.php?diff=19235306&oldid=19226928&rcid=13875037 [08:31:49] [[Tech]]; 114.5.132.22; /* Do Wikimedia sites have sitemaps? */; https://meta.wikimedia.org/w/index.php?diff=19235307&oldid=19235306&rcid=13875038 [08:31:59] [[Tech]]; Tegel; Reverted changes by [[Special:Contributions/114.5.132.22|114.5.132.22]] ([[User talk:114.5.132.22|talk]]) to last version by Lofty abyss; https://meta.wikimedia.org/w/index.php?diff=19235308&oldid=19235307&rcid=13875039 [21:28:56] Hello Everybody. I am writing an Oauth app that lets users "thank" each other through the API. It was working yesterday. But now I find that my I'm getting a "user blocked from editing error" when calling Oauth POST for thanking. I don't believe the oauth'd user or the oauth consumer app are blocked. How can I trouble shoot this further? Any help is appreciated. Thanks. [21:31:07] I guess first step - verify that the user can do thanks via the api directly without oauth [21:31:38] To see if something wrong with user or something wrong with your app [21:49:14] I have verified that the user can do thanks with API and I can do it in my dev environ. My production machine in AWS seems to be having the problem. [21:49:33] Is it possible that some AWS IP addresses are blocked from editing? [21:54:52] notconfusing: blocks are not affected by OAuth [21:55:22] so yes, that error means the IP is blocked [21:57:34] tgr: Thanks. Is there anyway to see why it's blocked? I don't mind getting another IP for my server, but I want to make sure the next IP I get from my service provider won't be blocked too. [21:58:44] there should be a block reason in the error message [21:59:36] worst case, you can ssh in and fetch /w/index.php?title=SomeTitle&action=edit and there will be a block message somewhere in the HTML [21:59:47] mwapi.error.APIError blocked: You have been blocked from editing. -- See https://en.wikipedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes." [22:00:55] not very informative. As I said. If I run the same code with the same data from my laptop it succeeds. If I run it on amazon web services it fails I get that message. [22:02:09] try action=query&meta=userinfo&uiprop=blockinfo [22:06:17] Thanks! It gave me a reason called "colocation" [22:07:03] what does this response mean? [22:07:06] {"batchcomplete":"","query":{"userinfo":{"id":0,"name":"3.222.166.26","anon":"","blockid":9051048,"blockedby":"SQL","blockedbyid":3637572,"blockreason":"{{Colocationwebhost}} ","blockedtimestamp":"2019-06-01T16:45:53Z","blockexpiry":"2022-01-01T16:45:53Z} [22:12:40] It's a template. [22:12:43] notconfusing: It says it's been blocked because it's AWS. [22:13:01] Are all AWS servers blocked? [22:13:04] https://en.wikipedia.org/wiki/Template:Colocationwebhost [22:14:00] notconfusing: I think they're meant to be, yes. That's an enwiki community decision though. [22:14:32] We have a static IP, so I guess the best way to go is to get an IP exception? [22:17:32] notconfusing, isn't that for anonymous editing only though? [22:22:48] Both the enwiki local block and the global block were placed before yesterday anyway [22:22:54] Maybe it's a hardblock? [22:23:17] 17:45, 1 June 2019 SQL talk contribs blocked 3.222.0.0/16 talk with an expiry time of 2 years, 214 days, 12 hours, 21 minutes and 36 seconds (account creation disabled) ({{Colocationwebhost}} ) [22:23:21] 20:30, 23 July 2019: Jon Kolbert (meta.wikimedia.org) globally blocked 3.222.0.0/16 (expires on 23 January 2021 at 19:30) (Open Proxy: Webhost: Contact stewards if you are affected ) [22:24:51] Can we get the hardblock removed for our oauth app? Address: 3.222.166.26 . Shall I submit a UTRS ticket? Is there a better way? [22:28:36] Thanks for helping me troubleshoot. Shall I contact stewards as the message says? [22:30:19] notconfusing, what hardblock? [22:31:59] I'm not exactly sure if it's a hardblock, but I imagine it is since it blocks a whole subnet. Just need an exception for a single address. [22:32:39] AFAIK range vs. single IP address is a completely different thing to whether a block is a hardblock? [22:33:11] notconfusing, did you fetch an action=edit page and find out what it says in the UI? [22:34:27] To me it looks like that global block is missing the 'anonymous only' flag so may affect logged-in users [22:34:36] the local block is probably fine to leave be [22:34:55] I will look at that action=edit output now. [22:35:19] It is effecting logged-in users, the users are logged in through Oauth. [22:35:39] so your options are probably either get a local admin to whitelist it (which will be a weird situation considering the local block of the range, but should be ok?), or ask a steward what they are willing to change [22:37:27] a steward might be able to make it anonymous-only perhaps, I doubt they'd be willing to get rid of it entirely, replacing it with a series of blocks such that your individual IP is excluded but the rest of the range is still blocked may be a lot of work [22:39:22] Thanks [22:40:18] and Krenair action=edit from the server shows me as blocked too. Thaks for your help. [22:40:29] notconfusing, yes but the important bit is the exact message it shows [22:40:40] if I'm right about this, it should show the *global* block, not the local one, right? [22:40:58] it being a global thing might also explain why the API error message is less helpful? [22:42:01] Krenair: exact message: https://i.imgur.com/BrO11UA.png [22:42:41] oh, right, you're affected by both in that because you sent an unauthenticated request, fun [22:43:28] you may find your browser's dev tools network tab has a function to right click a request and copy as a cURL command... you can use the -H Cookie part of that to make the request authenticated as your user [22:44:30] Ok I can put the cookie in, but in general I will be Oauthing as other users, not editing myself. [22:44:37] Which seems to be immaterial to this block. [22:46:16] yes, this is just to rule out the local block as being relevant to the logged in users [22:46:35] Ahaha, I see what you mean [22:46:50] that the oauth'd user is not themselves blocked [22:47:07] this is a particularly complicated situation [22:47:44] with two blocks involved from two different levels, different implications in each which are subtle [22:48:11] yes, thank you for taking the time to help. So I guess Im going to use the `-H cookie` approach. Show that it's just a global block, and then take that to the global stewards? [22:48:15] and with users using OAuth to come from your IP [22:48:19] sure