Modification directe des superglobaux

J'ai vu des gens (qui écrivent généralement du bon code) modifier directement le $_POSTtableau avec un code comme celui-ci:

// Add some value that wasn't actually posted
$_POST['last_activity'] = time();

// Alter an existing post value
$_POST['name'] = trim($_POST['name']);

// Our pretend function
// Pass the entire $_POST array as data to work with in the function
// The function update_record() will read only the values we actually need
update_record($_POST);

// ...That sure was easier than creating a new array 
//  with only the $_POST values we actually need.

Il est logique de update_record()ne pas accéder directement à $ _POST, nous pouvons donc lui passer d'autres tableaux de données, par exemple, mais c'est sûrement paresseux, de mauvaise conception ou peut-être tout simplement faux? Cependant, nous transmettons toujours un tableau valide à update_record(), alors pourquoi en créer un nouveau?

Ce n'est pas le but de la question, juste un exemple d'utilisation. Cependant, j'ai entendu beaucoup de gens dire que cela ne devrait pas être fait avec des $_REQUESTdonnées, et c'est une mauvaise pratique. Mais pourquoi? Semble assez inoffensif.

Exemples:

• Définition d'une valeur par défaut $_GET(ou post) qui n'existe pas vraiment

• Ajout de $_POSTvaleurs qui n'ont pas été réellement publiées après la soumission d'un formulaire

• Assainissement ou filtrage $_GETdirect des valeurs ou des clés du tableau très tôt dans le script (assainissement de secours ... pourquoi pas?)

• Définir une $_POSTvaleur manuellement avant la soumission du formulaire pour remplir une entrée avec une valeur par défaut (lorsque l'entrée lit $_POSTpour sa valeur par défaut; je l'ai fait)

• Créer vos propres $_SERVERvaleurs? Bien sûr, pourquoi pas?

• $_COOKIEEt les autres, comme et $_SESSION? Bien sûr, nous devons les modifier directement non? Alors pourquoi pas les autres?

La modification directe des superglobaux ne devrait-elle jamais doit-elle être effectuée, ou est-ce OK dans certains cas?

