Page MenuHomePhabricator

API action=login is deprecated
Open, HighPublic

Description

Login via action=login was deprecated in rMW54d58ef50665: API changes for AuthManager, which landed Jan 11 2016

Password for user xxxxxxx on wiktionary:xxx (no characters will be shown):
Logging in to wiktionary:xxx as xxxxxxx
WARNING: API warning (login): Main-account login via action=login is deprecated
and may stop working without warning. To continue login with action=login, see [[Special:BotPasswords]]. To safely continue using main-account login, see action=clientlogin.

Event Timeline

Xqt created this task.Jun 14 2016, 2:12 PM
Restricted Application added subscribers: pywikibot-bugs-list, Zppix, Aklapper. · View Herald TranscriptJun 14 2016, 2:12 PM
Xqt triaged this task as High priority.Jun 14 2016, 2:13 PM

I experience the same now on dewikisource now.

jayvdb updated the task description. (Show Details)Aug 6 2016, 5:50 AM
Udo_T added a subscriber: Udo_T.Aug 6 2016, 9:19 PM
Xqt added a subscriber: Vladis13.
Xqt added a comment.Oct 29 2016, 2:16 PM

There is another message coming in front of that above:

WARNING: API warning (login): Fetching a token via action=login is deprecated. Use action=query&meta=tokens&type=login instead.
Huji awarded a token.Nov 5 2016, 12:42 AM
Huji added a subscriber: Huji.
MBH added a subscriber: MBH.Nov 8 2016, 9:44 AM
MBH added a comment.Nov 8 2016, 10:00 AM

When the old login method will be turned off?

Huji added a subscriber: Anomie.Nov 9 2016, 11:14 PM

@MaxBioHazard I am not sure. It was marked as "deprecated" in response to T110276 in rMW54d58ef50665 and I think @Anomie might be able to answer your question best.

In T137805#2778915, @MaxBioHazard wrote:

When the old login method will be turned off?

There are currently no plans to turn it off. However, if something makes the "main account" login process require anything beyond the submission of a username and password field, action=login will just fail. That's why it's deprecated outside of use with BotPasswords, which themselves were created specifically so there would be a way for action=login to reliably keep working for bots instead of requiring that all bots convert to using OAuth.

For example, if your password needs to be reset, Special:UserLogin will return a second page asking you to change your password before actually logging you in and action=clientlogin will return a response with a similar request, while action=login will just fail.

For another example, if you enable two-factor authentication[1] on the bot's account, Special:UserLogin will return a second page asking for the second factor and action=clientlogin will return a response with a similar request, while action=login will just fail.

For still another example, if failed login attempts from your IP cause a captcha to be displayed on Special:UserLogin, the process for using action=clientlogin will signal that and will indicate how to submit the captcha answer, while action=login will not be able to signal it and attempting to log in will just fail because no captcha answer can be supplied.

[1] 2FA is technically deployed already, but needs a special user right to be able to turn it on. I guess a wider deployment is stuck on T100375 and its subtasks.

There is another message coming in front of that above:

WARNING: API warning (login): Fetching a token via action=login is deprecated. Use action=query&meta=tokens&type=login instead.

That's an unrelated warning.

  • Long ago, you could log in with action=login by just providing a username and password.
  • Then it was realized this was a CSRF vulnerability, so now you have to provide a username, password, and a CSRF token to be able to log in. The only way to get this token was to hit action=login without providing a token, in which case you'd get a NeedToken response with the necessary token.
  • Some time later, all token fetching was consolidated into action=query&meta=tokens and other methods of fetching a token were deprecated.

Again, there are no plans to actually remove the ability to fetch the login token by hitting action=login and getting a NeedToken response any time soon. Someday it might be removed, if the logs behind Special:ApiFeatureUsage indicate that reasonably close to no one is hitting this warning anymore. But it has been hit 85914 times just in the past 24 hours, so that day doesn't seem like it'll be coming any time soon.

