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 #1303] [BUG] Rules not stateless between requests? #6641

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

Originally created by @tiuck on GitHub (Aug 18, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1303

Hi,

I'm using Pangolin to secure my Immich installation but I'm having trouble with the rules that appear not to match as they should.

Setup information

  • Pangolin v.1.8.0 on public vm with activated geoblock
  • Selfhosted immich on local server, connected to Pangolin VM via Wireguard (connection not facilitated by Gerbil/Newt as the VM itself is creating a tunnel to my local router)
  • Two resources created:
  1. one for immich mobile app access, secured via shareable link/access tokens (this resource works fine)
  2. one exclusively for immich "share link" functionality to share albums and pictures with friends and have them upload pictures. No immich user login is required nor allowed. <-- this is the one that I have trouble with
  • Share URLs look like https://mydomain/share/L66jTe8ejIrl9XFcPHo0EzccmLh4H8Lggng477usD0Uie-r2g7_Wq8S8xTwD4zuBNK4
  • Using chrome's developer tools I found all the calls Immich makes to the webserver and whitelisted them in rules tab. Additionally, I blacklisted admin and auth directories (see below)
  • On tab "Authentication" all authentication methods are disabled
Image

Problem description

(all attempts made using chrome incognito sessions)

  • Opening a shared gallery link works fine the first time, however reloading the tab results in a 401 HTTP status with Unauthorized in the body.
  • Any further page reloads continue to give 401 Unauthorized.
  • The shared gallery link works again once I close the incognito window and open a new one. The next reload is then blocked again.
  • It appears, that there is some sort of statefulness between requests: If I disable the final Always deny * rule refreshing the page does not result in a 401 unauthorized!

Any ideas what this could be and how to prevent it? I'd be happy to share pangolin logs but don't know which logs would be relevant and how I would access them.

Many thanks in advance!

Originally created by @tiuck on GitHub (Aug 18, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1303 Hi, I'm using Pangolin to secure my Immich installation but I'm having trouble with the rules that appear not to match as they should. ### Setup information - Pangolin v.1.8.0 on public vm with activated geoblock - Selfhosted immich on local server, connected to Pangolin VM via Wireguard (connection not facilitated by Gerbil/Newt as the VM itself is creating a tunnel to my local router) - Two resources created: 1. one for immich mobile app access, secured via shareable link/access tokens (this resource works fine) 2. one exclusively for immich "share link" functionality to share albums and pictures with friends and have them upload pictures. No immich user login is required nor allowed. **<-- this is the one that I have trouble with** - Share URLs look like `https://mydomain/share/L66jTe8ejIrl9XFcPHo0EzccmLh4H8Lggng477usD0Uie-r2g7_Wq8S8xTwD4zuBNK4` - Using chrome's developer tools I found all the calls Immich makes to the webserver and whitelisted them in rules tab. Additionally, I blacklisted `admin `and `auth` directories (see below) - On tab "Authentication" all authentication methods are disabled <img width="500" alt="Image" src="https://github.com/user-attachments/assets/4876d400-c88c-4209-a9b9-435e3a0d2fe4" /> ### Problem description (all attempts made using chrome incognito sessions) - Opening a shared gallery link works fine the first time, however reloading the tab results in a 401 HTTP status with `Unauthorized` in the body. - Any further page reloads continue to give 401 Unauthorized. - The shared gallery link works again once I close the incognito window and open a new one. The next reload is then blocked again. - It appears, that there is some sort of statefulness between requests: If I disable the final `Always deny *` rule refreshing the page does not result in a 401 unauthorized! Any ideas what this could be and how to prevent it? I'd be happy to share pangolin logs but don't know which logs would be relevant and how I would access them. Many thanks in advance!
GiteaMirror commented 2026-04-25 15:34:06 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Aug 31, 2025):

Hi! Sorry for the long delay in my reply!

This is strange. While something could be going on with state issues in
the rules processing my hypothesis is this could be related to Immich
and caching or something. When you load the resource for a 2nd time, if
you open the network tab in the browser tools could you post that? A
before and after? I am curious to see more about the request that is
getting blocked. Mainly: is it the same as the first request in path?

<!-- gh-comment-id:3239731771 --> @oschwartz10612 commented on GitHub (Aug 31, 2025): Hi! Sorry for the long delay in my reply! This is strange. While something could be going on with state issues in the rules processing my hypothesis is this could be related to Immich and caching or something. When you load the resource for a 2nd time, if you open the network tab in the browser tools could you post that? A before and after? I am curious to see more about the request that is getting blocked. Mainly: is it the same as the first request in path?
GiteaMirror commented 2026-04-25 15:34:06 -05:00
Author
Owner
Copy Link

@tiuck commented on GitHub (Aug 31, 2025):

Hi @oschwartz10612,

I just updated immich to v.140.1.1 and Pangolin to v.1.9.2 and I now cannot replicate the behavior anymore. I'll keep an eye on it and will report if it does happen again.
In any case, where and how would I be able to see the respective logs that show the rules processing decisions if it does happen again?

Many thanks!

<!-- gh-comment-id:3239999100 --> @tiuck commented on GitHub (Aug 31, 2025): Hi @oschwartz10612, I just updated immich to v.140.1.1 and Pangolin to v.1.9.2 and I now cannot replicate the behavior anymore. I'll keep an eye on it and will report if it does happen again. In any case, where and how would I be able to see the respective logs that show the rules processing decisions if it does happen again? Many thanks!
GiteaMirror commented 2026-04-25 15:34:07 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Sep 1, 2025):

Sounds good!

You can turn on debug logs by setting the log level to debug and
restarting then looking at the logs:
https://docs.digpangolin.com/self-host/advanced/config-file#param-log-level

You can also open dev tools in chrome to see the client side requests in
the network tab!

:}

Let us know if it happens again!

<!-- gh-comment-id:3240818714 --> @oschwartz10612 commented on GitHub (Sep 1, 2025): Sounds good! You can turn on debug logs by setting the log level to debug and restarting then looking at the logs: https://docs.digpangolin.com/self-host/advanced/config-file#param-log-level You can also open dev tools in chrome to see the client side requests in the network tab! :} Let us know if it happens again!
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
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#6641
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?