Page MenuHomePhabricator

Update JsonConfig for AuthManager
Closed, ResolvedPublic

Description

The issue here is that API action=login won't reliably continue working in an AuthManager world. Options include:

  • Using OAuth or BotPasswords instead for your remote access, which will continue working.
  • Creating your own custom OAuth-like SessionProvider for your remote access.
  • Figuring out some way to do the remote access that isn't requiring authenticated API requests to a remote wiki.

If you pick BotPasswords as the solution, it won't necessarily even need any code changes. Just some manual work to set up BotPasswords on the account used for the remote access then a configuration change to update the username and password.

Related Objects

Event Timeline

Anomie created this task.May 11 2016, 10:16 PM
Restricted Application added a subscriber: Zppix. · View Herald TranscriptMay 11 2016, 10:16 PM
demon raised the priority of this task from Normal to High.May 31 2016, 4:13 PM
Tgr added a subscriber: jcrespo.May 31 2016, 4:44 PM

Per mail discussion with Yuri, I'll enable bot passwords on zerowiki so he can switch to bot passwords. That will require creating a bot_password table on zerowiki (ping @jcrespo; per your earlier comment (comment #6 here) this does not need DBA attention, so I'll do it, just making sure you are aware).

Sadly, policy had to change due to security concerns: https://wikitech.wikimedia.org/wiki/Schema_changes#What_is_not_a_schema_change

The table can be created unattended, but requires a blocking task to be done beforehand.

@Tgr, I assume this private data (sorry, I do not know/remember the context)?

I can see that zerowiki is already a private wiki. Is there a chance, even remote, that this table could be created on a public wiki in the future?

Change 291954 had a related patch set uploaded (by Jcrespo):
Add bot_password as a private table

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

Tgr added a comment.EditedMay 31 2016, 5:09 PM

@jcrespo: Yes, the table contains private data (password hashes). There are no plans to create it anywhere else, but the normal (single sign-on) WMF wikis already have a shared bot_password table (since January), on metawiki. Also, it is not inconceivable that some public-but-not-SUL wiki will need it in the future.

Ok, committing that now. In this particular case, this is not a blocker since zero is already fully filtered, but normally it would require a commit + puppet deploy + sanitarium mysql restart.

Change 291954 merged by Jcrespo:
Add bot_password as a private table

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

The table is actually called bot_passwords.

Change 291956 had a related patch set uploaded (by Jcrespo):
Change filter to the actual real name: bot_passwords, plural

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

Change 291956 merged by Jcrespo:
Change filter to the actual real name: bot_passwords, plural

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

Mentioned in SAL [2016-05-31T22:38:03Z] <tgr> running "mwscript sql.php --wiki=zerowiki /srv/mediawiki/php-1.28.0-wmf.4/maintenance/archives/patch-bot_passwords.sql" for T135074

Change 292053 had a related patch set uploaded (by Gergő Tisza):
Enable bot passwords on zerowiki

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

Change 292053 merged by jenkins-bot:
Enable bot passwords on zerowiki

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

Change 292951 had a related patch set uploaded (by Gergő Tisza):
Create zeroscript grant group for zerowiki

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

Change 292951 merged by jenkins-bot:
Create zeroscript grant group for zerowiki

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

Mentioned in SAL [2016-06-06T16:39:49Z] <tgr> PrivateSettings changes were for T135074

Yurik closed this task as Resolved.Jun 6 2016, 11:46 PM
Yurik claimed this task.

Deployed again in the evening SWAT. Hope its ok now.