[GH-ISSUE #1604] SSO auth not forwarding headers #1959

Closed
opened 2026-04-16 08:50:31 -05:00 by GiteaMirror · 10 comments
Owner

Originally created by @proofrock on GitHub (Oct 2, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1604

Describe the Bug

Hello!
first of all, thanks for a great tool. I have Pangolin with a few SSO-protected services. The problem is that if I "sniff" the request after SSO login, it doesn't contain the headers stated in the docs.

traefik/whiami gives:

Hostname: 96fed3a0cb1e
IP: 127.0.0.1
IP: ::1
IP: 172.19.0.4
RemoteAddr: 172.19.0.2:49210
GET / HTTP/1.1
Host: echo.[...]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Edg/140.0.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9,en-GB;q=0.8,it-IT;q=0.7,it;q=0.6
Cache-Control: max-age=0
Cookie: [...]
Dnt: 1
Priority: u=0, i
Referer: https://pan.[...]/
Sec-Ch-Ua: "Chromium";v="140", "Not=A?Brand";v="24", "Microsoft Edge";v="140"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 188.218.111.179
X-Forwarded-Host: echo.gercloud.cc
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: d298ac39a445
X-Real-Ip: 188.218.111.179

I am not using a bypass rule; only "Use platform SSO" is active. This happens both with the integrated auth (Badger?) and with PocketID; I know for sure that PocketID gives those information because (FWIW) until yesterday I used Cloudflare with the same pocketID, and it transmitted the headers (albeit different ones).

I have modified Traefik config to enable geoblock and rate limiting, but it shouldn't be related.

Thanks!

Environment

  • OS Type & Version: Ubuntu 24.04 + Docker
  • Pangolin Version: 1.10.3
  • Gerbil Version: 1.2.1
  • Traefik Version: v3.5.3
  • Newt Version: v1.5.1
  • Olm Version: --

To Reproduce

I just created a SSO-protected Resource that points to traefik/whoami and tested.

Expected Behavior

The one described here: https://docs.digpangolin.com/manage/access-control/forwarded-headers#supported-headers

Originally created by @proofrock on GitHub (Oct 2, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1604 ### Describe the Bug Hello! first of all, thanks for a great tool. I have Pangolin with a few SSO-protected services. The problem is that if I "sniff" the request after SSO login, it doesn't contain the headers stated in the docs. `traefik/whiami` gives: ``` Hostname: 96fed3a0cb1e IP: 127.0.0.1 IP: ::1 IP: 172.19.0.4 RemoteAddr: 172.19.0.2:49210 GET / HTTP/1.1 Host: echo.[...] User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Edg/140.0.0.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-US,en;q=0.9,en-GB;q=0.8,it-IT;q=0.7,it;q=0.6 Cache-Control: max-age=0 Cookie: [...] Dnt: 1 Priority: u=0, i Referer: https://pan.[...]/ Sec-Ch-Ua: "Chromium";v="140", "Not=A?Brand";v="24", "Microsoft Edge";v="140" Sec-Ch-Ua-Mobile: ?0 Sec-Ch-Ua-Platform: "Windows" Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: same-site Sec-Fetch-User: ?1 Upgrade-Insecure-Requests: 1 X-Forwarded-For: 188.218.111.179 X-Forwarded-Host: echo.gercloud.cc X-Forwarded-Port: 443 X-Forwarded-Proto: https X-Forwarded-Server: d298ac39a445 X-Real-Ip: 188.218.111.179 ``` I am not using a bypass rule; only "Use platform SSO" is active. This happens both with the integrated auth (Badger?) and with PocketID; I know for sure that PocketID gives those information because (FWIW) until yesterday I used Cloudflare with the same pocketID, and it transmitted the headers (albeit different ones). I have modified Traefik config to enable geoblock and rate limiting, but it shouldn't be related. Thanks! ### Environment - OS Type & Version: Ubuntu 24.04 + Docker - Pangolin Version: 1.10.3 - Gerbil Version: 1.2.1 - Traefik Version: v3.5.3 - Newt Version: v1.5.1 - Olm Version: -- ### To Reproduce I just created a SSO-protected Resource that points to `traefik/whoami` and tested. ### Expected Behavior The one described here: https://docs.digpangolin.com/manage/access-control/forwarded-headers#supported-headers
GiteaMirror added the stale label 2026-04-16 08:50:31 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Oct 17, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

<!-- gh-comment-id:3413339243 --> @github-actions[bot] commented on GitHub (Oct 17, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
Author
Owner

@v1rusnl commented on GitHub (Oct 26, 2025):

Possibly related?
https://github.com/orgs/fosrl/discussions/1502

I am also having a hard time using headers lately. Whoami shows the passed headers, but it does not work on other ressources.
Currently testing for the author of https://github.com/JellyWatchteam/JellyWatch to implement custom header support in the new Embywatch app, but using the headers when generating shareable links are also failing.

The thing is, it definitely worked in the past because I set up headers generated via shareable links for another application connected to openwebui, but at some point it stopped working.

<!-- gh-comment-id:3448648883 --> @v1rusnl commented on GitHub (Oct 26, 2025): Possibly related? https://github.com/orgs/fosrl/discussions/1502 I am also having a hard time using headers lately. Whoami shows the passed headers, but it does not work on other ressources. Currently testing for the author of https://github.com/JellyWatchteam/JellyWatch to implement custom header support in the new Embywatch app, but using the headers when generating shareable links are also failing. The thing is, it definitely worked in the past because I set up headers generated via shareable links for another application connected to openwebui, but at some point it stopped working.
Author
Owner

@sippeangelo commented on GitHub (Oct 31, 2025):

If anyone else finds this issue wondering why their auth headers are missing:

The feature was added in Badger v1.2.0. Badger is a Traefik plugin, so you must edit your Traefik config to update it.

experimental:
  plugins:
    badger:
      moduleName: "github.com/fosrl/badger"
      version: "v1.2.1" # <-- Here

I'm using Docker Compose to manage Pangolin, so I assumed a docker compose pull would update the whole stack. Unfortunately Badger needs to have its version number updated manually in the Traefik config. I'm not sure if there's a way to do the equivalent of a "latest" tag in Traefik. There's next to no documentation on the plugin system...

<!-- gh-comment-id:3472745192 --> @sippeangelo commented on GitHub (Oct 31, 2025): If anyone else finds this issue wondering why their auth headers are missing: The feature was added in Badger v1.2.0. Badger is a Traefik plugin, so you must edit your Traefik config to update it. ```traefik_config.yml experimental: plugins: badger: moduleName: "github.com/fosrl/badger" version: "v1.2.1" # <-- Here ``` I'm using Docker Compose to manage Pangolin, so I assumed a `docker compose pull` would update the whole stack. Unfortunately Badger needs to have its version number updated manually in the Traefik config. I'm not sure if there's a way to do the equivalent of a "latest" tag in Traefik. There's next to no documentation on the plugin system...
Author
Owner

@v1rusnl commented on GitHub (Oct 31, 2025):

If anyone else finds this issue wondering why their auth headers are missing:

The feature was added in Badger v1.2.0. Badger is a Traefik plugin, so you must edit your Traefik config to update it.

experimental:
plugins:
badger:
moduleName: "github.com/fosrl/badger"
version: "v1.2.0" # <-- Here
I'm using Docker Compose to manage Pangolin, so I assumed a docker compose pull would update the whole stack. Unfortunately Badger needs to have its version number updated manually in the Traefik config. I'm not sure if there's a way to do the equivalent of a "latest" tag in Traefik. There's next to no documentation on the plugin system...

Badger version itself is not the culprit at least on my side. Running 1.2.0 since June.

<!-- gh-comment-id:3472806545 --> @v1rusnl commented on GitHub (Oct 31, 2025): > If anyone else finds this issue wondering why their auth headers are missing: > > The feature was added in Badger v1.2.0. Badger is a Traefik plugin, so you must edit your Traefik config to update it. > > experimental: > plugins: > badger: > moduleName: "github.com/fosrl/badger" > version: "v1.2.0" # <-- Here > I'm using Docker Compose to manage Pangolin, so I assumed a `docker compose pull` would update the whole stack. Unfortunately Badger needs to have its version number updated manually in the Traefik config. I'm not sure if there's a way to do the equivalent of a "latest" tag in Traefik. There's next to no documentation on the plugin system... Badger version itself is not the culprit at least on my side. Running 1.2.0 since June.
Author
Owner

@proofrock commented on GitHub (Oct 31, 2025):

Oh! Ok. It's not a problem for me to update badger, but is it documented somewhere? I'd say that once installed it gets obsolete very quickly, and this is not good for a number of reasons.

<!-- gh-comment-id:3472873589 --> @proofrock commented on GitHub (Oct 31, 2025): Oh! Ok. It's not a problem for me to update badger, but is it documented somewhere? I'd say that once installed it gets obsolete very quickly, and this is not good for a number of reasons.
Author
Owner

@proofrock commented on GitHub (Oct 31, 2025):

Badger version itself is not the culprit at least on my side. Running 1.2.0 since June.

🤕 ouch

<!-- gh-comment-id:3472879423 --> @proofrock commented on GitHub (Oct 31, 2025): > Badger version itself is not the culprit at least on my side. Running 1.2.0 since June. 🤕 ouch
Author
Owner

@sippeangelo commented on GitHub (Oct 31, 2025):

Oh! Ok. It's not a problem for me to update badger, but is it documented somewhere? I'd say that once installed it gets obsolete very quickly, and this is not good for a number of reasons.

I tried to at least move it out into my Docker Compose file by configuring it through either Traefik command line arguments or environment variables, so it's easier to maintain. But it seems that Traefik completely ignores both those options, which is mildly infuriating.

I tried both --experimental.plugins.badger.moduleName=github.com/fosrl/badger --experimental.plugins.badger.version=v1.2.0 and setting TRAEFIK_EXPERIMENTAL_PLUGINS_BADGER_MODULENAME=github.com/fosrl/badger TRAEFIK_EXPERIMENTAL_PLUGINS_BADGER_VERSION=v1.2.0. Neither worked 🙄

The only option seems to be to generate traefik_config.yml through Jina templates or something, but I can't be bothered.

<!-- gh-comment-id:3472950797 --> @sippeangelo commented on GitHub (Oct 31, 2025): > Oh! Ok. It's not a problem for me to update badger, but is it documented somewhere? I'd say that once installed it gets obsolete very quickly, and this is not good for a number of reasons. I tried to at least move it out into my Docker Compose file by configuring it through either Traefik command line arguments or environment variables, so it's easier to maintain. But it seems that Traefik completely ignores both those options, which is mildly infuriating. I tried both `--experimental.plugins.badger.moduleName=github.com/fosrl/badger --experimental.plugins.badger.version=v1.2.0` and setting `TRAEFIK_EXPERIMENTAL_PLUGINS_BADGER_MODULENAME=github.com/fosrl/badger TRAEFIK_EXPERIMENTAL_PLUGINS_BADGER_VERSION=v1.2.0`. Neither worked 🙄 The only option seems to be to generate `traefik_config.yml` through Jina templates or something, but I can't be bothered.
Author
Owner

@proofrock commented on GitHub (Oct 31, 2025):

Thanks @sippeangelo! It solved for me, anyways. I can see Remote-Email and Remote-User. Let's see if @v1rusnl can retry and confirm.

The only option seems to be to generate traefik_config.yml through Jina templates or something, but I can't be bothered.

I meant: it's not a problem to do it manually. I devised an "update procedure" that I follow once a week: see the latest versions of traefik/pangolin/gerbil (I don't trust latest), and update manually. I'll just add badger to the checklist.

But I think it's not evident from the documentation that badger should be updated this way. It's pretty important, so it should be noted somewhere. If I am not missing something.

<!-- gh-comment-id:3473039659 --> @proofrock commented on GitHub (Oct 31, 2025): Thanks @sippeangelo! It solved for me, anyways. I can see `Remote-Email` and `Remote-User`. Let's see if @v1rusnl can retry and confirm. > The only option seems to be to generate traefik_config.yml through Jina templates or something, but I can't be bothered. I meant: it's not a problem to do it manually. I devised an "update procedure" that I follow once a week: see the latest versions of traefik/pangolin/gerbil (I don't trust `latest`), and update manually. I'll just add badger to the checklist. But I think it's not evident from the documentation that badger should be updated this way. It's pretty important, so it should be noted somewhere. If I am not missing something.
Author
Owner

@github-actions[bot] commented on GitHub (Nov 17, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

<!-- gh-comment-id:3539532999 --> @github-actions[bot] commented on GitHub (Nov 17, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
Author
Owner

@github-actions[bot] commented on GitHub (Dec 1, 2025):

This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.

<!-- gh-comment-id:3594044758 --> @github-actions[bot] commented on GitHub (Dec 1, 2025): This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#1959