Page MenuHomePhabricator

BotPasswords login fails in Pywikibot core
Closed, InvalidPublic


After applying two-factor authentication (2FA) to my account, I wanted to keep on using my collection of handy Pywikibot command line scripts without the hassle of OAuth. Following the manual guidelines at works, so long as a passwords file is created locally, in that a terminal session logs in, however pywikibot core fails to pick up the login credentials. Note that would break at the stage of getting cookies if manual login was tried rather than a passwords file. I ran a git pull yesterday for Pywikibot core, so my local version is the latest.

With the pressure to move admin accounts to using the more secure 2FA option, and the likelihood of this later rolling out for all accounts, this bug runs counter to the advice being given to volunteers for continued API access for script users.

As an example I have set up a bot password for Fæ@uploader with extensive rights including uploading files and editing pages. Pywikibot's correctly applies it, however pywikibot modules then fail to apply it:

Example at login

core fae$ python login
Logging in to commons:commons as Fæ@uploader
Logged in on commons:commons as Fæ.

core fae$ python
Python 2.7.10 (default, Jul 14 2015, 19:46:27) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywikibot
>>> site = pywikibot.getSite('commons', 'commons')
>>> print site.userinfo['name']
> < here my IP address gets displayed rather than the expected account name >

Example failure when running an upload script after appearing to correctly log in

User 'None' does not have upload rights on site commons:commons.

Further investigation shows that using with a BotPasswords account, creates a faulty cookie in pywikibot.lwp. This lacks commonswikiUserName, centralauth_Token etc. It is likely that this is the source of the problem.

Event Timeline

After digging into, I'm wondering if we should be recommending that BotPasswords is avoided. Authorizing OAuth for user accounts wanting to simply run scripts for themselves, rather than making apps for others, happens automatically without needing any human approvals. For Pywikibot, once the user has their credentials, they simply add paste them into their local, no other steps needed to get them to work.

If Pywikibot's is not going to accept BotPasswords, I suspect the same should happen for AWB and other tools, so that security is at least as good as relying on OAuth. Rather than letting this float on without resolution, it may actually be more positive and ask if any tools really need to rely on a BotPasswords solution.

If you add site.login() to your script it should log you in with the right credentials (it does for me).

FWIW, in your case, using as the username and uploader@<whatever your BotPassword is> will work. This is what my bots use.

@fæ Is this still an issue or did the .login() fix it for you?

I can reproduce the "bug" if I deliberately use a bad secretPassword, like putting (u'Valhallasw', BotPassword(u'replace-on-tools', u'mysupersecretbotpassword')) in passwordfile and follow

So @Fae it's look like you can solve your problem by using (u'Fæ', BotPassword(u'uploader', u'<whatever your BotPassword is>')) as explained by @zhuyifei1999. Is it ok ?

Closing as invalid per Fae comment. Will re-open it if it reappears.