[GDRCD] Possibili problematiche passando a nuovo hosting

28/05/2026 16:20:42

Per la questione #2 degli IP tutti uguali perchè $_SERVER['REMOTE_ADDR'] attualmente usato in GDRCD cattura l'IP di Cloudflare e non quello del giocatore.

Per ripristinare gli ip "reali"

if (isset($_SERVER["HTTP_CF_CONNECTING_IP"])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER["HTTP_CF_CONNECTING_IP"];
} elseif (isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER["HTTP_X_FORWARDED_FOR"];
}

In realtà si potrebbe implementare questa istruzione in tutti i punti di GDRCD che richiamano l'IP. In questo modo funziona sia sotto CDN sia in caso non ci sia diventando più compatibile con varie tipologie di configurazioni server.

Fatemi sapere se risolvete!

🤞

28/05/2026 16:47:51 e modificato da blancks il 28/05/2026 16:48:11

gdr-online.com ha scritto: ...

Grazie per l'intervento (e per aver aggiunto l'highlighter!)

Devo però sconsigliare fermamente la soluzione suggerita perché incompleta e soffre di un problema di sicurezza abbastanza importante: chiunque, configurando uno dei due header in questione ( CF_CONNECTING_IP o X_FORWARDED_FOR ), potrebbe facilmente comunicare al tuo sistema un qualunque indirizzo IP arbitrario e questo aprirebbe la strada problemi ben più seri del non sapere l'ip reale dell'utente se i vari gestori lo hanno trattato non curandosi di escape vari nelle query SQL per esempio.

GDRCD, purtroppo, non è stato così lungimirante in proposito e si trovano situazioni come questa nel codice, dove l'indirizzo IP viene iniettato in query senza alcun filtro.

$result = gdrcd_query("SELECT * FROM blacklist WHERE ip = '". $_SERVER['REMOTE_ADDR'] ."' AND granted = 0", 'result');

Per essere implementata correttamente, sarebbe necessario recuperare tramite chiamata API a cloudflare ( https://api.cloudflare.com/client/v4/ips ↗ ) la lista completa dei loro ip pubblici, verificare che l'ip di ingresso nel REMOTE_ADDR faccia parte di quelli, e soltanto se presente effettuare l'operazione indicata.

Il fix non è immediato perché richiede di salvare una cache della chiamata api di CF da invalidare periodicamente, per poi fare il confronto dell'IP in ingresso tramite CIDR notation.

Potrebbe aver senso dedicare qualche energia nella creazione di un pacchetto da rilasciare per permettere di risolvere il problema in modo corretto 🤔

28/05/2026 17:00:18

blancks ha scritto: ...

Hai perfettamente ragione non ci avevo pensato. Bisognerebbe scaricare con $ipv4 = @file_get_contents('https://www.cloudflare.com/ips-v4'); (1 volta al giorno in caso di cambiamenti?) la lista e fare un check preventivo se la richiesta arriva dalla whitelist e in quel caso procedere.

Oggi se l'IP vine memorizzato in 1 solo punto (ad esempio la login) è anche fattibile aggiungre lo script di controllo così da poter utilizzare HTTP_CF_CONNECTING_IP e raggirar il problema madre. Se invece in GDRCD sono tanti i punti in cui si richiama l'IP magari si aggiunge una classe in config che fa questa roba al volo.

Però alzo le mani conosco poco GDRCD e PHP perciò lascio la palla a voi che siete decisamente più bravi di me ;)


P.S. felice che sia di gradimento! Grazie ancora!

28/05/2026 17:38:16 e modificato da blancks il 28/05/2026 17:38:42

gdr-online.com ha scritto: ...

Credo GDRCD ne faccia uso soltanto in fase di login, ma non potendo sapere se alcuni gestori hanno trattato il dato anche altrove penso sia più sicuro assumere vadano gestite tutte le richieste in ingresso intervenendo sul file di inizializzazione dell'engine (in /includes/required.php).

Bisognerebbe scaricare con $ipv4 = @file_get_contents('https://www.cloudflare.com/ips-v4'); (1 volta al giorno in caso di cambiamenti?)

Una volta al giorno mi sembra una tempistica corretta! Per completezza del discorso, casomai qualcuno volesse implementare per conto suo questa possibile soluzione, farei solo attenzione a non dare per scontato che la chiamata API riesca sempre. Se questa fallisce per qualsiasi motivo (possono essere problemi di CF o del servizio di hosting o un nodo internazionale che va giù) ha senso tenere per valida la situazione attuale della cache e skippare l'aggiornamento per quella giornata, perché se non gestito correttamente può nel migliore dei casi far ripresentare il problema che si voleva risolvere, nel peggiore rendere il sito totalmente inaccessibile. Grazie nuovamente per il confronto sul tema!