Bypass Auth path rules do not work for unauthenticated users on Protected resources #192

New Issue

MrUnknownDE · 2026-04-05T17:02:05+02:00

MrUnknownDE commented

2026-04-05 17:02:05 +02:00

Originally created by @BeBeRex56 on 2/26/2026

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

OS Type & Version: Ugreen NAS (Docker)
Pangolin Version: latest (hosted via app.pangolin.net)
Gerbil Version: N/A
Traefik Version: N/A
Newt Version: 1.10.0
Pangolin-CLI Version: latest
Olm Version: N/A

To Reproduce

Create a resource with Authentication set to Protected
Navigate to the Rules tab for the resource
Add a rule: Action = Bypass Auth, Match Type = Path, Value = /share/
Save the rules
Open a path matching the rule (e.g. /share/) in a private/incognito browser window
Observe that Pangolin redirects to the authentication page instead of allowing access

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.

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:

When a resource is set to Protected, Bypass Auth rules do not allow unauthenticated users to access matched paths — the global auth wall fires before rules are evaluated.
When a resource Authentication is set to off/none, Pass to Auth rules 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

When Authentication is Protected: Bypass Auth path rules should allow unauthenticated users to access matched paths without hitting the auth wall.
When Authentication is off: Pass to Auth path 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:

Create a resource with Authentication set to Protected
Navigate to the Rules tab and add: Action = Bypass Auth, Match Type = Path, Value = /share/
Save the rules
Open a matching path (e.g. /share/<token>) in a private/incognito browser window
Observe redirect to Pangolin auth page instead of bypassing

Scenario B:

Set the same resource Authentication to off/none
Navigate to the Rules tab and add: Action = Pass to Auth, Match Type = Path, Value = /
Save the rules
Open the resource root URL in a private/incognito browser window
Observe that the resource is fully accessible with no authentication required

Environment

OS Type & Version: Ugreen NAS (Docker)
Pangolin Version: latest (hosted via app.pangolin.net)
Gerbil Version: N/A
Traefik Version: N/A
Newt Version: 1.10.0
Pangolin-CLI Version: latest
Olm Version: N/A

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):

Priority	Action	Match Type	Value
1	Bypass Auth	Path	/share/
2	Bypass Auth	Path	/api/public/
3	Bypass Auth	Path	/static/assets/
4	Bypass Auth	Path	/static/img/

Even with rule 5 in place, the resource root is fully publicly accessible with no authentication.

Additional Observations

The issue is only reproducible for unauthenticated sessions. Logged-in users with a valid Pangolin session are unaffected and rules appear to function correctly for them.
This strongly suggests that the global authentication state (Protected or off) is evaluated at a layer above the rules engine, and rules are only consulted after a valid session is already confirmed.
There is no option in the Proxy settings UI to strip forwarded headers, which would have been an alternative workaround.
Secondary CORS/CORB errors were also observed when static assets required by the share page (JS, CSS) were being intercepted by the auth wall and redirected cross-origin to app.pangolin.net.

Suggested Fix

Path rules should be evaluated before the global authentication check, so that:

Matching Bypass Auth rules pass unauthenticated requests directly to the upstream without triggering the auth redirect
Matching Pass to Auth rules enforce authentication even when the resource is globally unprotected

Alternatively, a dedicated "Mixed" authentication mode that explicitly supports public paths with protected fallback would address this use case cleanly.

</html> </html>

