Ho trovato una soluzione parziale.
Il problema è che nel caso di un redirect HTTP 301, i dati passati via vettore $_POST vengono accodati con metodo GET; per evitare questo ci vuole un redirect HTTP 307, ovvero temporaneo anziché permanente:
In questo caso la pagina file.php si troverà a disposizione il vettore $_POST bell'e pronto, uguale a quello che vede la pagina slave che effettua il redirect.Codice PHP:<?php // Pagina slave di un form;
header("HTTP/1.0 307 Temporary redirect");
header("Location: www . sitedomain . ext/dir/file.php");
?>
La fregatura è che il browser vede questo reindirizzamento, e qui entrano in funzione le misure di sicurezza: Firefox ad esempio apre un confirm box in cui informa l'utente che la pagina a cui puntava il form sta indirizzando ad un'altra pagina, chiedendo conferma per inviare i dati del form anche alla nuova pagina.
Le specifiche W3C sui protocolli infatti parlano chiaro:
Inoltre siccome basta poco per leggere gli header HTTP (e quindi per scoprire le pagine a cui le richieste HTTP vengono reindirizzate) gli accorgimenti per la sicurezza che mi interessavano sarebbero inutili (== far risiedere su un'altra locazione lo script che elabora le info postate senza usare un include() o require()).Originariamente scritto da w3c.org
If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Questo comunque avverrebbe anche con la composizione "manuale" dell'header HTTP contenente dei postdata, quindi non ci sarebbe alcun vantaggio...
Rispondi quotando