Avantages de cet algo

[okoweb]

Code :

1
2
3
4
5
6
7
 
if(isset($_GET['id'])){
  $id =(int)$_GET['id'];
  unset($_GET['id']);
  //Suite du code avec $id
  ...
}

A quoi peut vraiment servir ce bout de code ? Pourquoi détruire $_GET['id']

Code :

unset($_GET['id']);

et pour le reste du code bosser avec $id ?

Merci d'avance...

[transgohan]

Il est vrai qu'à part être sûr que la valeur ne pourra être réutilisé sans être épurée et testée il n'y a aucun intérêt.
Mais c'est tout de même un très bon point que d'interdire d'utiliser une variable brute.

[ThomasR]

Ya quand même plus simple :

Code :

1
2
3
 
if(isset($_GET['id']))
    $_GET['id'] = intval($_GET['id']);

comme çà quelque-soit le code qui utilise la variable passée en paramètre elle est bien nettoyée. De plus cela permet de conserver un fonctionnement normal d'application sans se casser la tête.

[ABCIWEB]

Comme l'a dit transgohan on évite d'utiliser directement des variables externes comme $_GET, $_POST, $_COOKIE, puisque celles-ci peuvent être définies directement pas l'utilisateur.
Dans ton exemple $_GET['id'] est transtypé en entier, et donc "id" sera nécessairement un entier.

On peut faire aussi comme dit ThomasR, chacun fait suivant ses préférences et suivant ses besoins, mais l'important est de prendre l'habitude de vérifier ses variables avant de les utiliser.

Souvent on profite de l'occasion pour attribuer une valeur par défaut, par exemple

Code :

$id = isset($_GET['id']) && is_numeric($_GET['id']) ? intval($_GET['id']) : 0;

[okoweb]

Bjr,
Pour les données provenant d'un formulaire

Code :

1
2
3
 
$id =$_POST['var'];
unset($_POST['var']);

Ceci ne résoudrait pas le problème de rafraichissement d'une page recevant les données d'un formulaire ?

[Benjamin Delespierre]

Tant que le formulaire est soumis en HTTP classique (et non pas avec un XHR) le rafraichissement de page se produit car le navigateur fait partir une nouvelle requête POST.

[RunCodePhp]

Salut

Ceci ne résoudrait pas le problème de rafraichissement d'une page recevant les données d'un formulaire ?

Théoriquement non.
Quand on rafraichi (ou actualise) une page contenant un formulaire, les données sont à nouveaux transmises, donc ensuite à nouveau récupérées par le serveur et le même code sera alors exécuté.

Ce que ThomasR à suggéré me semble plus judicieux : filtrer la donnée plutôt que la détruire.


Ceci dit, quand on regarde comment procède certains FrameWork, ils procèdent en gros de la même manière que tu fais.
En gros ils stockent les données GET/POST entre autre dans un Objet, les filtre par la même occasion.
Les tableaux $_GET $_POST sont détruits/vidés, et c'est via l'Objet dédié qu'il faut exploiter coté application.

Ce n'est pas tous les FrameWork qui le font, mais n'empêche ça se fait.

[ThomasR]

Ceci ne résoudrait pas le problème de rafraichissement d'une page recevant les données d'un formulaire ?

Non car le navigateur va exécuter la requête HTTP précédente, et pas à partir de la réponse HTTP.

[ABCIWEB]

Si l'on te t'a pas parlé de unset($_GET['id']); c'est que cela devait être spécifique au code que tu as pris en exemple : ce n'est pas une manière générique de faire.
On peut effacer cette variable si l'on en as plus besoin (comme toutes les autres variables), mais il est peu fréquent (sauf nécessité spécifique) d'avoir besoin le faire.

Pour éviter de re soumettre un formulaire au rafraichissement de la page, tu peux rediriger vers la même page (ou une autre) avec un header

Code :

1
2
3
4
5
6
7
if (isset($_POST['valider']))
 
{
// traitement du formulaire
 
header('Location: '.$_SERVER['PHP_SELF']); //redirection vers la page en cours
}

[RunCodePhp]

Envoyé par ABCIWEB

Pour éviter de re soumettre un formulaire au rafraichissement de la page, tu peux rediriger vers la même page (ou une autre) avec un header

Pour le rafraichissement, d'accord, mais si l'internaute reviens petit à petit en arrière via l'historique (page précédente), il reviendra à un moment au même formulaire, donc quelque part le soumettre une 2ème fois.
Voir même 3, 4 fois qui sait pour peu qu'il soit dyslexique.

D'ailleurs, et quand j'observe des personnes pas très initiées, j'ai plutôt tendance à remarquer que l'action de retour en arrière (et plusieurs, genre history -2, -3) serait bien plus utilisée que le rafraichissement de la page.

Donc quelque part un header() ne serait pas vraiment l'arme absolue du problème assez courant de la double insertion en Bdd.

[sabotage]

mais si l'internaute reviens petit à petit en arrière via l'historique (page précédente), il reviendra à un moment au même formulaire

Je n'ai pas fais le test mais dans ton historique de navigation, tu devrais n'avoir que le formulaire et la page de destination de la redirection, pas l'etape de traitement.
donc si tu fais précedent, tu reviendras sur le formulaire et il faudra cliquer explicitement sur valider pour avoir une double insertion.

[ABCIWEB]

