github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 21:59:09 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #1698] HTTP Basic Auth not working #6777

New Issue
Closed
opened 2026-04-25 15:43:06 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-25 15:43:06 -05:00
Owner
Copy Link

Originally created by @jln-brtn on GitHub (Oct 19, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1698

Originally assigned to: @jln-brtn on GitHub.

Describe the Bug

According to the discussion #1682 , using the Basic Auth authentication failed in some situation, while it shouldn't. The user is therefor redirected to the pangolin login page.
However, it's working with Curl and Postman. The first analysis lead to an issue related to the browser use.
I'm investigating this issue.

Environment

  • OS Type & Version: Ubuntu 22.04
  • Pangolin Version: 1.11.0
  • Gerbil Version: 1.2.2
  • Traefik Version: 3.5.3

To Reproduce

  • Activate the Basic Auth for a resource
  • Try to reach this resource with the credential used
  • The user is redirected to the pangolin login page

Expected Behavior

  • The user should be able to reach the resource
Originally created by @jln-brtn on GitHub (Oct 19, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1698 Originally assigned to: @jln-brtn on GitHub. ### Describe the Bug According to the discussion #1682 , using the Basic Auth authentication failed in some situation, while it shouldn't. The user is therefor redirected to the pangolin login page. However, it's working with Curl and Postman. The first analysis lead to an issue related to the browser use. I'm investigating this issue. ### Environment - OS Type & Version: Ubuntu 22.04 - Pangolin Version: 1.11.0 - Gerbil Version: 1.2.2 - Traefik Version: 3.5.3 ### To Reproduce - Activate the Basic Auth for a resource - Try to reach this resource with the credential used - The user is redirected to the pangolin login page ### Expected Behavior - The user should be able to reach the resource
GiteaMirror commented 2026-04-25 15:43:08 -05:00
Author
Owner
Copy Link

@jln-brtn commented on GitHub (Oct 19, 2025):

The problem has been identified: Browsers and some HTTP libraries do not send the Authorization header unless explicitly challenged.

This behavior is described in RFC 7617 :

Upon receipt of a request for a URI within the protection space that lacks credentials, the server can reply with a challenge using 401 (Unauthorized) status code ([RFC7235], Section 3.1) and WWW-Authenticate header field ([RFC7235], Section 4.1).

For instance:

  HTTP/1.1 401 Unauthorized
  Date: Mon, 04 Feb 2014 16:50:53 GMT
  WWW-Authenticate: Basic realm="WallyWorld"

The current implementation only works with clients that include the Authorization header in the first request (like curl or Postman).
To also support browsers, the authentication flow should follow this sequence :

+------------+                                       +------------+
|            |                                       |            |
|  Browser   |                                       |   Server   |
|            |                                       |            |
+------------+                                       +------------+
       |                                                     |
       | 1. Initial request (no Authorization header)        |
       |---------------------------------------------------->|
       |                                                     |
       | 2. Server responds with 401 Unauthorized            |
       |    and "WWW-Authenticate: Basic realm=..."          |
       |<----------------------------------------------------|
       |                                                     |
       | 3. Browser prompts user for credentials             |
       |     or use the credentials in the url               |
       |                                                     |
       | 4. Re-sends request with                            |
       |    "Authorization: Basic <credentials>"             |
       |---------------------------------------------------->|
       |                                                     |
       | 5. Server validates credentials and returns 200 OK  |
       |<----------------------------------------------------|
       |                                                     |

Therefor, We need to decide which flow to adopt @oschwartz10612 :

  1. Always return 401 when no Authorization header is provided. This forces the client to supply credentials.
    Side effect: the Pangolin login page will never be reached, effectively disabling SSO login.
  2. Create a dedicated subdomain for header-based authentication. For example, if the protected domain is protected.example.com, create api.protected.example.com or protected-api.example.com. Side effect: some web applications behind the proxy that cannot handle multiple domains may experience conflicts.

If you have any other idea ?

<!-- gh-comment-id:3419693442 --> @jln-brtn commented on GitHub (Oct 19, 2025): The problem has been identified: **Browsers and some HTTP libraries do not send the Authorization header unless explicitly challenged**. This behavior is described in [RFC 7617](https://www.rfc-editor.org/rfc/rfc7617) : > Upon receipt of a request for a URI within the protection space that lacks credentials, the server can reply with a challenge using 401 (Unauthorized) status code ([[RFC7235], Section 3.1](https://www.rfc-editor.org/rfc/rfc7235#section-3.1)) and WWW-Authenticate header field ([[RFC7235], Section 4.1](https://www.rfc-editor.org/rfc/rfc7235#section-4.1)). > > For instance: > > HTTP/1.1 401 Unauthorized > Date: Mon, 04 Feb 2014 16:50:53 GMT > WWW-Authenticate: Basic realm="WallyWorld" **The current implementation only works with clients that include the `Authorization` header in the first request (like curl or Postman).** To also support browsers, the authentication flow should follow this sequence : ``` +------------+ +------------+ | | | | | Browser | | Server | | | | | +------------+ +------------+ | | | 1. Initial request (no Authorization header) | |---------------------------------------------------->| | | | 2. Server responds with 401 Unauthorized | | and "WWW-Authenticate: Basic realm=..." | |<----------------------------------------------------| | | | 3. Browser prompts user for credentials | | or use the credentials in the url | | | | 4. Re-sends request with | | "Authorization: Basic <credentials>" | |---------------------------------------------------->| | | | 5. Server validates credentials and returns 200 OK | |<----------------------------------------------------| | | ``` Therefor, We need to decide which flow to adopt @oschwartz10612 : 1. **Always return 401 when no `Authorization` header is provided.** This forces the client to supply credentials. Side effect: the Pangolin login page will never be reached, effectively disabling SSO login. 2. **Create a dedicated subdomain for header-based authentication.** For example, if the protected domain is `protected.example.com`, create `api.protected.example.com` or `protected-api.example.com`. Side effect: some web applications behind the proxy that cannot handle multiple domains may experience conflicts. If you have any other idea ?
GiteaMirror commented 2026-04-25 15:43:08 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Oct 30, 2025):

@jln-brtn I am sorry for the delay in responding to this!

I am thinking maybe we go with option 1 but we make it an optional checkbox. So if you enable header auth you can choose to select the check box to "challenge browsers" with a code. This could be in the options when you set it up with a small explanation and warning about the consequences. That way if the option is not chosen you can still use header auth with the other auth methods. What do you think?

I was also thinking that we could try to have it so in the 401 response a simple html page is returned with a link to the login page for the resource. This way the user would not get confused and would have the option to fail the login challenge and then click the link to go to the regular auth. What do you think about that?

<!-- gh-comment-id:3470160179 --> @oschwartz10612 commented on GitHub (Oct 30, 2025): @jln-brtn I am sorry for the delay in responding to this! I am thinking maybe we go with option 1 but we make it an optional checkbox. So if you enable header auth you can choose to select the check box to "challenge browsers" with a code. This could be in the options when you set it up with a small explanation and warning about the consequences. That way if the option is not chosen you can still use header auth with the other auth methods. What do you think? I was also thinking that we could try to have it so in the 401 response a simple html page is returned with a link to the login page for the resource. This way the user would not get confused and would have the option to fail the login challenge and then click the link to go to the regular auth. What do you think about that?
GiteaMirror commented 2026-04-25 15:43:09 -05:00
Author
Owner
Copy Link

@jln-brtn commented on GitHub (Oct 30, 2025):

No worries !
I completely agree with both suggestions! I’ll start implementing these changes right away and aim to share progress soon.

<!-- gh-comment-id:3470244397 --> @jln-brtn commented on GitHub (Oct 30, 2025): No worries ! I completely agree with both suggestions! I’ll start implementing these changes right away and aim to share progress soon.
GiteaMirror commented 2026-04-25 15:43:09 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Oct 30, 2025):

Sounds good thanks so much for your help!!

For the returning the 401 page let me know what you think with that. We
might need to update gerbil to be able to do this if its even possible
with traefik the more I think about it.

<!-- gh-comment-id:3470732695 --> @oschwartz10612 commented on GitHub (Oct 30, 2025): Sounds good thanks so much for your help!! For the returning the 401 page let me know what you think with that. We might need to update gerbil to be able to do this if its even possible with traefik the more I think about it.
GiteaMirror commented 2026-04-25 15:43:09 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 14, 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:3530292810 --> @github-actions[bot] commented on GitHub (Nov 14, 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.
GiteaMirror commented 2026-04-25 15:43:10 -05:00
Author
Owner
Copy Link

@jln-brtn commented on GitHub (Nov 26, 2025):

UPDATE : Development is progressing well, but given my current workload and the upcoming holiday season, completion may take a bit more time than initially expected. I’m aiming to provide an update and deliver the final version in early 2026.

<!-- gh-comment-id:3580554650 --> @jln-brtn commented on GitHub (Nov 26, 2025): _UPDATE : Development is progressing well, but given my current workload and the upcoming holiday season, completion may take a bit more time than initially expected. I’m aiming to provide an update and deliver the final version in early 2026._
GiteaMirror commented 2026-04-25 15:43:10 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Nov 26, 2025):

Thanks for the update @jln-brtn! Appreciate the help managing this feature.

<!-- gh-comment-id:3581795597 --> @oschwartz10612 commented on GitHub (Nov 26, 2025): Thanks for the update @jln-brtn! Appreciate the help managing this feature.
GiteaMirror commented 2026-04-25 15:43:10 -05:00
Author
Owner
Copy Link

@jln-brtn commented on GitHub (Dec 1, 2025):

Great news 🎉
I successfully solved this issue. Even better, I managed to include the redirection. This feature involves two modifications:

Please provide any feedback you may have.

<!-- gh-comment-id:3594093193 --> @jln-brtn commented on GitHub (Dec 1, 2025): Great news 🎉 I successfully solved this issue. Even better, I managed to include the redirection. This feature involves two modifications: - from pangolin : [https://github.com/fosrl/pangolin/pull/1951](https://github.com/fosrl/pangolin/pull/1951) - from badger : [https://github.com/fosrl/pangolin/pull/1951](https://github.com/fosrl/badger/pull/16) Please provide any feedback you may have.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#6777
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?