$_server['http_referer']

Buongiorno, la seguente riga di codice :

Codice PHP:

---

$mio= parse_url($_SERVER['HTTP_REFERER'])


---

blocca pa pagina del sito e produce un errore HTPError 500.
In locale e in altre pagine in remoto non mi crea alcuna problema,è possibile dipenda dalle impostazioni del server altervista?
Grazie per l'attenzione.

Mauro

Salve,
in realtà il messaggo non è un error ma un warning. ovvero un'avvertenza. La risposta 500 con blocco eseguzione è relativa alla configuarzione server di AlterVista.

Con PHP 7.x si ha un messaggio di tipo notice di questo tipo:

Citazione:

---

Notice: Undefined index: HTTP_REFERER in /home/user/scripts/code.php on line 14

---

Con PHP 8.x si ha un messaggio di tipo warning di questo tipo:

Citazione:

---

Warning: Undefined array key "HTTP_REFERER" in /home/user/scripts/code.php on line 14

---

Per evitarlo, bisogna aggiungere un controllo:

Codice PHP:

---

$mio = parse_url($_SERVER['HTTP_REFERER'] ?? '');


---

inoltre, il valore restituito da parse_url() è un erray. Se si vuole però recuperarlo come stringa, va convertito.

Codice PHP:

---

$mio = join(", ", parse_url($_SERVER['HTTP_REFERER'] ?? ''));


---

Cordiali saluti.

GraphOGLRisorse, grazie per la rapida ed esauriente risposta.
In locale utilizzo come server AMPPS con php 8.2, con error_reporting(E_ALL)e non ricevo alcun warning, anche se leggendo il manuale di PHP la mia sintassi in effetti è sbagliata. In locale correttamente tratto la risposta come array leggendo l'indice 'host' che + poi il dato di mio interesse.
Grazie ancora per la completa risposta

Mauro

Ho fatto una prova con la sintassi suggerita:
in Altervista è
array(1) { ["path"]=> string(0) "" }, quindi quando leggo l'indice HOST ovviamente ho un errore
in locale è:
array(3) { ["scheme"]=> string(4) "http" ["host"]=> string(9) "127.0.0.1" ["path"]=> string(1) "/" }
Ho letto che questa funzione può avere comportamenti 'strani' cercherò nel manuale PHP il modo corretto di leggere
il valore di host.
Grazie

Ma quindi l'intento finale dell'uso di parse_url() è di recuperare l'host dagli URL dei referer?

Il recupero dell'host da un URL può essere fatto semplicemente così:

Codice PHP:

---

function NomeDominio($url='') {
$str = strtolower(trim($url));
$str = preg_replace('/^http:\/\//i', '', $str);
$str = preg_replace('/^https:\/\//i', '', $str);
$str = preg_replace('/^www\./i', '', $str);
$str = explode('.', $str);
$str = trim($str[0]);
return $str;
}


---

Ad ogni modo, io prima ho risposto sulla base delle imformazione che ha fornito. Non vedendo l'intero codice non posso prevedere eventuali errori altrove nell'intero codice.

Se vuole, può riportare l'intero codice.

Comnque differenti configurazioni tra AMPPS in locale ed i server AlterVIsta, possono tal volta compoetare comportamenti incongrenti. Così come l'uso di differenti versini di PHP.

Edit:
Mi sorge un dubbio... L'url che le serve recuperare è quella corrente dove esegue lo script?

In tal caso, è corretto che HTTP_REFERER su AlterVista restituisca "". HTTP_REFERER viene valorizzato con l'url di provenienza da un asltro sito non con quello corrente. Per ottenere quello corrente va usato REQUEST_URI.

Codice PHP:

---

echo $_SERVER['REQUEST_URI'];


---

I sistemi che emulano i server in locale, tal volta possono avere comportamenti ingannevoli rispetto ai servere veri. Il comportamento di AMPPS che valorizza HTTP_REFERER come se fosse REQUEST_URI non è esattamente un errore lato suo, ma non è corretto in riferimnto a PHP su server.

Cordiali saluti.

Citazione:

---

Originalmente inviato da GraphOGLRisorse

Il recupero dell'host da un URL può essere fatto semplicemente così:

Codice PHP:

---

function NomeDominio($url='') {
$str = strtolower(trim($url));
$str = preg_replace('/^http:\/\//i', '', $str);
$str = preg_replace('/^https:\/\//i', '', $str);
$str = preg_replace('/^www\./i', '', $str);
$str = explode('.', $str);
$str = trim($str[0]);
return $str;
}


---

---

O con $host = parse_url($url)['host'] ?? ''; come menzionato sopra, non c'è motivo di reinventare la ruota :mrgreen:

Tornando al primo messaggio, il codice

Codice PHP:

---

$mio = parse_url($_SERVER['HTTP_REFERER'])


---

è corretto. Ci può essere un warning se l'header non esiste, ed in questo caso un avviso di deprecazione in PHP 8.1+:

Codice:

---

> parse_url(null)

  DEPRECATED  parse_url(): Passing null to parameter #1 ($url) of type string is deprecated.

= [
    "path" => "",
  ]

---

parse_url non è quindi la causa dell'errore 500. A mio parere il problema in cui @kairos2020 incappa è altrove, magari nel codice che usa $mio['host'] e lo trova vuoto.

