I'm not sure how the login script works, but you should be able to workaround the main issue by calling site.login() in your script:

import pywikibot
site = pywikibot.Site()
site.login()  # add this line, make sure username and password_file are defined in user-config.py
print(len(list(site.watched_pages())))

(this way, there should be no need to call pwb.py login before running the script)

Does this error also occur if you clone mirror repos ( https://github.com/wikimedia/pywikibot.git and https://github.com/wikimedia/pywikibot-i18n.git )?

Hi @Xqt,
Do you have access to pywikibot account on toolforge? (according to https://admin.toolforge.org/tool/pywikibot you do)

In T260993#6402614, @Huji wrote:

@Dalba it seems like the only piece of that code which you need is the following:

textarea[dir='ltr']
{
  direction:ltr !important;
}

Also interesting that adding

textarea[dir='rtl'], input[dir='rtl']
{
  direction:rtl !important;
}
textarea[dir='ltr'], input[dir='ltr']
{
  direction:ltr !important;
}

to Special:MyPage/common.css (as suggested by @Nightdevil on fawiki) does fix the issue for me.

More questions ... :)

Interesting, so, in a way, Parsoid allows writing whole sections inside a title. (not that I'm complaining, just a very unrealistic case I noted).

My premise was not true. There are several other queries that also have different formats.

https://www.mediawiki.org/wiki/API:Query#Example_5:_Batchcomplete mentions https://en.wikipedia.org/w/api.php?action=query&list=allimages&ailimit=3&format=jsonfm&formatversion=2 as an example of batchcomplete.

According to T154324#4164161 this should also be resolvable in pywikibot itself and I think https://gerrit.wikimedia.org/r/c/pywikibot/core/+/531589 will do it.

I'm curious to know if e.info contains any more details. Adding the following print statement to login.py should print it:

pywikibot-core[master]
$ git diff
diff --git a/pywikibot/login.py b/pywikibot/login.py
index 3bc76619..b9bee2b2 100644
--- a/pywikibot/login.py
+++ b/pywikibot/login.py
@@ -304,6 +304,7 @@ class LoginManager(object):
         except pywikibot.data.api.APIError as e:
             error_code = e.code
             pywikibot.error('Login failed ({}).'.format(error_code
))
+            print(e.info, self.login_name, self.password)
             if error_code in self._api_error:
                 error_msg = 'Username "{}" {} on {}'.format(
                     self.login_name, self._api_error[error_code],
self.site)

(also check username and password)

In T229293#5423342, @Huji wrote:

Mine is like this:

('HujiBot', BotPassword('HujiBot', 'REDACTED'))

@Huji, are having multiple pywikibot processes running on the same machine? Maybe this is the result of a race condition between them. If so, try it with a single process per user.

In T229293#5418675, @Huji wrote:

With BotPasswords, the CSRF error was not shown when the first block was done. When a second block was attempted, I got a Login failed error. Here are some relevant portions of the log:

...
Checking 5.250.46.252
Checking 109.169.72.36
Logging in to wikipedia:fa as HujiBot@HujiBot
Checking 188.229.7.134
Checking 5.106.138.33
...
Checking 2A02:A03F:52DB:3500:51F8:75AD:3798:726C
Checking 204.14.73.69
Logging in to wikipedia:fa as HujiBot@HujiBot
ERROR: Login failed (Aborted).
Password for user HujiBot@HujiBot on wikipedia:fa (no characters will be shown):

Note that my bot successfully blocked 109.169.72.36 (and that is where the first login attempt happened and was successful); later, it tried to block 204.14.73.69 and, because each block must be preceded with a new login, it tried to log in again and failed. This is all using BotPasswords.

In T229293#5418459, @Huji wrote:

I believe it is because OAuth does not provide a way to ascertain the username associated with a consumer .. but should it matter?

Could you give BotParsswords or OAuth a try, please, and see if the same Invalid CSRF token error occurs or not?

Maybe switching to bot passwords will resolve this issue. I would suggest doing so. action=login has been long deprecated anyway.

In T229288#5376439, @gerritbot wrote:

Change 526278 merged by jenkins-bot:
[pywikibot/core@master] Add allowusertalk to the userblock options in pywikibot

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

In T228841#5360477, @Xqt wrote:

Either T113120 isn't really solved or the behaviour is different from Python 2. The fix works for Python 3.4 only since rPWBC07ce5ab6fe67.

Apparently this is not limited to python 2, there is a failure on py341 on appveyor: https://ci.appveyor.com/project/Ladsgroup/pywikibot-g4xqx/builds/26087824/job/jm5299v53hmuib2q

Could not find a way to reproduce, maybe the source is somewhere other than getCookie...

BTW, I think the error message (...limited to members of the Interface administrators group..) should be changed to complain about the required user rights, not the user group.

Thanks Umherirrender. Because of the strange translation I had not noticed that one. Sorry for that. I needed to have editsitejs right.
(Also fixed the translation on translatewiki.net)

In T222508#5179922, @gerritbot wrote:

Change 508893 merged by jenkins-bot:
[pywikibot/core@master] [bugfix] clear tokens on logout()

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

In T224366#5220554, @Dvorapa wrote:

@Dalba It still fails with 0.15.4

Werkzeug 0.15.4 is released and the upstream issue seems to have been resolved.

is not deterministic

In T213287#5212154, @KTC wrote:

For information, this is the code, and this is the command that ran the script.

In T194009#5188159, @Dvorapa wrote:

I don't like marking tasks as Upstream.

For example if the task is MediaWiki-Action-API bug and is marked with MediaWiki-Action-API and Pywikibot-tests (failing APi test).

The MediaWiki-Action-API team can think - per Upstream tag - this is not their issue.

The Pywikibot team can think - per Upstream tag - this is not their issue either

But this is both issues as MediaWiki-Action-API must fix the bug and then Pywikibot must adjust the tests to the fixed behavior

I can understand why the page is taking so long to save (it's almost 300KB), but why is it timing out when trying to blank the page? Is MW trying to generate a diff or something like that that requires processing the previous content of the page, too?