Open lbreitk opened 2 years ago
This causes an issue as the external URL is not internally accessible
@lbreitk , thank you for the issue! 👍 Please provide a configuration snippet for this. Additionally, please provide a Caddyfile config snippet for that future state (i want to see the logic from Caddyfile perspective) where internal and external URL are being separate.
Please provide a configuration snippet for this
@lbreitk , please respond.
@greenpau Thanks for the follow up - I apologize that I haven't responded, I'll try to make time to reply soon. My work priorities get shuffled around a lot.
My work priorities get shuffled around a lot.
@lbreitk , same here. I was MIA for the last 3-4 weeks.
@lbreitk , in the coming release, there will be an option to specify trusted public keys inside caddy security config. This way, there will be no need for external comms. Would that help your use case?
@lbreitk, bump.
Describe the issue
When you start caddy with the module, it connects to the URL of the provider. The issue is, at least with oauth, is that the end-user has to connect directly to the oauth provider. But the caddy service also connects to the provider to get the settings, etc. This causes an issue as the external URL is not internally accessible, meaning that to get everything to play nicely, I have to enable NAT reflection, or configure reverse policy zones, etc. so that the external URL resolves to an internal IP address internally for caddy, so it can connect to the oauth server. It would be nice if I could just specify the URL to server to external clients, and to use internally.
Version Information
Expected behavior Out of the box compatibility with internally hosted services, rather than make assumptions that services are all external or hosted in a "cloud" somewhere