tailscale zta: use x-forwarded-for value if present and valid

[kenichi]

In trying to set up a livebook instance on our tailnet, we noticed that a direct connections over http to the service would identify users correctly, but a reverse-proxied connection over https would identify everyone as the user who created the tailscale key in use by the instance. This is because we had configured an nginx server to terminate TLS with the cert/key from tailscale cert, and then rev-proxy to livebook. Even though traffic over tailnets is encrypted already, it is by design transparent to browsers who can still complain about http. So, in our nginx conf, we had set the request header:

proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;

However, Livebook.ZTA.Tailscale had no knowledge of this header. This PR adds a couple tests to simulate the situation and a new private function in the module to fetch the correct IP to use when querying tailscaled.

[github-actions]

Uffizzi Ephemeral Environment deployment-51667

☁️ https://app.uffizzi.com/github.com/livebook-dev/livebook/pull/2603

📄 View Application Logs etc.

What is Uffizzi? Learn more!

[kenichi]

I've looked into these options as well:

• Plug.SSL enabled by env var does not support -for
• tailscale serve vs nginx (works the same, also sets x-forwarded-for)

[josevalim]

Unfortunately we cannot do this automatically, because it means if someone is using it outside of a proxy, then we will listen to this header set by a user, which they can then point anywhere.

Can you please send a PR that adds x-forwarded-for support to Plug.RewriteOn? Then I can make Plug.RewriteOn configurable via LIVEBOOK env vars. :)

[josevalim]

Actually,. I will have a commit for this soon, hold on!

[josevalim]

Please give #2604 a try!

[kenichi]

@josevalim that is a much better solution, thank youuuu! 🙇🏽‍♂️