search

cloud-gov / cf-cdn-service-broker

A Cloud Foundry service broker for CloudFront and Let's Encrypt
Other
10 stars 13 forks source link

Expose forwarded host to proxied applications #64

Closed jmcarp closed 7 years ago

jmcarp commented 7 years ago

So that proxied applications can generate redirects relative to the correct host (for example), users should be able to configure broker instances to pass the original host to the app. Based on discussion in #cloud-gov-agent-q, options include:

  1. (Optionally) set custom X-Forwarded-Host header
  2. (Optionally) forward original Host header to app

Option 1 wouldn't require users to do anything differently and should Just Work, as long as their application code understands the X-Forwarded-Host header. But for instances that use multiple external domains, like app.agency.gov,www.app.agency.gov, we'd have to pick one of those domains, or allow users to control all custom headers, both of which might be unintuitive.

Option 2 would require users to add a private domain (although we could add this to the broker) and associate it with their app. Users also wouldn't need to specify an origin url--we'd always point to the cloud.gov elb or app.cloud.gov (right?). Another complication here is that users might want more control over forwarding headers (see #46), so we might want to default to forwarding Host but also allow users to pass an array of headers to forward, including "*" for all headers.

Option 2 sounds better--as @cnelson pointed out, we don't have to rely on users' application code understanding X-Forwarded-Host, and it makes use of existing cf logic around domains, like setting the domain in the app manifest. The only question is whether it's all right to add the extra step of creating a private domain and associating with an app--which I think is fine.

Thanks @cnelson and @LinuxBozo for explaining all this to me--I'm basically just transcribing here.

cnelson commented 7 years ago

[@jcscottiii - James Scott] Can you accept this work, or comment on what more needs to be done based on the discussions around cross-org domain sharing today?

jcscottiii commented 7 years ago

This work is effectively done. [@jmcarp - Josh Carp] and I discussed a path forward that unblocked migrations. It causes the app manifest to set no-hostname: true. An example PR of using this solution is in this PR for dolores: https://github.com/18F/dolores-landingham-slack-bot/pull/246

However, one downside is that one org can effectively own a domain and prevent others from using it.

There is a card to discuss how to make this process much better here: https://github.com/18F/cf-cdn-service-broker/issues/67