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

オープン
  • 何か問題がありますか？
#2,800 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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
フォーク
506
平均マージ
1日 9時間
マージ済み PR（30日）
63

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

php/frankenphp のほかの issue

php/frankenphp の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。