401 error hosting wakapi on yunohost

[RedGlow]

Hello,
I'm trying to host a dockerized version of Wakapi (using sqlite) on a yunohost machine. The problem I'm encountering is that authenticated calls receive a 401 and don't recognize the user.
The current situation is:

• The host is responding ( https://wakapi.foxthesystem.space )
• I can login on the web interface using my user
• I get the setup instructions for my .wakatime.cfg file:

[settings]
api_url = https://wakapi.foxthesystem.space/api
api_key = <API KEY>

• If I try to run the CLI, it fails.

E.g., running wakatime-cli-windows-amd64.exe --today --key <API KEY> --verbose (same thing happens if I don't provide the api key and I let the cli read it from the config file), produces the following logs for wakatime-cli:

{"level":"debug","now":"2025-12-23T11:25:28+01:00","caller":"cmd/run.go:118","func":"github.com/wakatime/wakatime-cli/cmd.RunE","message":"command: today","version":"v1.132.1","os/arch":"windows/amd64"}
{"level":"error","now":"2025-12-23T11:25:28+01:00","caller":"cmd/run.go:289","func":"github.com/wakatime/wakatime-cli/cmd.runCmd","message":"failed to run command: today fetch failed: failed fetching today from api: authentication failed at \"https://wakapi.foxthesystem.space/api/users/current/statusbar/today\". body: \"401 unauthorized\"","version":"v1.132.1","os/arch":"windows/amd64"}
{"level":"debug","now":"2025-12-23T11:25:28+01:00","caller":"cmd/run.go:307","func":"github.com/wakatime/wakatime-cli/cmd.runCmd","message":"command failed with exit code 1","version":"v1.132.1","os/arch":"windows/amd64"}

And using docker container logs --follow wakapi I see:

{"time":"2025-12-23T10:25:29.358983573Z","level":"INFO","msg":"[request]","status":401,"method":"GET","uri":"/api/users/current/statusbar/today","duration":37761,"bytes":16,"addr":"82.57.190.43","user":"-"}

Yunohost puts an nginx reverse proxy in front of the docker machine; I'm not expert at all with nginx though, so I'll just copy a couple of its config files here. I also don't know how the API key is passed to the APIs: is it a header? a query string parameter? something else?

/etc/nginx/conf.d/wakapi.foxthesystem.space.conf:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    listen [::]:80;
    server_name wakapi.foxthesystem.space;

    access_by_lua_file /usr/share/ssowat/access.lua;

    include /etc/nginx/conf.d/acme-challenge.conf.inc;

    location ^~ '/.well-known/ynh-diagnosis/' {
        alias /var/www/.well-known/ynh-diagnosis/;
    }

    location / {
        return 301 https://$host$request_uri;
    }

    include /etc/nginx/conf.d/yunohost_http_errors.conf.inc;

    access_log /var/log/nginx/wakapi.foxthesystem.space-access.log;
    error_log /var/log/nginx/wakapi.foxthesystem.space-error.log;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name wakapi.foxthesystem.space;

    include /etc/nginx/conf.d/security.conf.inc;

    ssl_certificate /etc/yunohost/certs/wakapi.foxthesystem.space/crt.pem;
    ssl_certificate_key /etc/yunohost/certs/wakapi.foxthesystem.space/key.pem;

    more_set_headers "Strict-Transport-Security : max-age=63072000; includeSubDomains; preload";

    access_by_lua_file /usr/share/ssowat/access.lua;

    include /etc/nginx/conf.d/wakapi.foxthesystem.space.d/*.conf;

    include /etc/nginx/conf.d/yunohost_sso.conf.inc;
    include /etc/nginx/conf.d/yunohost_admin.conf.inc;
    include /etc/nginx/conf.d/yunohost_api.conf.inc;
    include /etc/nginx/conf.d/yunohost_http_errors.conf.inc;

    access_log /var/log/nginx/wakapi.foxthesystem.space-access.log;
    error_log /var/log/nginx/wakapi.foxthesystem.space-error.log;
}

/etc/nginx/conf.d/wakapi.foxthesystem.space.d/redirect__3.conf:

#sub_path_only rewrite ^/$ / permanent;
location / {

  proxy_pass        http://127.0.0.1:9572;
  proxy_redirect    off;
  proxy_set_header  Host $host;
  proxy_set_header  X-Real-IP $remote_addr;
  proxy_set_header  X-Forwarded-Proto $scheme;
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header  X-Forwarded-Host $server_name;
  proxy_set_header  X-Forwarded-Port $server_port;
  
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

  # Include SSOWAT user panel.
  include conf.d/yunohost_panel.conf.inc;
  more_clear_input_headers 'Accept-Encoding';
}

[muety]

Hi @RedGlow, thanks for reporting this . First of all, I assume you double-checked the API key to actually be correct, yes?

Let me give you some more details that might help you debug this issue. The wakatime-cli tool will send the API key via Authorization header in base64 encoding (e.g. Authorization: Basic bWVycnkgY2hyaXN0bWFzIQo=). Alternatively, you can also pass it as a query parameter (api_key=your_plain_text_api_key) in the request URL when manually issuing requests.

After having had a quick look at your nginx config, I suspect the SSOWhat plugin to be the cause of your trouble. I didn't get too much into detail of how it works, but it appears to contingently set the Authorization header for upstream requests (see here). This might conflict with the original request's header value. Perhaps you can dig into the different config options of that plugin and either turn it off entirely if not needed or instruct it to pass through the original header?

For debugging, you can also try to run manual requests (using cURL or your browser) with the API key included as a query param, e.g. try to GET /summary?interval=yesterday&api_key=blaahh.

[RedGlow]

@muety thanks a lot for the input and the investigation on YunoHost's sources, it really helps me narrow down the problem!

I've checked the API key with the query parameter option, and it works correctly. So I think it's really a problem of the Authorization header not being copied over towards Wakapi, or being overwritten.

I'm also inclined toward looking at SSOWat as the main reason of this problem, although it seems to be correctly configured. I've now asked further information on the YunoHost forum, to see if someone with a better understand of SSOWat and the SSO architecture of YunoHost can help me out (and if not, I guess I'll have to dig in the sources myself ;-D)

I'll update this thread when I have further information.

[RedGlow]

@muety As you can see in the forum link discussion, it was indeed an SSOWat configuration to tweak, I just didn't find the right place where to look. The problem has now been solved. Thanks for the assistance!

[muety]

Glad to hear you managed to solve this! 🙌