View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006837||Taler||deployment and operations||public||2021-04-08 00:00||2021-04-08 16:27|
|Reporter||Christian Grothoff||Assigned To||MS|
|Platform||i7||OS||Debian GNU/Linux||OS Version||squeeze|
|Summary||0006837: deployment of 'master' on demo.taler.net fails with merchant authorization issue|
|Description||During the |
step, deployment fails with the error:
Password for Survey changed
Configuration failed on URL: https://backend.demo.taler.net/private/instances
<head><title>401 Authorization Required</title></head>
<center><h1>401 Authorization Required</h1></center>
|Additional Information||This is most likely caused by the new merchant authorization logic, which the deployment script likely does not yet support properly.|
|Tags||No tags attached.|
The deployment script did not expect nginx to want the 'ApiKey sandbox' header. I've removed that from nginx, then I could complete the deployment. After that, I re-enabled the auth check.
=> We should decide how to do this properly:
1) Can we adapt the deployment script to bypass nginx and talk directly to the backend?
2) Should we stop using nginx for this and only enable 'internal' auth checks inside the backend?
3) What about the default instance? We should at least protect that one better, right? Now that it can be used to delete other instances, which would trash the demo...
Looking through the relevant repos (deployment.git and taler-merchant-demos.git), it looks like the migration to token-based authentication stopped somewhere in the middle. For example, the frontends still use the old "ApiKey sandbox" header, when it should be "Bearer ...", but the deployment script creates instances with token auth.
We first need to (re-?)evaluate whether to use "token" or "external" auth for the demo merchant.
When using external auth:
[+] We can allow certain endpoints to be accessible via the sandbox token (order creation/status), and restrict others to unix domain socket only, so that people can follow along interactively with a merchant backend API tutorial while not being able to trash our demo
[-] We can't easily have frontend demos that require endpoints other than those allowed with the sandbox token (unlikely that we need that though ...)
[-] We need to adjust deployment scripts to talk directly to the backend via unix domain sockets
[o] We can't use the full functionality of the back-office SPA with demo/test, but it might be good to see whether the app still works correctly in this scenario
When using token auth:
[+] We can easily lock down access by generating a secret token when bootstrapping the test/demo environment, which is exposed as an environment variables to deployment scripts and frontend demos
[-] It's not possible anymore to provide sandbox access to only certain functionality (creating/checking orders). But for that, we could simply create a "playground" merchant backend that we additionally host on test/demo.
WDYT? I'm leaning more towards external auth.
Nevertheless, the nginx config and frontend demos should still be switched to the same secret token format that the internal token auth of the backend expects ...
||Discussed offline: We'll do token auth, but have a sandbox instance with a publicly known token, where nginx blocks access to the administrative APIs.|
|2021-04-08 00:00||Christian Grothoff||New Issue|
|2021-04-08 00:00||Christian Grothoff||Status||new => assigned|
|2021-04-08 00:00||Christian Grothoff||Assigned To||=> MS|
|2021-04-08 10:18||Christian Grothoff||Note Added: 0017710|
|2021-04-08 12:44||Christian Grothoff||Severity||block => major|
|2021-04-08 13:34||Florian Dold||Note Added: 0017712|
|2021-04-08 16:27||Florian Dold||Note Added: 0017713|