commit 0cdfa91271c7cf348276e18d775f9766f76ae699
parent b255c55d0487f035ccd9382be433f5bc218f4c8e
Author: ms <ms@taler.net>
Date: Mon, 7 Feb 2022 17:10:39 +0100
DD 027
Diffstat:
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/design-documents/027-sandboxing-taler.rst b/design-documents/027-sandboxing-taler.rst
@@ -26,16 +26,30 @@ the remaining RESTful resources. Such RESTful resources include
the merchant instances and all the euFin accounts, both at Sandbox
and at Nexus.
+The sandbox will serve one HTTP base URL and make any service
+reachable at $baseUrl/$service. For example, the exchange base
+URL will be "$baseUrl/exchange".
+
+The sandbox allows to configure:
+
+- which host it binds to, typically localhost+port.
+- which host is being reverse proxied to the sandbox. This
+ helps to generate valid URIs of services.
+
+All the other values will be hard-coded in the preparation.
+
Open questions
==============
- How to collect the static configuration values?
+
- How to persist, at build time, the information
needed later at launch time to create the RESTful
resources?
-
-
-
-
-
+- Should we at this iteration hard-code passwords too?
+ With generated passwords, (1) it won't be possible to
+ manually log-in to services, (2) it won't be possible
+ to write the exchange password for Nexus in the conf.
+ Clearly, that's a problem when the sandbox is served
+ to the outside.