Il referer è un header particolarmente inaffidabile, visto che non sempre è presente, e quando c'è potrebbe essere stato modificato dall'utente. Concordo quindi con GraphOGLRisorse, sarebbe utile capire qual'è il problema "a monte".

Su AlterVista attulmente il problema è che per evitare di mostrare eventuali messaggi di PHP che visualizzano i percorsi assoluti pubblicamente, si è deciso di far apparire la pagina di errore 500. E questo vale per tutti i tipi di messaggi (notice, warning ed error).

Notice e warning non sono messaggi bloccanti, ma gestendoli così, lo diventano. E ciò mi sembra un po' penalizzante. Considerando poi, che molti utenti non sono esperti di PHP e difficilmente useranno ambienti di emulazione in locale per i test.


kairos2020:
Per visualizzare errori (e resto) su AlterVista, vedere qui.

Cordiali saluti.

Grazie a tutti per le risposte. Si, in effetti volevo leggere leggere il nome dell'host, ho letto, in una libro dedicato al PHP 7 che potrebbe essere utile per contrastare attacchi CSRF, poi però ho letto, nell'edizione successiva che il metodo prima indicato era quasi del tutto inutile, si suggeriva l'utilizzo di TOKEN prima dell'effettuazione del POST. Ho implementatto questo sistema come suggerito e credo, per quanto leggo in giro, che questo unito alle normali precauzioni sull 'input utente mi consenta un minimo di tranquillità. Grazie ancora per la competenza e la gentilezza delle vostre risposte.

Mauro

Citazione:

---

Originalmente inviato da GraphOGLRisorse

Su AlterVista attulmente il problema è che per evitare di mostrare eventuali messaggi di PHP che visualizzano i percorsi assoluti pubblicamente, si è deciso di far apparire la pagina di errore 500. E questo vale per tutti i tipi di messaggi (notice, warning ed error).

---

Questo è incorretto: notice, warning, e deprecated non causano un errore 500! Ad esempio

Codice PHP:

---

<p>Proviamo con <code>$x = $y</code>
<?php $x = $y ?>

<p>Proviamo con <code>parse_url(null)</code>
<?php parse_url(null) ?>

---

In locale produce

Codice:

---

Proviamo con $x = $y
Warning: Undefined variable $y in /mnt/c/Users/Fra/www/errors.php on line 5

Proviamo con parse_url(null)
Deprecated: parse_url(): Passing null to parameter #1 ($url) of type string is deprecated in /mnt/c/Users/Fra/www/errors.php on line 8

---

Mentre su AlterVista/PHP-8.4 i messaggi di errore non sono visibili, ma lo script completa

Codice:

---

Proviamo con $x = $y

Proviamo con parse_url(null)

---

Se allo script aggiungo

Codice PHP:

---

<p>Proviamo con sintassi rotta</p>
<?php gna_gna(gna)_gna ?>

---

In locale ho un messaggio di errore

Codice:

---

Parse error: syntax error, unexpected identifier "_gna" in /var/www/errors.php on line 11

---

Mentre AlterVista mostra un errore 500 senza altro output.

Citazione:

---

Originalmente inviato da kairos2020

[...] si suggeriva l'utilizzo di TOKEN prima dell'effettuazione del POST. Ho implementatto questo sistema come suggerito e credo, per quanto leggo in giro, che questo unito alle normali precauzioni sull 'input utente mi consenta un minimo di tranquillità.

---

Nota che il metodo token per sessione o form è anch'esso obsoleto, ora che i browser implementano l'header Sec-Fetch-Site, vedi https://cheatsheetseries.owasp.org/c...tadata-headers

Citazione:

---

Originalmente inviato da dreadnaut

Questo è incorretto: notice, warning, e deprecated non causano un errore 500!

---

In locale, certo, non ho un errore 500.

Comunque ho capito come mai a me su AlterVita (almeno con i miei account), mi risultava errore 500 per ogni tipo di messaggio.

Attualmente su AlterVista se non si mette il tag di chiusura di PHP ?>, ogni tipo di messaggio generato da PHP porta a visualizzare un errore 500. Se invece lo si chiude, allora si ha il comportamento citato negli esempi sopra.

Cordiali saluti.

Citazione:

---

Originalmente inviato da GraphOGLRisorse

Attualmente su AlterVista se non si mette il tag di chiusura di PHP ?>, ogni tipo di messaggio generato da PHP porta a visualizzare un errore 500. Se invece lo si chiude, allora si ha il comportamento citato negli esempi sopra.

---

Mmmmh, chissà se c'è qualcosa di diverso sul tuo account, non riesco a riprodurre quello che descrivi 🤔 Ho provato l'esempio sotto, e vedo l'output senza problemi.

Codice PHP:

---

<p>Proviamo con <code>echo $y</code>
<?php
echo $y;
echo "Tutto a posto";

---

Buongiorno, grazie ancora per i suggerimenti, ho fatto un 'giro' alla pagina https://cheatsheetseries.owasp.org/c...tadata-headers, dovrò rileggerla e rileggerla ancora. Per fortuna il tempo non mi manca e sopratutto non devo fare applicazioni 'vere' solo piccole cose per la mia associazione, grazie ancora per l'aiuto. Mauro