@MarcoAurelio it would be nice if you could test and confirm that my patch (r531589) can fix this issue
Fri, Aug 23
Thu, Aug 22
@Ciencia_Al_Poder I agree with you in essence. All of these checks are a side effect of the fact that we have historically allowed a user to run *one* bot script with a configuration that includes *more than one* user account (one normal account, one sysop account). This is archaic, and if it was up to me, I would immediately drop it. And I am not alone in that point of view; see T71283#1040612
I am considering to take this over after T229293 is fixed. Besides site.py is there any other place where we allow dualism?
I just confirmed that the patch above fixes the issue both using the traditional username and password based user configuration, as well as using the BotPasswords configuration.
I think I found the problem. Removing the MW tag, because this is indeed a Pywikibot bug. And my guess was on point: hard coded "sysop" values are the cause. You can find them here and here. Essentially, Pywikibot is being presumptuous that *only* sysops can block. This is wrong, and instead of checking the user group, the rights should be checked. I will submit a patch shortly, which fixes my problem and also avoids other similar problems in the future.
And here is a comparison of the rights of the "sysop" group to those my bot holds by being in both "bot" and "botdamin" groups:
This can potentially be a MediaWiki bug (such as a hardcoded "sysop" value somewhere in the API code), so I am going to add a MW tag as well.
First of all, I found out something really interesting: when I run the bot against test.wikipedia.org it works without any issues. When I run it against fa.wikipedia.org I get that Login Failed error followed by the script asking for my password.
Wed, Aug 21
Correct. Here is how I have it now:
Tue, Aug 20
No. Only one instance, run in solitude.
@Dalba I just ran this simplified bot on fawiki and ran into the same issue (of it asking me to login again):
Mon, Aug 19
@Daimona I updated these:
I agree that a DBA review would be necessary.
Sun, Aug 18
Is there a reason we are using cl_timestamp and not page_random here? The code has been using cl_timestamp since 2013 at least. In comparison, Randompage and Randomrootpage both use page_random.
Sat, Aug 17
I am not fluent in MW API, so let me ask this: is there a way to ask the API "who am i"? Or "which groups am I a part of"? Because if so, then all Pywikibot has to do is when OAuth is used it should check to make sure it is indeed authenticated using a sysop account before trying each sysop action.
Fri, Aug 16
With BotPasswords, the CSRF error is not shown.
Alright, I tried OAuth and when I was creating the consumer on meta, I made sure to check "Block and unblock users". However, when the bot gets to the point that it tries to block an IP I get this error message:
Sure, I will give OAuth a try. But first, I need someone to add my bot to the "confirmed" group on Meta.
@Sambasoccer27 can you please provide a diff link, not an oldid link? Something like https://en.wikipedia.org/w/index.php?title=Abd_el-Krim&diff=prev&oldid=906255302
Wed, Aug 14
That is my best guess. Here is an excerpt of the relevant portions of the output of my bot in one of its recent runs:
Sun, Aug 11
I did not know that if you do not specify the bot parameter it would mean the edit won't be labeled as a bot edit. Since we had both minor and notminor I just assumed we would also need notbot. I just verified that what @Antigng said is actually correct, hence marking the task as invalid.
Sat, Aug 10
Thu, Aug 8
Here is the thing tho: if we only want to allow literal strings as the first parameter, then what is the point of having set_var at all? We already can use the variable := value syntax for that.
You can query public filters like this but (a) you cannot query private filters, and (b) this would require running the query for hundreds of wikis one at a time.
Can this be merged with T170504 somehow? As a parent and child task, or some other way?
Wed, Aug 7
@Daimona, I think we should run a query to make sure no WMF wiki already uses this feature, before disabling it. Can you take the lead on that subtask?
Sat, Aug 3
Obviously, keeping this open despite the merged patch, as the patch only helps with better logging of events and the problem persists.
Thu, Aug 1
Tue, Jul 30
I did more examinations of this. My bot will issue several blocks each time I run it. The first block never causes the warning to show up; all subsequent blocks will. I will try to investigate more, but thought sharing it here could help others who may also be investigating this.
Mon, Jul 29
Sat, Jul 27
@Urbanecm yes; sorry I did not see your message due to poor inbox management.
Jul 23 2019
Jul 21 2019
Hmmm. The only case for using cuc_user_text would be if we were thinking that a user maybe renamed but CU data might not have been synced yet. But I don't think that should be the case ever since the onRenameUserSQL hook exists (since rECHU7b16c55a4a0def59a910d4bb4bead07706a23028 implemented in 2016).
Jul 20 2019
No, I don't. Here is what I get for running a check for "admin":
That was a typo (I updated the task). The issue persists.
Jul 17 2019
Jul 13 2019
I still think someone else with more experience should give this some consideration; I continue to think that the help message should be wiki-specific, and therefore it should not be handled through the code base.
https://www.mediawiki.org/wiki/Manual:Special_pages#Custom_special_pages does not provide the relevant information (for one thing, it never even mentions Special:BlankPage so for a non-technical user that help page is completely useless).
Jul 11 2019