Page MenuHomePhabricator

Quickstatements should work out of the box in wikibase docker image
Open, NormalPublic8 Story Points

Description

We should have quickstatements working as it does on wikidata.org out of the box.

Currently we rely on using it's OAuth functionality to make edits. Unfortunately the setup process for the user is non-trivial and has some annoying "tricky bits" like faking having an email address for an account. The setup is described here: https://github.com/wmde/wikibase-docker/blob/master/quickstatements/README.md We've had reports from multiple people that they struggled, or missed steps from the guide etc...

Suggested Approach

  • Create a maintenance script for OAuth to generate a new consumer (see separate ticket T211568)
  • Add running this script to the entrypoint of wikibase bundle image
  • Write the credentials to a file
  • Have this file jointly mounted in both the Wikibase-Bundle container and the QS container
  • Adapt the QS entrypoint script to read the values from the file if it is present

Hints
User will need still need an email set at some point
User will need the correct permissions to manage OAuth consumers. There are already granted in LocalSettings.php.wikibase-bundle.template

Script to run from bundle is probably: php extensions/OAuth/maintenance/createOAuthConsumer.php --approve --callbackUrl $QS_PUBLIC_SCHEME_HOST_AND_PORT--callbackIsPrefix true --user Admin --name QuickStatements --description QuickStatements --version 1.0.1 --grants createeditmovepage editpage highvolume --jsonOnSuccess > /shared/qs-oauth.json

Acceptance Criteria
Quickstatements OAuth should require no user interaction by the Admin user to setup. It should behave in the same way as a user visiting the wikidata.org version sees it behave (i.e. each end user still has to approve the consumer to make edits).

Event Timeline

Addshore created this task.Sep 27 2018, 8:21 AM
Restricted Application added a project: Wikidata. · View Herald TranscriptSep 27 2018, 8:21 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
dbs added a subscriber: dbs.Nov 24 2018, 3:52 AM
Tarrow moved this task from Backlog to Features on the Wikibase-Containers board.Dec 6 2018, 8:44 AM
Tarrow triaged this task as Normal priority.Dec 6 2018, 9:28 AM
Tarrow updated the task description. (Show Details)

@Tarrow @Addshore can you please create the remaining ticket before storytime tomorrow so we can pick this up?

Tarrow updated the task description. (Show Details)Dec 10 2018, 10:02 AM
Tarrow removed Tarrow as the assignee of this task.Dec 11 2018, 3:27 PM
Addshore moved this task from incoming to in progress on the Wikidata board.Dec 19 2018, 12:47 PM
Tarrow updated the task description. (Show Details)Jan 23 2019, 4:04 PM
Tarrow removed Tarrow as the assignee of this task.Mon, Feb 4, 10:04 AM
Ladsgroup claimed this task.Tue, Feb 5, 9:18 AM
Ladsgroup added a subscriber: Ladsgroup.

Let me try it.

Restricted Application added a project: User-Ladsgroup. · View Herald TranscriptTue, Feb 5, 9:18 AM

When building it I got this error:

wikibase_1         | [5822c40de0bb67811876d3c4] [no req]   Error from line 98 of /var/www/html/extensions/OAuth/maintenance/createOAuthConsumer.php: Call to undefined method MediaWiki\Extensions\OAuth\MWOAuthConsumer::getConsumerKey()
wikibase_1         | Backtrace:
wikibase_1         | #0 /var/www/html/maintenance/doMaintenance.php(94): MediaWiki\Extensions\OAuth\CreateOAuthConsumer->execute()
wikibase_1         | #1 /var/www/html/extensions/OAuth/maintenance/createOAuthConsumer.php(130): require_once(string)
wikibase_1         | #2 {main}

It's because https://github.com/wikimedia/mediawiki-extensions-OAuth/commit/98df9d78b1fd2a4d96a01b5af7031335ce27e3b8#diff-c040382e76751693f9b9b99cbed94e4e doesn't exist in 1.32 and 1.31. Let me backport.

cherry-pick failed due to merge conflict :(((((((((((

Change 488046 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/OAuth@REL1_32] Make maintenance/createOAuthConsumer.php conform with 1.32

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

Change 488047 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/OAuth@REL1_31] Make maintenance/createOAuthConsumer.php conform with 1.31

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

Change 488046 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_32] Make maintenance/createOAuthConsumer.php conform with 1.32

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

Change 488047 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_31] Make maintenance/createOAuthConsumer.php conform with 1.31

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

Okay I tried again and the OAuth app works but it doesn't get accepted:


The file in the docker gives some insight:

{
  "created":true,
  "id":1,
  "name":"QuickStatements",
  "key":"f059491dbfe0b5baaa28feb9294665af",
  "secret":"ed544fa17affbff3b9e13990ebb98142d1112539",
  "approved":"Someone changed the attributes of this consumer as you viewed it. Please try again. You may want to check the change log."
}

I will try to see what's going on there and fix it.

Okay it seems in the maintaince script we make the context and then set the user and then MWOAuthConsumerSubmitControl::processAction() builds the context again from singleton but doesn't set the user causing the $cmr->checkChangeToken( $context, $this->vals['changeToken'] ) to fail. It's a needed feature to make sure integrity of context is intact so I don't know what to do here. Maybe we need to remove the user from the context.

Okay it seems in the maintaince script we make the context and then set the user and then MWOAuthConsumerSubmitControl::processAction() builds the context again from singleton but doesn't set the user causing the $cmr->checkChangeToken( $context, $this->vals['changeToken'] ) to fail. It's a needed feature to make sure integrity of context is intact so I don't know what to do here. Maybe we need to remove the user from the context.

Is this only breaking on a specific version of mediawiki / OAuth?

It's broken on 1.32 but I tested it on master on my native installation and it works. Let me go to 1.32 and try again on native installation.

Yup, it's broken only on 1.32 both native and docker.

'ownerOnly' key in context is different, it's 0 in one and false in the other.

Change 488449 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/OAuth@REL1_32] Backport normalization of values from master

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

Change 488450 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/OAuth@REL1_31] Backport normalization of values from master

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

Change 488450 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_31] Backport normalization of values from master

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

Change 488449 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_32] Backport normalization of values from master

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