Envoyé par RunCodePhp

Pour le rafraichissement, d'accord, mais si l'internaute reviens petit à petit en arrière via l'historique (page précédente), il reviendra à un moment au même formulaire, donc quelque part le soumettre une 2ème fois.
...
Donc quelque part un header() ne serait pas vraiment l'arme absolue du problème assez courant de la double insertion en Bdd.

Essayes

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
if (isset($_POST['valider']))
{
header('Location: '.$_SERVER['PHP_SELF']);
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Document sans titre</title>
</head>
 
<body>
<form method="post" action = "#">
<input type = "text" name= "nom" />
<input type = "submit" name = "valider" value= "valider" />
</form>
<a href="index.php">index</a>
</body>
</html>

envoies le formulaire puis balade toi sur le lien index.php, reviens en arrière autant de fois que tu veux, ou rafraichis le formulaire, mais bon moi jamais le navigateur ne me propose de re soumettre le formulaire

[RunCodePhp]

Envoyé par sabotage

donc si tu fais précedent, tu reviendras sur le formulaire et il faudra cliquer explicitement sur valider pour avoir une double insertion.

Et bien justement, observe des gens plutôt novices coté Web, et bien ils ne comprennent pas vraiment ce que le message indique (soit revalider le formulaire), et il y 1 chance sur 2 qu'ils cliquent sur "Oui" ou "Non".
Donc une chance sur 2 que ça refasse le même traitement.

C'est à mon sens beaucoup courant qu'on ne le croit.

[ABCIWEB]

Envoyé par RunCodePhp

Et bien justement, observe des gens plutôt novices coté Web, et bien ils ne comprennent pas vraiment ce que le message indique (soit revalider le formulaire), et il y 1 chance sur 2 qu'ils cliquent sur "Oui" ou "Non".
Donc une chance sur 2 que ça refasse le même traitement.

C'est à mon sens beaucoup courant qu'on ne le croit.

Nan... il n'y aura pas de message, essayes le code plus haut et dit moi dans quelles conditions le navigateur t'envoies un message ? Moi je n'en vois jamais.

[RunCodePhp]

mais bon moi jamais le navigateur ne me propose de re soumettre le formulaire

Je fais aussi comme ça (un header) absolument partout pour les formulaire (et plus même), ça fonctionne plutôt bien, effectivement.

Mais il me semble qu'il y a quand même des cas où un risque persiste.

Difficile de re-tester tout ça vu que de mon coté je prends pas mal de précautions pour justement éviter ces risques de double insertions.

[Eric2a]

Salut,

Pareil car la fonction header redirige et les données (POST dans l'exemple) ne sont plus passées.

[ABCIWEB]

Ben oui, donc jusqu'à preuve du contraire (que je n'ai jamais constatée), il semble bien que la redirection après un post soit l'arme absolue pour éviter les messages du navigateur en cas de rafraichissement ou utilisation des boutons de navigation du navigateur

[okoweb]

Envoyé par RunCodePhp

Mais il me semble qu'il y a quand même des cas où un risque persiste.

Difficile de re-tester tout ça vu que de mon coté je prends pas mal de précautions pour justement éviter ces risques de double insertions.

Quelles genres de précautions preniez-vous ?

[RunCodePhp]

Quelles genres de précautions preniez-vous ?

Je ne vais pas pouvoir te les énumérer comme ça, de plus, il n'y a rien d'extraordinaire.

Une précaution, ça veut dire de faire une (voir plusieurs) vérifications.
Cas typique : Vérifier qu'un login et mot de passe n'existe pas avant de faire l'insertion en est une, et tout le monde la connait.
Donc vérifier en 1er que quelque chose n'existerait pas déjà fait partie du BABA s'il est spécifier qu'il ne doit pas en avoir 2.


Après, ça, et pour le reste, on peu s'appuyer sur des ajouts de données dans des champs cachés pour vérifier celle saisie et celle dans le champ caché.
Si c'est la même chose, on ne poursuit pas.
On peu s'appuyer sur les session, cookie, etc, etc ...

Encore une fois, rien d'extraordinaire, tout ça tu connais déjà j'en suis certain.
Faut juste les exploiter si le besoin le demande.


Et encore, je n'exploite pas tout ce qui est possible dans ce domaine, car il y a l'intégrité référentielle, de même que les transaction.
J'ai pas d'autre choix que d'utiliser MyISAM comme moteur MySQL (et non InnoDB).
C'est d'ailleurs en grande partie à cause de ça que ça oblige de le faire "à la mano".


En tout cas, ce que je voulais dire c'est que un header() n'est vraiment pas l'arme absolue, car selon des cas, selon la manière dont on effectue certaine opération, on ne peut justement pas faire de header(), donc le risque persiste.
Je pense particulièrement à l'Ajax qui sans précaution favorise grandement le risque d'incohérences.
Faire une vérif reste la manière la plus fiable.

De plus, quand bien même qu'on ait pris soin de mettre un header(), rien n'empêche de revenir au formulaire précédent, qui plus est on aura pris soin de le pré-remplir, et hop, l'utilisateur valide instinctivement.
Là encore sans précaution ça débouche sur un doublon.



Petite parenthèse tout de même.
J'évoque seulement des doublons, qui sous entendent uniquement insertion.
Mais les risques sont quasi les même pour les 3 opérations : insertion, mise à jours et suppression.