mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-21 09:21:15 -05:00
[Feature Request] Configure allow and deny for subfolders #423
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 @Joly0 on GitHub (Jun 9, 2025).
Hey, from what i can see, Pangolin supports two rule types, "Always Allow" and "Always Deny".
This is in general helpful, but if i want to expose just a specific endpoint with a specific subfolder to the public world and deny everything else i would have no option to do so.
So for example i want to run homeassistant at my home, but doesnt want to expose the full homeassistant instance to the public world, but still want to expose the webhook endpoint publicly BUT with authentication through pangolin, i have no chance for that.
As far as i can see, i only could deny everything, and allow the webhook subfolder, but that would leave the webhook subfolder without authentication from pangolin.
Would be great, if this was possible to do. So i could also configure a deny all in general for an endpoint/service and then have various subfolders (paths) with authentication and some without. This would help a lot.
So tl;dr, would be great to have an "Always Allow" but with authentication.
@miloschwartz commented on GitHub (Jun 12, 2025):
You should be able to do this by setting two rules and using the priorities:
Add an allow for your specific path with priority 1.
Add a deny all rule for all paths with priority 2.
This way the second rule acts as a catch all. It's not sexy but should work.
@Joly0 commented on GitHub (Jun 12, 2025):
While this is true in general, the allow all rule bypasses authentication, which i want to use in this scenario.
As i described, i would like to deny all for all paths, but allow WITH authentication through pangolin for certain subfolders
@github-actions[bot] commented on GitHub (Jun 27, 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.
@Joly0 commented on GitHub (Jun 27, 2025):
Not an issue but a feature request and still important
@miloschwartz commented on GitHub (Sep 27, 2025):
Thanks, converting this to a discussion thread so others can upvote and participate!