github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-06 00:22:42 -05:00
Code Issues 464 Packages Projects Releases 71 Wiki Activity

[GH-ISSUE #2262] Header Authentication not working #6916

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

Originally created by @YouriStudent on GitHub (Jan 17, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2262

Describe the Bug

When adding a header authentication option to a resource it still directs to the login page instead of the resource

Environment

  • OS Type & Version: Ubuntu 22.04
  • Pangolin Version: 1.41.1
  • Gerbil Version: 1.3.0
  • Traefik Version: v3.6.5
  • Newt Version: ?
  • Olm Version: (if applicable)

To Reproduce

Create a resource,
Add authentication
add header authentication
use firefox (i used 146.0.1) to go the the resource https://username:password@myresource.example.com

When trying to set this up I first used a random generate password as username and password, maybe this breaks something....

Expected Behavior

visit the page without login screen.

Originally created by @YouriStudent on GitHub (Jan 17, 2026). Original GitHub issue: https://github.com/fosrl/pangolin/issues/2262 ### Describe the Bug When adding a header authentication option to a resource it still directs to the login page instead of the resource ### Environment - OS Type & Version: Ubuntu 22.04 - Pangolin Version: 1.41.1 - Gerbil Version: 1.3.0 - Traefik Version: v3.6.5 - Newt Version: ? - Olm Version: (if applicable) ### To Reproduce Create a resource, Add authentication add header authentication use firefox (i used 146.0.1) to go the the resource https://username:password@myresource.example.com When trying to set this up I first used a random generate password as username and password, maybe this breaks something.... ### Expected Behavior visit the page without login screen.
GiteaMirror added the stale label 2026-04-25 15:55:00 -05:00
GiteaMirror commented 2026-04-25 15:55:01 -05:00
Author
Owner
Copy Link

@K0lin commented on GitHub (Jan 18, 2026):

Code Investigation

Looking at the authentication code in server/routers/badger/verifySession.ts, I can see that the extractBasicAuth function only checks for Basic Auth credentials in the HTTP Authorization header:

function extractBasicAuth(headers: Record<string, string> | undefined): string | undefined {
    if (!headers || (!headers.authorization && !headers.Authorization)) {
        return;
    }

    const authHeader = headers.authorization || headers.Authorization;
    if (!authHeader.startsWith("Basic ")) {
        return;
    }

    // Extract base64 credentials...
}

The function does not attempt to extract credentials from the URL itself.

Why This Behavior Occurs

When a browser accesses https://user:pass@domain.com, it sends the request with credentials embedded in the URL. However, the Pangolin authentication system only looks for credentials in the Authorization header. Since browsers typically don't automatically convert URL credentials to headers for cross-origin requests (or in this case, the reverse proxy setup), the server doesn't see the authentication.

Conclusion

This appears to be working as designed rather than a bug. The Pangolin system is configured to only accept Basic Authentication via HTTP headers, which is the standard and more secure approach. URL-embedded credentials are not supported.

For example, you can try:

curl https://username:password@myresource.example.com

and it should work.

For browsers, you would need to use developer tools or a proxy to add the Authorization header manually.

Why curl Works

curl handles this differently - it automatically converts URL credentials to the proper Authorization: Basic <base64> header:

curl -H "Authorization: Basic $(echo -n 'username:password' | base64)" https://myresource.example.com

This works because curl adds the header before sending the request.

Note: I'm not affiliated with the Pangolin project maintainers. This analysis is based on code review and could be incorrect. Please consult the official documentation or wait maintainers for confirmation.

<!-- gh-comment-id:3765150211 --> @K0lin commented on GitHub (Jan 18, 2026): ## Code Investigation Looking at the authentication code in `server/routers/badger/verifySession.ts`, I can see that the `extractBasicAuth` function only checks for Basic Auth credentials in the HTTP `Authorization` header: ```typescript function extractBasicAuth(headers: Record<string, string> | undefined): string | undefined { if (!headers || (!headers.authorization && !headers.Authorization)) { return; } const authHeader = headers.authorization || headers.Authorization; if (!authHeader.startsWith("Basic ")) { return; } // Extract base64 credentials... } ``` The function does **not** attempt to extract credentials from the URL itself. ## Why This Behavior Occurs When a browser accesses `https://user:pass@domain.com`, it sends the request with credentials embedded in the URL. However, the Pangolin authentication system only looks for credentials in the `Authorization` header. Since browsers typically don't automatically convert URL credentials to headers for cross-origin requests (or in this case, the reverse proxy setup), the server doesn't see the authentication. ## Conclusion This appears to be **working as designed** rather than a bug. The Pangolin system is configured to only accept Basic Authentication via HTTP headers, which is the standard and more secure approach. URL-embedded credentials are not supported. For example, you can try: ```bash curl https://username:password@myresource.example.com ``` and it should work. For browsers, you would need to use developer tools or a proxy to add the Authorization header manually. ## Why curl Works curl handles this differently - it automatically converts URL credentials to the proper `Authorization: Basic <base64>` header: ```bash curl -H "Authorization: Basic $(echo -n 'username:password' | base64)" https://myresource.example.com ``` This works because curl adds the header before sending the request. **Note**: I'm not affiliated with the Pangolin project maintainers. This analysis is based on code review and could be incorrect. Please consult the official documentation or wait maintainers for confirmation.</content>
GiteaMirror commented 2026-04-25 15:55:01 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 2, 2026):

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:3832381405 --> @github-actions[bot] commented on GitHub (Feb 2, 2026): 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:55:01 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 16, 2026):

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:3905805474 --> @github-actions[bot] commented on GitHub (Feb 16, 2026): 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.
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 stale
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#6916
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?