Étant donné que PHP définit déjà ces superglobaux, je ne pense pas que ce soit mauvais de les modifier. Dans certains cas, cela peut être le meilleur moyen de résoudre les problèmes ... en particulier lorsqu'il s'agit de code tiers que vous ne pouvez pas facilement modifier. (Ils peuvent utiliser $_GETdirectement ou supposer qu'une clé existe dans $_SERVER, etc.)

Cependant, d'une manière générale, je pense que c'est une mauvaise pratique lorsque vous écrivez votre propre code. Modifier les $_REQUESTdonnées avec un filtre en arrière-plan qui s'exécute automatiquement sur chaque page est susceptible d'introduire des effets secondaires. (Voir tous les problèmes que les "guillemets magiques" ont causés pour preuve.)

Donc, si vous n'allez pas le faire (filtrer automatiquement les superglobaux), ce qui suit ne vous offre aucun avantage:

$_POST['foo'] = filter($_POST['foo']);

quand vous pouvez facilement faire:

$foo = filter($_POST['foo']);

Je pense qu'il est beaucoup plus clair de faire la distinction à l'échelle du site $_POSTet qu'il $_GETs'agit toujours de données non filtrées et non fiables, et elles ne devraient jamais être utilisées telles quelles .

En copiant la valeur filtrée dans une autre variable, vous prétendez que "je comprends ce que je fais ... j'ai filtré cette entrée et elle est sûre à utiliser".

Je suggérerais généralement que vous ne devriez pas modifier les super-globaux prédéfinis afin qu'il soit clair ce qui est des données filtrées et quelles sont les données brutes / non fiables.

D'autres pourraient suggérer que si vous nettoyez les superglobales au début du cycle de demande, vous n'avez pas à vous en préoccuper ailleurs.

Je les associerais toujours quand vous en avez besoin avec:

$id = (int)$_POST['id'];

ou similaire.

En ce qui concerne les autres variables , il est bon de ne pas écrire à l' une des $_GET, $_POST, $_REQUEST, $_SERVERou $_COOKIE. $_SESSIONcependant, c'est différent parce que vous voulez souvent écrire des données dans la session qui sont ensuite persistées sur différentes requêtes de la session.

Vous devriez l'éviter. Peut-être qu'un certain temps vous avez oublié de nettoyer quelque chose, vous pouvez alors récupérer des données dangereuses. Si vous copiez les données dans une nouvelle structure pendant la désinfection

• Vous obtenez seulement ce que vous voulez / avez besoin et pas ce qui se trouve $_POSTaussi
• Vous obtiendrez probablement une erreur, si le tableau nouvellement créé manque certaines clés ou manque du tout

D'autres scripts supplémentaires peuvent supposer que le tableau est intact et peuvent réagir curieusement.

Je n'ai jamais aimé l'idée de modifier le superglobale car elle est trompeuse. C'est un moyen rapide et hacky de faire quelque chose qu'il y aura probablement une meilleure façon de faire.

Si vous modifiez la valeur de $_POST , par exemple, vous dites que le logiciel a reçu des données qu'il n'a pas reçues.

LE VRAI PROBLÈME

Il y a une situation réelle où cela devient un gros problème:

Imaginez que vous travaillez en équipe. Dans un monde idéal, tout le monde utilise la même syntaxe, mais nous ne vivons pas dans un monde idéal. Un développeur, John, aime accéder aux données publiées à l'aide de $_POST. Il change quelque chose dans les post-vars:

$_POST['ranking'] = 2; // John has changed ranking from 1 to 2 for whatever reason

Ensuite, vous avez un autre développeur, Chris, qui préfère utiliser filter_inputpour accéder aux données entrées (c'est-à-dire GET, POST, SERVER, COOKIE) car il va protéger le logiciel lors du traitement des données que l'utilisateur peut altérer. Dans sa partie du logiciel, il doit obtenir la valeur de poste de ranking. Sa partie du code est AFTER John's.

$ranking = filter_input(INPUT_POST, 'ranking', FILTER_SANITIZE_NUMBER_INT);
// $ranking = 1

Dans l'exemple ci-dessus, en changeant un superglobal, vous avez cassé PHP. John a défini la valeur de $_POST['ranking']2 pour une raison quelconque, mais maintenant Chris a reçu une valeur de 1

Quand je n'ai vu aucun autre moyen de le faire:

J'ai travaillé sur un projet qui utilisait wordpress comme blog derrière un équilibreur de charge AWS. Cela change la valeur de $_SERVER['remote_address']. Dans ce cas, l'autre développeur n'a eu d'autre choix que de procéder comme suit:

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $parts = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    $_SERVER['REMOTE_ADDR'] = $parts[0];
}

Conclusion

Il y a presque certainement un meilleur moyen que de changer les superglobaux

Je pense que la vraie question ici est «pourquoi devriez-vous modifier le thème?». Je ne vois aucune raison valable de le faire. Si vous devez nettoyer un imput, vous pouvez utiliser une variable locale…

À moins que votre code soit suffisamment court (disons, moins de 50 lignes de long), la modification de ces super-globales ne ferait que rendre votre code plus difficile à maintenir et à comprendre.

Soit dit en passant, vous n'avez pas besoin de passer $ _POST à ​​la fonction, car il s'agit d'un tableau superglobal auquel on peut accéder même dans la portée locale d'une fonction.

Après avoir d'abord répondu à cette question en disant qu'il ne devrait pas y avoir de raison de modifier les superglobaux, je modifie cette réponse avec un exemple de moment où j'ai décidé de le faire.

Je travaille actuellement sur une table de base de données de réécriture d'URL dans laquelle la requestcolonne dirige l'utilisateur vers son correspondanttarget colonne .

Par exemple, un requestpourrait être blog/title-hereet targetpourrait l'être blog.php?id=1.

Depuis blog.phpattend des $_GETvariables, et je ne veux pas changer le header("Location:"), je suis laissé faire quelque chose comme ceci:

$uri    = explode('?', $uri_request)[0];
$params = explode('?', $uri_request)[1];
parse_str($params, $_GET);

Cela crée un $_GETtableau contenant les paramètres voulus transmis par la targetcolonne.

En fin de compte, je déconseille fortement de modifier les superglobales à moins que vous ne deviez absolument le faire .