View Issue Details

IDProjectCategoryView StatusLast Update
0006837Talerdeployment and operationspublic2021-08-24 16:23
ReporterChristian Grothoff Assigned ToMS  
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Version0.8 
Target Version0.8Fixed in Version0.8 
Summary0006837: deployment of 'master' on demo.taler.net fails with merchant authorization issue
DescriptionDuring the
demo-blue@gv:~$ taler-deployment-prepare

step, deployment fails with the error:


Password for Survey changed
Configuration failed on URL: https://backend.demo.taler.net/private/instances
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx</center>
</body>
</html>
Additional InformationThis is most likely caused by the new merchant authorization logic, which the deployment script likely does not yet support properly.
TagsNo tags attached.

Activities

Christian Grothoff

2021-04-08 10:18

manager   ~0017710

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...

Florian Dold

2021-04-08 13:34

manager   ~0017712

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 ...

Florian Dold

2021-04-08 16:27

manager   ~0017713

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.

MS

2021-06-02 08:07

reporter   ~0017939

Done.

Issue History

Date Modified Username Field Change
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
2021-06-02 08:07 MS Note Added: 0017939
2021-06-02 08:07 MS Status assigned => resolved
2021-06-02 08:07 MS Resolution open => fixed
2021-07-30 13:56 Christian Grothoff Fixed in Version => 0.8
2021-08-24 16:23 Christian Grothoff Status resolved => closed