This will be perfect for remotely accessing my vaultwarden. Not something I want publicly proxied, no matter the restrictions I put in play.
<!-- gh-comment-id:4188489073 -->
@Vyerni commented on GitHub (Apr 5, 2026):
This will be perfect for remotely accessing my vaultwarden. Not something I want publicly proxied, no matter the restrictions I put in play.
@BryanConradHart commented on GitHub (Apr 9, 2026):
Will this allow overlapping domains with the public resources?
Eg: for a single domain, when the client is enabled use the client as auth, when the client is disabled use the public proxy auth as the auth for that domain.
<!-- gh-comment-id:4210869885 -->
@BryanConradHart commented on GitHub (Apr 9, 2026):
Will this allow overlapping domains with the public resources?
Eg: for a single domain, when the client is enabled use the client as auth, when the client is disabled use the public proxy auth as the auth for that domain.
@oschwartz10612 commented on GitHub (Apr 9, 2026):
Yes we should be able to work that in. Might need to make sure we clear
the DNS cache on the host first or something in the clients. :}
<!-- gh-comment-id:4210904295 -->
@oschwartz10612 commented on GitHub (Apr 9, 2026):
Yes we should be able to work that in. Might need to make sure we clear
the DNS cache on the host first or something in the clients. :}
@BryanConradHart commented on GitHub (Apr 11, 2026):
I'm not sure how well this fits with the future vision of pangolin, but as a fairly simple home user, the way I'd want this to work is that "private" and "public" resources are simply authentication methods for resources, and a resource can have neither, either, or both.
I understand if that UX conflicts with more important use cases, but I figured I wouldn't hurt to suggest.
<!-- gh-comment-id:4230087080 -->
@BryanConradHart commented on GitHub (Apr 11, 2026):
I'm not sure how well this fits with the future vision of pangolin, but as a fairly simple home user, the way I'd want this to work is that "private" and "public" resources are simply authentication methods for resources, and a resource can have neither, either, or both.
I understand if that UX conflicts with more important use cases, but I figured I wouldn't hurt to suggest.
I would use this too but with a slightly different approach by making site specific rules.
a site called local-network-access-only with a rule for all resources tied to that site to only allow connections from a local ip range.
the other site would be called something like remote-access and set authentication methods for all resources in that site.
in my use case I only have local sites as pangolin is on the same internal network as my general docker host so i'm not sure if that would work with other types of sites.
<!-- gh-comment-id:4301774231 -->
@akanealw commented on GitHub (Apr 23, 2026):
I would use this too but with a slightly different approach by making site specific rules.
a site called local-network-access-only with a rule for all resources tied to that site to only allow connections from a local ip range.
the other site would be called something like remote-access and set authentication methods for all resources in that site.
in my use case I only have local sites as pangolin is on the same internal network as my general docker host so i'm not sure if that would work with other types of sites.
@AstralDestiny commented on GitHub (Apr 23, 2026):
You won't really get the real ip all users via private resources will show up as the ip of the newt host, But not fully sure what you're going for fully.. Can you elaborate more? @akanealw ? Sorta sounds like you'd prefer to use a public resource to gate people then use the private resource to just bypass any auth.
<!-- gh-comment-id:4302001228 -->
@AstralDestiny commented on GitHub (Apr 23, 2026):
You won't really get the real ip all users via private resources will show up as the ip of the newt host, But not fully sure what you're going for fully.. Can you elaborate more? @akanealw ? Sorta sounds like you'd prefer to use a public resource to gate people then use the private resource to just bypass any auth.
it wouldn't necessarily need to be the public vs private resource groups but a way to set common rules like restricting access to an ip range for a specific group of resources.
I did see another discussion about resource policies after i wrote the first message so maybe my comment would relate more to that topic.
i apologize if this belongs in a different discussion.
<!-- gh-comment-id:4302093307 -->
@akanealw commented on GitHub (Apr 23, 2026):
it wouldn't necessarily need to be the public vs private resource groups but a way to set common rules like restricting access to an ip range for a specific group of resources.
I did see another discussion about resource policies after i wrote the first message so maybe my comment would relate more to that topic.
i apologize if this belongs in a different discussion.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @oschwartz10612 on GitHub (Mar 26, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2720
@Vyerni commented on GitHub (Apr 5, 2026):
This will be perfect for remotely accessing my vaultwarden. Not something I want publicly proxied, no matter the restrictions I put in play.
@BryanConradHart commented on GitHub (Apr 9, 2026):
Will this allow overlapping domains with the public resources?
Eg: for a single domain, when the client is enabled use the client as auth, when the client is disabled use the public proxy auth as the auth for that domain.
@oschwartz10612 commented on GitHub (Apr 9, 2026):
Yes we should be able to work that in. Might need to make sure we clear
the DNS cache on the host first or something in the clients. :}
@BryanConradHart commented on GitHub (Apr 11, 2026):
I'm not sure how well this fits with the future vision of pangolin, but as a fairly simple home user, the way I'd want this to work is that "private" and "public" resources are simply authentication methods for resources, and a resource can have neither, either, or both.
I understand if that UX conflicts with more important use cases, but I figured I wouldn't hurt to suggest.
@akanealw commented on GitHub (Apr 23, 2026):
I would use this too but with a slightly different approach by making site specific rules.
a site called local-network-access-only with a rule for all resources tied to that site to only allow connections from a local ip range.
the other site would be called something like remote-access and set authentication methods for all resources in that site.
in my use case I only have local sites as pangolin is on the same internal network as my general docker host so i'm not sure if that would work with other types of sites.
@AstralDestiny commented on GitHub (Apr 23, 2026):
You won't really get the real ip all users via private resources will show up as the ip of the newt host, But not fully sure what you're going for fully.. Can you elaborate more? @akanealw ? Sorta sounds like you'd prefer to use a public resource to gate people then use the private resource to just bypass any auth.
@akanealw commented on GitHub (Apr 23, 2026):
it wouldn't necessarily need to be the public vs private resource groups but a way to set common rules like restricting access to an ip range for a specific group of resources.
I did see another discussion about resource policies after i wrote the first message so maybe my comment would relate more to that topic.
i apologize if this belongs in a different discussion.