mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-31 11:06:13 -05:00
[GH-ISSUE #2551] Bypass Auth path rules do not work for unauthenticated users on Protected resources #10947
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#10947
Reference in New Issue
Block a user
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?
Originally created by @BeBeRex56 on GitHub (Feb 26, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2551
Describe the Bug
When a resource is set to Protected, path-based Bypass Auth rules do not allow unauthenticated users to access those paths. Unauthenticated visitors are always redirected to the Pangolin authentication wall regardless of matching Bypass Auth rules. Authenticated users with an existing session are unaffected, which makes the issue easy to miss during testing.
Environment
To Reproduce
Expected Behavior
A Bypass Auth path rule should allow unauthenticated users to access the matched path without being redirected to the login page, even when the resource is globally Protected. This is needed to support use cases where a protected resource has specific public-facing endpoints, such as application-generated share links.
<html> <html><head></head>Bypass Auth and Pass to Auth Path Rules Do Not Work Correctly in Either Authentication Mode
Summary
Path-based rules in Pangolin's Resource Rules Configuration are broken in both directions:
Bypass Authrules do not allow unauthenticated users to access matched paths — the global auth wall fires before rules are evaluated.Pass to Authrules do not enforce authentication on matched paths — everything is publicly accessible regardless of rules.This makes it impossible to achieve a mixed-access configuration where some paths on a resource are public (e.g. share links) and others are protected — regardless of which direction you configure it from.
Expected Behavior
Bypass Authpath rules should allow unauthenticated users to access matched paths without hitting the auth wall.Pass to Authpath rules should enforce authentication on matched paths, blocking unauthenticated access to those paths.In both cases, path rules should be evaluated before the global authentication decision is made.
Actual Behavior
Scenario A — Protected resource with Bypass Auth rules: Unauthenticated users visiting any path, including those explicitly covered by Bypass Auth rules, are redirected to the Pangolin authentication page. The bypass rules are never applied.
Scenario B — Unprotected resource with Pass to Auth rules: All paths are publicly accessible to unauthenticated users regardless of Pass to Auth rules. The rules are never applied.
In both scenarios, authenticated users with existing Pangolin sessions are unaffected, which makes the issue easy to miss during initial testing.
Steps to Reproduce
Scenario A:
Scenario B:
Environment
Use Case / Impact
This prevents a common and important self-hosting use case: protecting a resource behind Pangolin authentication while allowing specific public-facing paths (such as application-generated share links) to remain accessible without login.
The specific case tested was File Browser running behind Pangolin, where File Browser generates unique share link tokens accessible at
/share/<token>,/api/public/share/<token>, and serving assets from/static/assets/and/static/img/. These endpoints are intended to be publicly shareable. With the current behavior there is no way to expose these public endpoints while keeping the rest of the resource protected.Rules configuration tested (Scenario A):
Even with rule 5 in place, the resource root is fully publicly accessible with no authentication.
Additional Observations
Suggested Fix
Path rules should be evaluated before the global authentication check, so that:
Bypass Authrules pass unauthenticated requests directly to the upstream without triggering the auth redirectPass to Authrules enforce authentication even when the resource is globally unprotectedAlternatively, a dedicated "Mixed" authentication mode that explicitly supports public paths with protected fallback would address this use case cleanly.
</html> </html>@JonathanCrouse commented on GitHub (Feb 27, 2026):
Just updated to 1.16.0 and I'm not seeing similar behavior with my resources. I think this might just be a rules issues, at least for your first scenario.
For Scenario A change the path from '/share/' to '/share/*'. Then after that rule add another as Action = Pass to Auth, Match Type = Path, Value = *
Scenario B could be a caching/cookie issue if you're already authenticated with pangolin. If it's not that then similar to above change '/' to '*' and try it.
Here is a good list of examples in the docs too - https://docs.pangolin.net/manage/access-control/rules
@moohbr commented on GitHub (Feb 27, 2026):
@JonathanCrouse I had the same issue as the OP, but I'm using the direct page (/config.html). I'm on version 1.13.1
@JonathanCrouse commented on GitHub (Feb 27, 2026):
@moohbr In your case, assuming /config.html is the only location that you want to allow access unauthenticated, you would have a rule to bypass auth for path /config.html and then another rule (with a higher priority number) that will pass to auth for path *.
This should require authentication through pangolin for any location on that resource except for /config.html.
@moohbr commented on GitHub (Mar 1, 2026):
@JonathanCrouse not successful here. I tried the exactly thing you suggest, but no effects happened. My actual goal is block only
/config.html@moohbr commented on GitHub (Mar 1, 2026):
If I full block access to this page, it work perfectly, however when I try force authentication only on this page, it won't work.
1st case -> block access for everyone on a unprotected resource - works
2nd case -> force auth in a unique path - failed
@moohbr commented on GitHub (Mar 1, 2026):
After analyzing the code, the file
server/routers/badger/verifySession.tsis responsible for applying the access rules. Here is what actually happens:Bypass auth→ Always returns allowedBlock access→ Always returns not allowedPass to auth→ Tries to verify the enabled authentication methodsOn line 264, the condition
if (!sso && !pincode && !password && ...)checks whether the resource has any authentication method configured.If none exists, the rule is ignored and access is automatically granted to the user, even if the option selected was
Pass to Auth.IMO, a safer approach would be:
If the resource has no authentication methods configured, the system should only allow the
Block Accessoption and on API return an explicit message. Maybe this would avoid misconfiguration scenarios.BTW, to fix the issue, I did:
Pass to Authon the routes I actually want to block.Bypass Authon*to allow access to all other pages.In the screenshot there are more blocked pages (and I disabled * xD), but you get the idea.
PS: Until 01/03, I can't bypass specifics URL in the scenario above.
@moohbr commented on GitHub (Mar 1, 2026):
@BeBeRex56 Please, try what I said. It may help you. If it works, we can discuss the next steps.
@BeBeRex56 commented on GitHub (Mar 1, 2026):
Ok I'll try this ! Thank you !
@moohbr commented on GitHub (Mar 2, 2026):
Hey guys, I found something interesting: when the path contains URL parameters, Pangolin doesn’t handle it properly and the rule validation “fails”. I used a basic URL validation (from the Web API) and that solved the issue. Until they review and accept my MR, I suggest adding a
*to any URL that may receive parameters.For example: if you allow
stream.html, thenstream.html?token=123will not be allowed. Pangolin validates the exact path, so you need to setBypass authforstream.html*.@github-actions[bot] commented on GitHub (Mar 17, 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.
@github-actions[bot] commented on GitHub (Mar 31, 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.