github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-07-16 06:08:33 -05:00
Code Issues 1.6k Packages Projects Releases 79 Wiki Activity

[GH-ISSUE #3254] Shared policy access rules are always at the bottom? #39140

New Issue
Open
opened 2026-06-22 02:59:36 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-06-22 02:59:36 -05:00
Owner
Copy Link

Originally created by @ceptonit on GitHub (Jun 12, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3254

Describe the Bug

After applying a shared policy to a public resource, it seems its access rules are always at the bottom if you try to add a custom rule for said resource.
In other words, it's impossible to add a custom rule that goes below the shared policy rules?
I'm not sure if it's a bug or meant to work this way, but this a bit of a bummer if your shared policy rules are all "Block access" type rules, which you'd probably always want at the top and not at the bottom priority wise.

Environment

  • OS Type & Version: Docker Compose on Debian Trixie
  • Pangolin Version: 1.19.1
  • Edition: Enterprise

To Reproduce

  1. Create a shared policy
  2. Create any access rule in it
  3. Apply the policy to a public resource
  4. Inside the public resource, go to the Access Rules tab
  5. The shared policy access rule shows up as greyed out (normal behavior)
  6. Add a custom rule of your choice via the "+ Add Rule" button
  7. Your new rule will appear at the top with a priority of 1
  8. Change its priority number to a number bigger than the last rule of the shared policy (ie 99)
  9. You get a "Invalid priority. Enter a whole number of 1 or higher."
  10. Impossible to move the custom rule below the shared policy rules.

Expected Behavior

Custom access rules on public resources should be able to go below shared policy rules.

Originally created by @ceptonit on GitHub (Jun 12, 2026). Original GitHub issue: https://github.com/fosrl/pangolin/issues/3254 ### Describe the Bug After applying a shared policy to a public resource, it seems its access rules are always at the bottom if you try to add a custom rule for said resource. In other words, it's impossible to add a custom rule that goes below the shared policy rules? I'm not sure if it's a bug or meant to work this way, but this a bit of a bummer if your shared policy rules are all "Block access" type rules, which you'd probably always want at the top and not at the bottom priority wise. ### Environment - OS Type & Version: Docker Compose on Debian Trixie - Pangolin Version: 1.19.1 - Edition: Enterprise ### To Reproduce 1. Create a shared policy 2. Create any access rule in it 3. Apply the policy to a public resource 4. Inside the public resource, go to the Access Rules tab 5. The shared policy access rule shows up as greyed out (normal behavior) 6. Add a custom rule of your choice via the "+ Add Rule" button 7. Your new rule will appear at the top with a priority of 1 8. Change its priority number to a number bigger than the last rule of the shared policy (ie 99) 9. You get a "Invalid priority. Enter a whole number of 1 or higher." 10. Impossible to move the custom rule below the shared policy rules. ### Expected Behavior Custom access rules on public resources should be able to go below shared policy rules.
GiteaMirror added the enhancement label 2026-06-22 02:59:36 -05:00
GiteaMirror commented 2026-06-22 02:59:38 -05:00
Author
Owner
Copy Link

@woernsn commented on GitHub (Jun 15, 2026):

I'm seeing the same.

I want to be able to add site-specific rules in between the shared rules.
Therefore I added 3 shared rules with priorities 10, 20 and 99.
Adding a specific rule via Docker label like

pangolin.public-resources.my-app.rules[0].priority=11

adds the rule regardless of the priority (or more likely: the shared rules' priorities) at the top.

Also the given priority in the shared rules are not reflected on the site configuration.

Share policy configuration:
Image

Site configuration using the shared policy and having the mentioned "11" priority:

Image
<!-- gh-comment-id:4707917944 --> @woernsn commented on GitHub (Jun 15, 2026): I'm seeing the same. I want to be able to add site-specific rules in between the shared rules. Therefore I added 3 shared rules with priorities 10, 20 and 99. Adding a specific rule via Docker label like ``` pangolin.public-resources.my-app.rules[0].priority=11 ``` adds the rule regardless of the priority (or more likely: the shared rules' priorities) at the top. Also the given priority in the shared rules are not reflected on the site configuration. Share policy configuration: <img width="1558" height="537" alt="Image" src="https://github.com/user-attachments/assets/8eac4d25-4866-423c-9c51-6620fbc91fc2" /> Site configuration using the shared policy and having the mentioned "11" priority: <img width="1551" height="667" alt="Image" src="https://github.com/user-attachments/assets/8e0b06fc-2634-45b9-a3c2-97e8d111e7cb" />
GiteaMirror commented 2026-06-22 02:59:39 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jun 16, 2026):

Right now this is expected behavior. The the rules on the resource
specifically "override" the policy rules and always go on top. We could
look into adding this as a feature (to interlace the rules).

On 6/15/26 05:28, Werner Kapferer wrote:

woernsn left a comment (fosrl/pangolin#3254)
https://github.com/fosrl/pangolin/issues/3254#issuecomment-4707917944

I'm seeing the same.

I want to be able to add site-specific rules in between the shared rules.
Therefore I added 3 shared rules with priorities 10, 20 and 99.
Adding a specific rule via Docker label like

|pangolin.public-resources.my-app.rules[0].priority=11 |

adds the rule regardless of the priority (or more likely: the shared
rules' priorities) at the top.

Also the given priority in the shared rules are not reflected on the
site configuration.

Share policy configuration:
image.png (view on web)
https://github.com/user-attachments/assets/8eac4d25-4866-423c-9c51-6620fbc91fc2

Site configuration using the shared policy and having the mentioned
"11" priority:

image.png (view on web)
https://github.com/user-attachments/assets/8e0b06fc-2634-45b9-a3c2-97e8d111e7cb

—
Reply to this email directly, view it on GitHub
https://github.com/fosrl/pangolin/issues/3254?email_source=notifications&email_token=ABGEUGFGYEMHJ3PKPJH6GQ3477TVVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZQG44TCNZZGQ2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4707917944,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABGEUGBVZ43GSCRPB73D4ZD477TVVAVCNFSNUABFKJSXA33TNF2G64TZHM4DMMZYGM2TIMRXHNEXG43VMU5TINRUHEYDCMJQGI22C5QC.
You are receiving this because you are subscribed to this
thread.Message ID: @.***>

<!-- gh-comment-id:4724548122 --> @oschwartz10612 commented on GitHub (Jun 16, 2026): Right now this is expected behavior. The the rules on the resource specifically "override" the policy rules and always go on top. We could look into adding this as a feature (to interlace the rules). On 6/15/26 05:28, Werner Kapferer wrote: > *woernsn* left a comment (fosrl/pangolin#3254) > <https://github.com/fosrl/pangolin/issues/3254#issuecomment-4707917944> > > I'm seeing the same. > > I want to be able to add site-specific rules in between the shared rules. > Therefore I added 3 shared rules with priorities 10, 20 and 99. > Adding a specific rule via Docker label like > > |pangolin.public-resources.my-app.rules[0].priority=11 | > > adds the rule regardless of the priority (or more likely: the shared > rules' priorities) at the top. > > Also the given priority in the shared rules are not reflected on the > site configuration. > > Share policy configuration: > image.png (view on web) > <https://github.com/user-attachments/assets/8eac4d25-4866-423c-9c51-6620fbc91fc2> > > Site configuration using the shared policy and having the mentioned > "11" priority: > > image.png (view on web) > <https://github.com/user-attachments/assets/8e0b06fc-2634-45b9-a3c2-97e8d111e7cb> > > > — > Reply to this email directly, view it on GitHub > <https://github.com/fosrl/pangolin/issues/3254?email_source=notifications&email_token=ABGEUGFGYEMHJ3PKPJH6GQ3477TVVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZQG44TCNZZGQ2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4707917944>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABGEUGBVZ43GSCRPB73D4ZD477TVVAVCNFSNUABFKJSXA33TNF2G64TZHM4DMMZYGM2TIMRXHNEXG43VMU5TINRUHEYDCMJQGI22C5QC>. > You are receiving this because you are subscribed to this > thread.Message ID: ***@***.***> >
GiteaMirror commented 2026-06-22 02:59:40 -05:00
Author
Owner
Copy Link

@woernsn commented on GitHub (Jun 17, 2026):

Right now this is expected behavior. The the rules on the resource
specifically "override" the policy rules and always go on top. We could
look into adding this as a feature (to interlace the rules).
…

Thanks for answering so fast!

I don't know if this would also be requested for others but for me it's a must-have to be able to use shared policies for a few of my sites.

Would there be other side effects if the given priorities of the shared policies are simply taken as-is for the sites?
For the current behavior, one could simply set the shared policy priorities to > 20 and therefore always add site-specific rules with priorities < 20 on top.

<!-- gh-comment-id:4726000804 --> @woernsn commented on GitHub (Jun 17, 2026): > Right now this is expected behavior. The the rules on the resource > specifically "override" the policy rules and always go on top. We could > look into adding this as a feature (to interlace the rules). > […](#) Thanks for answering so fast! I don't know if this would also be requested for others but for me it's a must-have to be able to use shared policies for a few of my sites. Would there be other side effects if the given priorities of the shared policies are simply taken as-is for the sites? For the current behavior, one could simply set the shared policy priorities to > 20 and therefore always add site-specific rules with priorities < 20 on top.
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 enhancement
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#39140
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?