Addshore added a comment.
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?TASK
Tarrow added a comment.
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:
Tarrow added a comment.
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.TASK DETAILhttps://phabricator.wikimedia.org/T192365EMAIL
Tarrow added a comment.
Currently QS in the container makes a request that triggers this from the wikibase image:
Internal Server ErrorInternal Server Error[32f9c20f1d0c083a5a00a14a] /w/api.php InvalidArgumentException from line 109 of /var/www/html/includes/libs/MWCryptHash.php: Invalid key
Addshore added a comment.
In T192365#4145533, @Tarrow wrote:
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
Tarrow added a comment.
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
Addshore added a comment.
In T192365#4142367, @Tarrow wrote:
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
Tarrow added a comment.
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
Tarrow added a comment.
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
Lucas_Werkmeister_WMDE added a comment.
I just didn’t want to create this subtask with the exact same title as the parent task, feel free to improve :)TASK DETAILhttps://phabricator.wikimedia.org/T192365EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Addshore added a comment.
and connect to OAuth in Wikibase bundle
So the image itself shouldn't do this, only allow for configuration.TASK DETAILhttps://phabricator.wikimedia.org/T192365EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc:
11 matches
Mail list logo
