Redirect app and Authorization headers

RedGlow · December 26, 2025, 12:59pm

Discuss

Hello! I’m a bit unsure if this is the right category for this kind of posts, since I don’t know if the problem I’m having lies on an app (Redirect), on YunoHost’s SSO machinery, or on my specific installation ;-D.

What I am trying to do is to install a self-hosted instance of Wakapi on my YunoHost server.

I have followed the instructions to use a Docker image with an nginx reverse proxy - for this last part, I’m using the standard “redirect” app. I’ve set it up with “visitors” access, which, to my knowledge, means that no SSO authentication should handled by nginx or the SSOwat plugin itself.

Indeed, when I look at /etc/ssowat/conf.json, I find this (redirect__3 is the instance for this app):

"redirect__3.main": {
    "auth_header": false,
    "public": true,
    "uris": [
        "wakapi.foxtheystem.space"
    ],
    "users": []
}

Which should mean, to my understanding, that the Authorization header isn’t overwritten or stripped.

Wakapi/wakatime works through plugins on the IDE of choice, which invokes a CLI tool, which in turn sends an API request setting the Authorization header to a specific API key set in the plugin configuration and connected to the Wakapi/WakaTime user. When I trace the various steps in the logs, what I see is that the Authorization header doesn’t seem to reach the docker machine. What I can see in the logs of the Docker machine is something like this:

{"time":"2025-12-26T11:51:25.406553348Z","level":"INFO","msg":"[request]","status":401,"method":"POST","uri":"/api/users/current/heartbeats.bulk","duration":58842,"bytes":16,"addr":"82.57.190.43","user":"-"}

What’s interesting is the "user":"-" part at the very end, indicating that the user wasn’t recognized (the logs produced by accessing the web interface instead correctly log my user there).

The local CLI tool produces this kind of logs, also confirming that the authorization header was lost somehow on the way:

{"level":"error","now":"2025-12-26T12:48:26+01:00","caller":"cmd/run.go:289","func":"github.com/wakatime/wakatime-cli/cmd.runCmd","message":"failed to run command: sending heartbeat(s) failed: authentication failed at \"https://wakapi.foxthesystem.space/api/users/current/heartbeats.bulk\"","version":"v1.132.1","os/arch":"windows/amd64","file":"E:/sources/Suetum/FactList/Logging/BindingsLogWrapper.cs","time":1766749693.172,"plugin":"jetbrainsrider/2025.3.1 jetbrainsrider-wakatime/15.0.4","lineno":23,"file":"E:/sources/Suetum/FactList/Logging/BindingsLogWrapper.cs","time":1766749693.172,"plugin":"jetbrainsrider/2025.3.1 jetbrainsrider-wakatime/15.0.4","lineno":23}

The API itself also supports sending the API key through a query parameter; if I try that, it works correctly. I say this to exclude problems regarding the API key itself.

So, it seems to me that somewhere along the line, the Authorization header is stripped away, but I don’t know enough about the SSO mechanism of YunoHost to debug the problem further. Is there something else I can check and/or changes to the SSOWat configuration to solve this problem?

This post is also connected to my original report on the wakapi github.

Thanks a lot for any kind of input!

otm33 · December 26, 2025, 1:50pm

This may help (if you haven’t read it before…)

otm33 · December 26, 2025, 2:23pm

This may help (if you haven’t read it before…)

and

github.com/YunoHost/SSOwat

access.lua

a59b558bb


      
                  if element_is_in_table(authUser, permission["users"]) then
                      logger:debug("User "..authUser.." can access "..ngx.var.host..ngx.var.uri..uri_args_string())
                      has_access = true
                  else
                      logger:debug("User "..authUser.." cannot access "..ngx.var.uri)
                      has_access = false
                  end
              end
          end
          
          -- ###########################################################################
          --     5. CLEAR USER-PROVIDED AUTH HEADER
          --
          --   Which could be spoofing attempts
          --
          --   Apps can opt out of the auth spoofing protection using the setting
          --   'protect_against_basic_auth_spoofing' set to false if they really need to,
          --   but that's a huge security hole and ultimately should never be done...
          --
          -- ###########################################################################

RedGlow · December 26, 2025, 3:38pm

Thanks a lot, that was the solution to my problem! I saw that page of the documentation but I missed the relevant paragraph; now upon close reading, I found it. To be precise, the section “Application which provide an API”: SSO/LDAP integration | Yunohost

For future reference, what I needed to do was just to run the three commands indicated against my app (redirect__3), and now the Authorization header isn’t protected any longer. I guess this could be something to put in the configuration of the redirect app?