Detect if `trusted_proxies` and `client_ip_headers` are on, and do other header manupulation

未关闭
#2,800 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
go, php
领域
backend, devtools

调研方向

The request concerns how FrankenPHP's Caddy integration handles trusted_proxies and client_ip_headers when setting $_SERVER values in the PHP SAPI, likely in the Go side where request environment variables are built. Start by locating where REMOTE_ADDR and HTTPS are populated for PHP requests and how Caddy's client IP settings reach it. Done means a design decision on a client_proto_headers-style option and tests showing X-Forwarded-Proto yields HTTPS only when trusted.

由索引模型根据 Issue 内容生成。

描述

enhancement
Describe your feature request

Is your feature request related to a problem? Please describe.

This previous discussion suggests that "FrankenPHP is not supposed to tell php the connection is https when it's not. Your application must handle the HTTP_X_FORWARDED_PROTO header, it's not the webservers job to lie to the application."

That is generally true -- when configuring following the Running being a reverse proxy instructions, FrankenPHP passes the request unmodified and application has to choose how to process it.

However, Caddy has trusted_proxies and client_ip_headers options which replace the REMOTE_ADDR value with the value provided by the proxy headers. This is convenient because the {client_ip} and other IP-based configuration can be used.

Using this option results in a situation where the application/framework's Trusted Proxies code doesn't see that the request came from a proxy -- which is exactly as desired, except that some other X-Forwarded-* values are not handled. Primarily, the X-Forwarded-Proto value is not translated to the HTTPS value in the $_SERVER superglobal, so the application/framework does not think the request came via a secure channel even though it did.

Describe the solution you'd like

It would be nice if we can detect that trusted_proxies and client_ip_headers are enabled and also process X-Forwarded-Proto. Alternatively, we may want this to be configurable and add another option - perhaps client_proto_headers - that can say which header(s) to look at, if present. (Unlike the base client_ip_headers, I do not think this can be added to Caddy itself, because the handling needs to be PHP-specific.)

Describe alternatives you've considered

There are two alternatives, which each have drawbacks:

  1. Tell the framework/application to "trust all proxies", so it will process the headers no matter what IP address is in REMOTE_ADDR. This only works if traffic from non-proxy origins is completely blocked, which is not always practical.
  2. Turn off trusted_proxies in Caddy/FrankenPHP, and only use the framework/application. This prevents Caddy's configuration from being able to use the real origin IP. Also, if multiple applications are used, they all need to be configured to handle proxy headers, instead of Caddy/FrankenPHP being able to do it all at once.
主要语言
Go
星标
11.5k
派生
510
平均合并
1 天 10 小时
30 天内合并 PR
64

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

php/frankenphp 的其他 Issue

查看 php/frankenphp 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。