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.
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.