Page MenuHomePhabricator

Create a migration path for legacy bots in an AuthManager world
Closed, ResolvedPublic

Description

AuthManager is generally going to complicate non-interactive authentication. We need to provide a method for legacy bots to be able to work without needing to prompt the operator for second-factors or the like.

Options include:

  1. OAuth owner-only consumers (T87395). Disadvantage is that it requires every bot to be updated to use OAuth rather than action=login. It also requires the OAuth extension to be installed.
  2. "Bot passwords" (not terribly different from Google's application passwords) via action=login. Disadvantage is that it's yet-another thing.
  3. Somehow do T110276 in a way that action=login is backwards-compatible as long as stuff like 2-factor isn't enabled. Disadvantage is that it's impossible to guarantee the "as long as" conditions won't be changed in the future.

Current thinking is that we'll do both #1 (recommended) and #2 (easy for end users to implement).

Event Timeline

Anomie created this task.Dec 10 2015, 4:28 PM
Anomie claimed this task.
Anomie raised the priority of this task from to Normal.
Anomie updated the task description. (Show Details)
Anomie added subscribers: bd808, Aklapper, Tgr, Anomie.

Change 255488 had a related patch set uploaded (by Anomie):
Add owner-only consumers

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

Legoktm updated the task description. (Show Details)Dec 10 2015, 10:26 PM
Legoktm set Security to None.

Change 255488 merged by jenkins-bot:
Add owner-only consumers

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

jayvdb added a subscriber: jayvdb.Dec 14 2015, 12:53 AM

Change 259052 had a related patch set uploaded (by Gergő Tisza):
Revert "Add owner-only consumers"

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

Change 259052 merged by jenkins-bot:
Revert "Add owner-only consumers"

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

Change 259066 had a related patch set uploaded (by Anomie):
Add "bot passwords"

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

Can we call it what pretty much everyone else calls it, "application passwords"? Instead of "bot passwords" which sound specific to bots, when it's really not.

Anomie added a subscriber: csteipp.Dec 15 2015, 7:51 PM

When I pitched this to @csteipp before putting a lot of work into writing code for it, he was concerned that calling it "application passwords" would make people think it was ok to use this instead of OAuth for tools. Since the entire point of this is to avoid breaking existing bot code when AuthManager finally happens (otherwise we'd just tell everyone to switch to OAuth and be done with it), we decided that calling it "bot passwords" would set the right expectations.

That's also why the header for Special:BotPasswords takes pains to point out that no one should ever ask you to generate one and tell it to them, and why Gerrit change 259067 exists.

Tgr added a comment.Dec 15 2015, 9:53 PM

Also worth noting that when Google introduced OAuth and tried to dissuade users from giving out their normal password, there already was a huge ecosystem of non-OAuth-enabled apps (including some of Google's own apps). In MediaWiki, on the other hand, automated login is pretty much only used by bots and the mobile apps (their developers need to be looped into this conversation BTW).

Mobile apps aren't bots, so this task doesn't apply to them. T110276: Rewrite the login API to use AuthManager does.

Once the API changes for AuthManager are finalized, we'll make the big announcement on wikitech-l about how authentication is going to change for everyone and what their options are. I suspect mobile apps will probably want to change over to action=clientlogin (or whatever I wind up naming it) rather than making users create an account on the desktop, set up a bot password, and then put the bot password into the app for login. OTOH, they might go for OAuth instead.

When I pitched this to @csteipp before putting a lot of work into writing code for it, he was concerned that calling it "application passwords" would make people think it was ok to use this instead of OAuth for tools. Since the entire point of this is to avoid breaking existing bot code when AuthManager finally happens (otherwise we'd just tell everyone to switch to OAuth and be done with it), we decided that calling it "bot passwords" would set the right expectations.

Does anyone else call it "bot passwords"? I think it's just needlessly confusing, given that "bot" is already an overused term. Also OAuth works for Wikimedia sites, but is an extra extension that most people won't have installed (it also requires mysql/memcached, etc.).

That's also why the header for Special:BotPasswords takes pains to point out that no one should ever ask you to generate one and tell it to them, and why Gerrit change 259067 exists.

Except presumably the bot framework that doesn't support OAuth is going to say, "hey! Go to Special:BotPasswords, generate one and type it in here".

Anomie moved this task from In Dev to Needs Review on the MediaWiki-API board.Jan 4 2016, 7:01 PM

Change 259066 merged by jenkins-bot:
Add "bot passwords"

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

Dereckson added a subscriber: Dereckson.

The UI for bot passwords is clean and nice to use.

Anomie closed this task as Resolved.Jan 20 2016, 4:30 PM

Created, deployed, and announced → resolved.

What happened to Special:BotPasswords? The page is gone on Enwiki, and the login method appears to no longer work.

What happened to Special:BotPasswords? The page is gone on Enwiki, and the login method appears to no longer work.

Special:BotPasswords is part of the 1.27.0-wmf.11 release which was removed from the wikis at 2016-01-23T01:33Z due to issues with account logout processes. We have been working since then to correct these issues and 1.27.0-wmf.11 will be rolling back to the wikis with this week's deployment train (group0/testing on 2016-01-26, group1/non-wikipedia on 2016-01-27, all on 2016-01-28).

thanks bd808!

Special:BotPasswords will not be in 1.27.0-wmf.12 but is currently scheduled to return in 1.27.0-wmf.13.