Has anyone implemented this? I’m wondering what combination of header forwarding is required to get it to work. Forwarding only the Host header caused very erratic behavior. Github asked me to reauthorize the drone integration with my account due to an unusually high number of requests and the authorization requests did not work so every page request redirected me to the reauthorization page.
I don’t actually want to do this long term, I was experimenting with cloudfront and the only public endpoint I could point it at in my dev environment is drone, so…
The setup looks like this: drone.mydomain.com Alias A record -> Cloudfront Distribution (TLS termination) -> ELB -> Traefik/kubernetes (TLS termination again) -> Drone Server Service/Pod
When I forwarded all the headers things seemed to work ok, but that apparently prevents caching and once I switched it to whitelist forwarding only the Host header, the github authorization failed as described above.
When drone is placed behind a reverse proxy or load balancer it cannot determine its actual url and will therefore have problems with oauth redirects, status updates, etc. For drone to determine its actual url you need to provide both the X-Forwarded-For and X-Forwarded-Proto header variables.
@fbcbarbosa I did not attempt to go any further. I read your other post. It is really strange that Cloudfront doesn’t forward X-Forwarded-Proto when it is specified, especially since it does forward it when configured to forward all headers.
While working on this I did discover one interesting thing about Cloudfront, it does domain fronting. Even when the distribution is configured for non-SNI clients.