Page MenuHomePhabricator

Create container for QuickStatements and connect to OAuth in Wikibase bundle
Closed, ResolvedPublic

Description

Create a php based container which contains the latest QS code.

Shim in some config variables so that we can point it at the wikibase install as desired at runtime

Event Timeline

and connect to OAuth in Wikibase bundle

So the image itself shouldn't do this, only allow for configuration.

I just didn’t want to create this subtask with the exact same title as the parent task, feel free to improve :)

Tarrow updated the task description. (Show Details)Apr 19 2018, 7:50 AM
Tarrow moved this task from Backlog to Doing on the User-TArrow board.Apr 19 2018, 10:11 AM
Tarrow claimed this task.Apr 19 2018, 10:39 AM
Tarrow added a comment.EditedApr 19 2018, 10:50 AM

One thing I forgot would need to happen is that somewhere we need to register (and approve) an OAuth Consumer for QuickStatements.

This should probably be part of the entrypoint script for QuickStatements but it will still need some credentials from the Wikibase to do this.

Solutions could be:

  • to talk straight to the DB
  • some shared secrets thing between containers (not sure this is possible without docker swarm)
  • hardcoded not-a-secret secrets like password

It turns out even making a consumer manually is pretty ugly. One needs to:

  • Use a maintenance script to set the user email (this is a prerequisite of the OAuth Extension)
  • Log in and propose a consumer
  • Authorise that consumer

Probably the best plan is therefore to not try and do this but instead just write documentation for a human to follow.

One thing I forgot would need to happen is that somewhere we need to register (and approve) an OAuth Consumer for QuickStatements.
This should probably be part of the entrypoint script for QuickStatements but it will still need some credentials from the Wikibase to do this.
Solutions could be:

  • to talk straight to the DB

Talking straight to the DB would be evil

  • some shared secrets thing between containers (not sure this is possible without docker swarm)

Yup, so basically this should be dealt with by the orchestration of the images, and not the images themselves

  • hardcoded not-a-secret secrets like password

ewwww

I think the hardcoded 'not-a-secret's would simply be ENV variables passed from the docker-compose.yml down to each container at runtime.

It would then be up to the user to enter a random string here instead so that it is secure. In any case:

Probably the best plan is therefore to not try and do this but instead just write documentation for a human to follow.

This would basically be manually generating a key using the UI and then putting it in the docker-compose.yml to be passed to the container at runtime.

I think the hardcoded 'not-a-secret's would simply be ENV variables passed from the docker-compose.yml down to each container at runtime.
It would then be up to the user to enter a random string here instead so that it is secure. In any case:

That would be consistent with https://github.com/wmde/wikibase-docker/blob/master/docker-compose.yml#L35 (the mysql creds)

This ticket is still not done but just to keep here updated on progress:

There is a WIP commit of the changes to wikibase-docker: https://github.com/tarrow/wikibase-docker/tree/add-qs-image

There are also changes that we probably require to go to upstream. This is because in the way docker is currently setup we need to reach the MW OAuth endpoint in two different ways:

  1. curls from Magnus' tools
  2. redirects for the user to authorize the tool to edit on their behalf

These two proposed changes can be seen at:
https://bitbucket.org/tarrow/magnustools/branch/seperate-public-oauth and D1028

Currently QS in the container makes a request that triggers this from the wikibase image:

<!DOCTYPE html><html><head><title>Internal Server Error</title></head><body><h1>Internal Server Error</h1><p>[32f9c20f1d0c083a5a00a14a] /w/api.php   InvalidArgumentException from line 109 of /var/www/html/includes/libs/MWCryptHash.php: Invalid key type: boolean<br />
Backtrace:<br />
#0 /var/www/html/includes/session/SessionProvider.php(520): MWCryptHash::hmac(string, boolean, boolean)<br />
#1 /var/www/html/extensions/OAuth/api/MWOAuthSessionProvider.php(127): MediaWiki\Session\SessionProvider-&gt;hashToSessionId(string)<br />
#2 /var/www/html/includes/session/SessionManager.php(487): MediaWiki\Extensions\OAuth\MWOAuthSessionProvider-&gt;provideSessionInfo(WebRequest)<br />
#3 /var/www/html/includes/session/SessionManager.php(190): MediaWiki\Session\SessionManager-&gt;getSessionInfoForRequest(WebRequest)<br />
#4 /var/www/html/includes/WebRequest.php(735): MediaWiki\Session\SessionManager-&gt;getSessionForRequest(WebRequest)<br />
#5 /var/www/html/includes/session/SessionManager.php(129): WebRequest-&gt;getSession()<br />
#6 /var/www/html/includes/Setup.php(762): MediaWiki\Session\SessionManager::getGlobalSession()<br />
#7 /var/www/html/includes/WebStart.php(114): require_once(string)<br />
#8 /var/www/html/api.php(38): require(string)<br />
#9 {main}<br />
</p></body></html>

I'll now dig into this to find out why it happens.

This is probably because $wgSecretKey isn't set by our docker setup because we trash the LocalSettings.php generated by install.php where this would be set.

I was correct on this. Setting $wgSecretKey has got us one step further.

I'm now tracking down why there are php warnings returned in some calls to QuickStatements api.php despite the fact that php error_reporting = 0, display_errors = off etc.

For example:

Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/html/quickstatements/public_html/quickstatements.php on line 389

Warning: file_put_contents(/var/log/quickstatements/tool.log): failed to open stream: No such file or directory in /var/www/html/quickstatements/public_html/quickstatements.php on line 368
{
    "status": "OK",
    "command": {
....

Setting $wgSecretKey has got us one step further.

A new issue should probably be created to track this as this should be fixed within our image.
Perhaps a grep for the secret from the generated localsettings to add to the custom one?

Tarrow moved this task from Doing to Review on the User-TArrow board.May 16 2018, 1:57 PM
Tarrow moved this task from Doing to Review on the Wikibase-Containers board.May 25 2018, 8:11 AM
Tarrow closed this task as Resolved.Jun 4 2018, 9:10 AM

PR Merged