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
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Tarrow | T192079 Include a connected container for Quickstatements in the default wikibase docker-compose | |||
| Resolved | Tarrow | T192365 Create container for QuickStatements and connect to OAuth in Wikibase bundle | |||
| Resolved | Tarrow | T193405 $wgSecretKey should be set in LocalSettings.php for the wikibase container | |||
| Resolved | Tarrow | T193606 Allow different internal and external URLs for Quickstatements to contact Mediawiki OAuth |
Event Timeline
Comment Actions
and connect to OAuth in Wikibase bundle
So the image itself shouldn't do this, only allow for configuration.
Comment Actions
I just didn’t want to create this subtask with the exact same title as the parent task, feel free to improve :)
Comment Actions
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
Comment Actions
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.
Comment Actions
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
Comment Actions
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.
Comment Actions
That would be consistent with https://github.com/wmde/wikibase-docker/blob/master/docker-compose.yml#L35 (the mysql creds)
Comment Actions
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:
- curls from Magnus' tools
- 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
Comment Actions
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->hashToSessionId(string)<br />
#2 /var/www/html/includes/session/SessionManager.php(487): MediaWiki\Extensions\OAuth\MWOAuthSessionProvider->provideSessionInfo(WebRequest)<br />
#3 /var/www/html/includes/session/SessionManager.php(190): MediaWiki\Session\SessionManager->getSessionInfoForRequest(WebRequest)<br />
#4 /var/www/html/includes/WebRequest.php(735): MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)<br />
#5 /var/www/html/includes/session/SessionManager.php(129): WebRequest->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.
Comment Actions
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.
Comment Actions
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": {
....Comment Actions
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?