XXN added a subscriber: XXN.Nov 18 2016, 10:09 PM
Masti added a subscriber: Masti.Nov 28 2016, 7:48 PM
Dvorapa added a subscriber: Dvorapa.
Prod added a subscriber: Prod.Feb 20 2018, 6:15 AM
Restricted Application added a subscriber: Zoranzoki21. · View Herald TranscriptMar 29 2018, 11:00 AM

Now we have a lot of tests failing due to this issue

Dvorapa added a comment.EditedMay 31 2019, 10:23 AM

We can use BotPasswords to make tests pass and avoid warnings, but it would mean we have one password for Beta Cluster wikis, another password for Wikimedia wikis and another password for musicbrainz wiki

Xqt added a comment.May 31 2019, 10:31 AM

We can use BotPasswords to make tests pass and avoid warnings, but it would mean we have one password for Beta Cluster wikis, another password for Wikimedia wikis and another password for musicbrainz wiki

I see two problems there:

  • the botpasswords file does only contain tuples for different users but not for different sites
  • botpasswords are in plain text
Udo_T removed a subscriber: Udo_T.May 31 2019, 10:34 AM
Dvorapa added a comment.EditedMay 31 2019, 10:43 AM
  • the botpasswords file does only contain tuples for different users but not for different sites

We can fix this in several ways:

  • add a possibility to store different wiki farms in botpasswords file
  • create multiple environment variables like PYWIKIBOT_BOTPASSWD_WIKI, PYWIKIBOT_BOTPASSWD_BETA, PYWIKIBOT_BOTPASSWD_MB and update .travis.yml to use the one it needs ...

See also:

  • what about same username on different wiki farms ?

  • botpasswords are in plain text

It has permissions so only the author can view the file, but I'm not sure, how cross-platform this thing is

  • Wouldnt ("en", "wikipedia", "my_username", BotPassword("botpassword suffix", "bot password")) work in the password file? See LoginManager.readPassword in login.py.
    • If not, that sounds like something we should support...
  • I believe it is possible to pass the botpassword in the classic login process by using "prefix@password" as password (this is not clearly documented on mw.org but is shown after creating a botpassword).
  • I believe it is possible to pass the botpassword in the classic login process by using "prefix@password" as password (this is not clearly documented on mw.org but is shown after creating a botpassword).

It is indeed. That option was added specifically with pywikibot in mind, see T142304: Allow using a bot password with base username .

  • I believe it is possible to pass the botpassword in the classic login process by using "prefix@password" as password (this is not clearly documented on mw.org but is shown after creating a botpassword).

It is indeed. That option was added specifically with pywikibot in mind, see T142304: Allow using a bot password with base username .

Of course, but still we have different Botpassword for Beta Cluster and different for wikis, which is a thing we need to overcome somehow. I suggested to have an environment variable containing Botpassword for each wiki family we use to test (I think there are 3 or 4 of them), which needs some additional code to make it work, but it should work.

What do you do now, without BotPasswords? Have your test account have the same password everywhere?

What do you do now, without BotPasswords? Have your test account have the same password everywhere?

Ehm, yes. This is what we discussed above. It has been easy to use in tests on Travis CI

Of course, but still we have different Botpassword for Beta Cluster and different for wikis, which is a thing we need to overcome somehow. I suggested to have an environment variable containing Botpassword for each wiki family we use to test (I think there are 3 or 4 of them), which needs some additional code to make it work, but it should work.

As far as I understand, a password file can contain multiple entries to support multiple passwords for multiple usernames/sites/etc.
https://docs.travis-ci.com/user/encrypting-files/ suggests Travis supports encrypting entire files, so it should be possible to skip the environment variables altogether, and just encrypt the passwords file.

Dvorapa added a comment.EditedJun 11 2019, 8:41 PM

I see. I'm not sure I understand correctly, where the file would be located, but anyway, this seems doable.