*Originally created by @BeBeRex56 on 2/26/2026* ### 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 - OS Type & Version: Ugreen NAS (Docker) - Pangolin Version: latest (hosted via app.pangolin.net) - Gerbil Version: N/A - Traefik Version: N/A - Newt Version: 1.10.0 - Pangolin-CLI Version: latest - Olm Version: N/A ### To Reproduce 1. Create a resource with Authentication set to Protected 2. Navigate to the Rules tab for the resource 3. Add a rule: Action = Bypass Auth, Match Type = Path, Value = /share/ 4. Save the rules 5. Open a path matching the rule (e.g. /share/<token>) in a private/incognito browser window 6. Observe that Pangolin redirects to the authentication page instead of allowing access ### 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> <body> <html><head></head><body><h1>Bypass Auth and Pass to Auth Path Rules Do Not Work Correctly in Either Authentication Mode</h1> <h2>Summary</h2> <p>Path-based rules in Pangolin's Resource Rules Configuration are broken in both directions:</p> <ol> <li>When a resource is set to <strong>Protected</strong>, <code>Bypass Auth</code> rules do not allow unauthenticated users to access matched paths — the global auth wall fires before rules are evaluated.</li> <li>When a resource Authentication is set to <strong>off/none</strong>, <code>Pass to Auth</code> rules do not enforce authentication on matched paths — everything is publicly accessible regardless of rules.</li> </ol> <p>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.</p> <h2>Expected Behavior</h2> <ul> <li>When Authentication is <strong>Protected</strong>: <code>Bypass Auth</code> path rules should allow unauthenticated users to access matched paths without hitting the auth wall.</li> <li>When Authentication is <strong>off</strong>: <code>Pass to Auth</code> path rules should enforce authentication on matched paths, blocking unauthenticated access to those paths.</li> </ul> <p>In both cases, path rules should be evaluated <strong>before</strong> the global authentication decision is made.</p> <h2>Actual Behavior</h2> <p><strong>Scenario A — Protected resource with Bypass Auth rules:</strong> 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.</p> <p><strong>Scenario B — Unprotected resource with Pass to Auth rules:</strong> All paths are publicly accessible to unauthenticated users regardless of Pass to Auth rules. The rules are never applied.</p> <p>In both scenarios, authenticated users with existing Pangolin sessions are unaffected, which makes the issue easy to miss during initial testing.</p> <h2>Steps to Reproduce</h2> <p><strong>Scenario A:</strong></p> <ol> <li>Create a resource with Authentication set to Protected</li> <li>Navigate to the Rules tab and add: Action = Bypass Auth, Match Type = Path, Value = /share/</li> <li>Save the rules</li> <li>Open a matching path (e.g. /share/<token>) in a private/incognito browser window</li> <li>Observe redirect to Pangolin auth page instead of bypassing</li> </ol> <p><strong>Scenario B:</strong></p> <ol> <li>Set the same resource Authentication to off/none</li> <li>Navigate to the Rules tab and add: Action = Pass to Auth, Match Type = Path, Value = /</li> <li>Save the rules</li> <li>Open the resource root URL in a private/incognito browser window</li> <li>Observe that the resource is fully accessible with no authentication required</li> </ol> <h2>Environment</h2> <ul> <li>OS Type & Version: Ugreen NAS (Docker)</li> <li>Pangolin Version: latest (hosted via app.pangolin.net)</li> <li>Gerbil Version: N/A</li> <li>Traefik Version: N/A</li> <li>Newt Version: 1.10.0</li> <li>Pangolin-CLI Version: latest</li> <li>Olm Version: N/A</li> </ul> <h2>Use Case / Impact</h2> <p>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.</p> <p>The specific case tested was File Browser running behind Pangolin, where File Browser generates unique share link tokens accessible at <code>/share/<token></code>, <code>/api/public/share/<token></code>, and serving assets from <code>/static/assets/</code> and <code>/static/img/</code>. 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.</p> <p><strong>Rules configuration tested (Scenario A):</strong></p> Priority | Action | Match Type | Value -- | -- | -- | -- 1 | Bypass Auth | Path | /share/ 2 | Bypass Auth | Path | /api/public/ 3 | Bypass Auth | Path | /static/assets/ 4 | Bypass Auth | Path | /static/img/ <p>Even with rule 5 in place, the resource root is fully publicly accessible with no authentication.</p> <h2>Additional Observations</h2> <ul> <li>The issue is only reproducible for unauthenticated sessions. Logged-in users with a valid Pangolin session are unaffected and rules appear to function correctly for them.</li> <li>This strongly suggests that the global authentication state (Protected or off) is evaluated at a layer above the rules engine, and rules are only consulted after a valid session is already confirmed.</li> <li>There is no option in the Proxy settings UI to strip forwarded headers, which would have been an alternative workaround.</li> <li>Secondary CORS/CORB errors were also observed when static assets required by the share page (JS, CSS) were being intercepted by the auth wall and redirected cross-origin to app.pangolin.net.</li> </ul> <h2>Suggested Fix</h2> <p>Path rules should be evaluated <strong>before</strong> the global authentication check, so that:</p> <ul> <li>Matching <code>Bypass Auth</code> rules pass unauthenticated requests directly to the upstream without triggering the auth redirect</li> <li>Matching <code>Pass to Auth</code> rules enforce authentication even when the resource is globally unprotected</li> </ul> <p>Alternatively, a dedicated "Mixed" authentication mode that explicitly supports public paths with protected fallback would address this use case cleanly.</p></body></html> </body> </html>

MrUnknownDE closed this issue

2026-04-05 17:02:05 +02:00

MrUnknownDE added the stale stale stale stale stale stale labels 2026-04-05 17:02:05 +02:00

Sign in to join this conversation.

Branches Tags

main

dev

dependabot/npm_and_yarn/dev-minor-updates-b4e5d6b9c5

revert-2766-feature/systemd-install-instructions

dependabot/npm_and_yarn/prod-patch-updates-05702d39f2

dependabot/npm_and_yarn/next-16.2.1

dependabot/npm_and_yarn/recharts-3.8.1

alerting-rules

private-site-ha

dependabot/docker/docker/library/node-25-slim

ssh

delete-account

msg-delivery

org-only-idp

cicd

patch

site-targets-auto-login

No Label stale stale stale stale stale stale

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/pangolin#192