$_server['http_referer']

[kairos2020]

Buongiorno, la seguente riga di codice :

    $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

[GraphOGLRisorse]

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:

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:

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

Per evitarlo, bisogna aggiungere un controllo:

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

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

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

Cordiali saluti.

[kairos2020]

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

[GraphOGLRisorse]

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ì:

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.

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.

[dreadnaut]

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

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

Tornando al primo messaggio, il codice

$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+:

> 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".

[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).

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.

[kairos2020]

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

[dreadnaut]

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

<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

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

Proviamo con $x = $y

Proviamo con parse_url(null)

Se allo script aggiungo

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

In locale ho un messaggio di errore

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

Mentre AlterVista mostra un errore 500 senza altro output.

[...] 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