Problem: As follow-up to trying to solve the issues with Quickstatements OAuth in the example configuration WBS (https://phabricator.wikimedia.org/T349806#9426634) it seems clear that we need an address which can be accessed both inside of the Docker network and on the host machine for this to work. As "localhost"-based addresses are loopbacks within the Docker container, not an address to the host, so that is not an option.
Proposed solutions: The options for creating an address that can be equally used both within the containers and on the host machine are as follows:
- A local top-level domain (TLD) served by running a DNS server locally either within the Docker compose setup, or on the host machine directly. dnsmasq is an open source DNS server commonly used for this purpose, with several healthy Docker. images available. Direct host configuration of a DNS server would require the user to make direct edits to their /etc/hosts file, or to configure a local running DNS server, which we want to provide guidance for.
- A subdomain (* or multiple subdomains) on a public TLD registered to route to the loopback address of 127.0.0.1. This is something we could fairly readily provide and would provide the additional benefit of consistency in the installation, making both use and support/documentation of the example simpler and consistent between users.
Implementing addresses locally routable on both the Docker network and on the host machine would have the additional benefit of further decoupling our test suite from being Docker specific.
* A subdomain registered for each of the WBS services (e.g. wikibase.wbs-local.net, etc) along with a Docker compose running nginx instance for reverse proxying to the ports could be the best case. However a single 127.0.0.1 routed public TLD subdomain is an adequate first step which solves the Quickstatements OAuth issues while providing consistency in routing inside and outside the Docker network.
* Helpful notes from Adam: https://phabricator.wikimedia.org/T315916