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

Đang mở
  • Có gì không ổn?
#2,800 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, php
Lĩnh vực
backend, devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Go
Star
11.5k
Fork
506
Merge trung bình
1 ngày 10 giờ
Pull request đã merge (30 ngày)
64

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của php/frankenphp

Tất cả issue của php/frankenphp

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.