Change Details

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" is a loopback on the host to the host, and a loopback to the running docker container within the container, that is not an option. Possible solutions: The options for creating an address that can be equally used both within the containers and on the host machine are as follows: 1) 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. 2) 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. * 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 would likely 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. 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.

**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" is a loopback on the host to the host, and a loopback to the running docker container within the container, 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: 1) 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. 2) 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. \* 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 would likely 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. 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.

**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" is a loopback on the host to the host, and a loopback to the running docker container within the container, that is not an option. Possible**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: 1) 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. 2) 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. \* 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 would likely 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. 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.