Page MenuHomePhabricator

docker-compose wdqs-frontend generates unresolvable item links in results
Closed, InvalidPublic

Description

Context

Wikibase docker bundle uses wikibase.svc as an alias for wikibase service. It is bound to port number 8181, and one can access wikibase instance locally
by navigating to http://localhost:8181, or after mapping wikibase.svc to loopback (in /etc/hosts in unix) by navigating to http://wikibase.svc:8181.

That alias wikibase.svc is used in other services in the bundle, like wdqs-frontend (https://github.com/wmde/wikibase-docker/blob/master/docker-compose.yml#L75) and wdqs (https://github.com/wmde/wikibase-docker/blob/master/docker-compose.yml#L87), to communicate with wikibase apis inside docker's internal network. That works because in the internal network, wikibase service is bound to port 80, so calling http://wikibase.svc would reach the backend successfully.

Problem

As a result of configuring WIKIBASE_HOST=wikibase.svc on wdqs and wdqs-frontend services, the urls that are created for entities in query results are mapped to the domain http://wikibase.svc/.... Those urls, when clocked on, will not resolve properly as we are visiting them externally, and wikibase.svc is there's no service listening on port 80 that can capture that server name.

Steps to reproduce

  1. check out https://github.com/wmde/wikibase-docker and boot it up with docker-compose up -d.
  2. navigate to wikibase instance http://localhost:8181 and create a property and an entity.. attach that new property to the new entity with any value.
  3. navigate to query service front-end http://localhost:8282 and run the following query (replace <new property id> with the new property id that you created in 2:
SELECT
  ?item ?itemLabel
WHERE 
{
  ?item wdt:P<new property id> ?value
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
LIMIT 10
  1. you should see your new item appearing in the results
  2. click on the item label/id in the results

Suggested next steps

  • Check whether those links in query results come from wdqs-frontend or wdqs service (who generates them and how)
  • Check if there's a reasonable way to make those links in query results resolve with the default setup. One possibility is to configuring the service generating those links with another variable that tells it what base url to use, and use it (for instance, one then can say WIKIBASE_EXTERNAL_URL=localhost:8181)

Event Timeline

Hi @Realworldobject, thanks for taking the time to report this!

Which codebase is this about? Wikidata-Query-Service? Wikibase Release Strategy? Feel free to associate a project with this task (via the Add Action...Change Project Tags dropdown). This will allow others to get notified and see this task when looking at the corresponding project workboard. Thanks!

This affects the query service portion of Wikibase specifically (wdqs-frontend). It's tempting to add Wikidata-Query-Service as a project tag, but this is more about desktop applications of Wikibase rather than Wikidata specifically.

Indeed, port 80 is hardcoded.

https://github.com/wmde/wikibase-docker/blob/master/wdqs-frontend/latest/default.conf#L8

We should define another environment variable called "WIKIBASE_PORT" that defaults to 80 (so we don't break people already using this image).

Addshore triaged this task as Medium priority.Jul 21 2019, 7:44 PM
Addshore added a project: Wikidata-Campsite.
Addshore updated the task description. (Show Details)
Addshore moved this task from Incoming to Ready to estimate on the Wikidata-Campsite board.
Addshore moved this task from Bugs to Features on the Wikibase-Docker-2017+ board.
Addshore moved this task from incoming to consider for next sprint on the Wikidata board.

Looking into T207133: SPARQL service returns entities with broken URLs, seems that we might not need to do this (customize wikibase port) at all.

We probably just need to update wikibase-docker readme on how to achieve custom urls for wdqs frontend.

@Addshore I was looking into this again, it appears that URIs on wdqs frontend are actually coming back (as seen in http responses) as full uris from wdqs service directly.

If that's the case, and if we want to allow frontend uris to resolve properly, we might need to change wdqs service itself somehow.

alaa_wmde renamed this task from wdqs-frontend can't be assigned with a port number to [investigate 4h] docker-compose wdqs-frontend generates unresolvable item links in results.Aug 27 2019, 9:08 AM
alaa_wmde renamed this task from [investigate 4h] docker-compose wdqs-frontend generates unresolvable item links in results to docker-compose wdqs-frontend generates unresolvable item links in results.
alaa_wmde updated the task description. (Show Details)
alaa_wmde moved this task from Needs Work to Ready to pick up on the Wikidata-Campsite board.
alaa_wmde updated the task description. (Show Details)

The URI returned by the query service is all down to the URI written to the query service during updating.
This is set using the WIKIBASE_HOST env var for the updater service / wherever the update runs.

You can see an example of this in the docker-compose at the top of this comment T207133#4680210

tear down the services with docker-compose down then boot them up again docker-compose up -d. note: this is seems to be required for wdqs-updater if it was run first time with a wikibase instance that had no entities yet.. so in case you had already the bundle setup and wdqs-updater running properly you might not need this step.

This step should not be needed. Starting a fresh and creating an entity, it will be added to the query service.
I think this is being confused with the issue where people start up the setup, then turn it off before making an edit, then the updater will not start properly from then on.

Addshore moved this task from Needs Work to Needs Tech Work on the Wikidata-Campsite board.

I'm going to mark this as invalid as the issue as described is to be expected with the default configuration.
When using the docker images you should configure them to your needs, and as a result you won't have the wikibase.svc concept URIs