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

Aperta
#2,800 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, php
Ambito
backend, devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Go
Stelle
11.5k
Fork
506
Merge medio
1g 9h
PR unite (30g)
63

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di php/frankenphp

Tutte le issue di php/frankenphp

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.