Bonjour,
 
J'ai une erreur quand mon script s'execute :
Parse error: parse error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting T_STRING or T_VARIABLE or T_NUM_STRING in H:\maquette intranet\stockMessage.php on line 30
 
voici la ligne en question :
 

 
Donc je pense que le problème  vient de mes variables que je place dans la requête, je pense qu'il faut les entourer d'accolades. Or j'ai déjà essayer et ça ne marche pas !
 
Merci pour votre aide !

il faut ajouter ' ' entre chaque champ:

Le problème vient du fait que t'essaye d'accéder à une case d'un tableau à l'intérieur d'une chaine de caractère ce qui est ambigüe :
"$_SESSION['nom']" veut il dire "contenu de $_SESSION suivit de la chaine "['nom']" ou bien contenu de la case 'nom' du tableau $_SESSION?
 
Au début php laissait faire ce genre de bêtise et ça a été la cause de  beaucoup de bugs.
 
Si tu veux éviter ce message t'as deux solutions :
- indiquer le début et la fin de la variable

, {$_SESSION['nom']},

- sortir la variable de la chaine de caractère (solution la plus propre)

, ".$_SESSION['nom'].",

 
En plus de ça ta requête ne risque pas de marcher faute de délimiteur de chaine pour la base de donnée (comme indiqué par Marty_McFly) et même une fois corrigé comme indiqué par Marty_McFly, elle présente de gros problèmes de sécurité si tu n'utilises pas des fonctions telles que mysql_real_escape_string ou des requêtes préparé (PDO, prepared_statement, ...)

Merci omega2 je n'ai plus d'erreur, mais la base de données ne se rempli pas pour autant :s
 
Marty_McFly ta solution ne marche pas par contre !
 
EDIT: Omega juste une question, pourquoi on doit indiquer les limites de la variable uniquement pour $_SESSION et pas pour les variable $id[]?

Ah? et quelle est l'erreur renvoyée ?
 

mysql_query("INSERT INTO mp VALUES('', '".$nomModule."', '".$id[0]."', '".$id[1]."', '".$_SESSION['nom']."', '".$_SESSION['prenom']."', '".$demande."')" );

Le double single quote ..  

Hum ... Y a t'il quelqu'un qui a fait attention à la fin de mon message?

De ce que je lis, toutes vos propositions laissent telles qu'elles les failles de type "Injections SQL" et autres problèmes du genre "ouin, ca plante quand on saisie "j'ai" dans le formulaire".

je suis d'accord. Mais rien n'indique qu'il ne l'a pas fait de son coté. Et puis, le mysql_real_escape_string peut tres bien etre fait avant l'execution de la requete:

 
Perso je n'utilise pas (encore) de requetes préparées, et les fonctions telles que mysql_real_escape_string, je m'en sers disons... TRES souvent .

 
Il prenait le {$_SESSION['nom']} et le {$_SESSION['prenom']} comme le nom d'un champ de la table. J'ai contourner le problème ainsi :

 
Concernant la sécurité, ce script est fait dans l'optique d'un intranet donc pas de risques d'intrusion de l'extérieur (enfin je pense, je n'y connais absolument rien en sécurité).

Si tu savais le nombre d'entreprises qui se sont rendus comptes après coup qu'un de leurs employés était un indélicat (pour ne pas dire un filou) ...
 
Même si c'est pour un intranet, il faut tout sécuriser comme il faut pour plusieurs raisons :
1) même si on a confiance en ses employés on ne sait jamais ce qui peut se passer (ça n'est pas une question de paranoïa mais de bon sens)
2) pour le moment c'est un intranet mais si plus tard vous faites un site internet ou un extranet (intranet accessible depuis l'extérieur) vous risquez de réutiliser le même code, code qui n'est pas sécurisé. A noter qu'il y a beaucoup plus de chance d'oublier de sécuriser une donnée quand on le fait après coup que quand on le fait au fur et à mesure
3) quand on prend de mauvaises habitudes, il est très dur d'en reprendre ensuite de bonnes : si tu ne prends pas dès maintenant l'habitude de sécuriser ce qui doit l'être alors tu risques d'oublier une fois sur deux de sécuriser ton code quand on t'obligera à le faire
4) même si les attaques ne sont pas toujours volontaires l'absence de sécurité laisse des failles qui ont une bonne odeur de bug. Par exemple si tu n'utilises pas de "mysql_real_escape_string" ou une autre méthode équivalente un simple "j'ai" ou un 'Et il a dit "je suis dieu" ' fera planter ta requête.

D'accord merci, je vais me renseigner sur les tutos traitant de la sécurité avec php car il est vrai que mon intranet tend à devenir un extranet !
 
Concernant mysql_real_escape_string:
 
J'ai un $nomModule qui vaut = Prière d'admettre.
Bien évidemment la requête plante à cause de l'apostrophe j'ai donc essayer ceci juste avant l'envoie de la requête :
mysql_real_escape_string($nomModule);
 
Mais toujours la même erreur. Si j'ai bien compris, mysql_real_escape_string permet d'éviter les erreurs de syntaxe normalement?
 
merci !

mysql_real_escape_string retourne une version sécurisé (pour mysql) de la valeur qu'on lui met en paramètre mais ne modifie pas la variable qu'on lui donne en paramètre.
Si t'as fait, par exemple :

mysql_real_escape_string($MaVar);
mysql_exex("SELECT colonne FROM table WHERE champ='$MaVar'";

alors ça n'est pas bon car le contenu de $MaVar n'a pas été modifié.
 
La version correcte est :

$MaVar = mysql_real_escape_string($MaVar);
mysql_exex("SELECT colonne FROM table WHERE champ='$MaVar'";

$MaVar contient une version sécurisé de son contenu d'origine.
 
PS : Personellement je préfixe les noms des variables afin de différencier celles qui sont sécurisé de celles qui ne le sont pas. Ca me permet aussi de différencier les différentes sécurité et enfin ça me permet d'appliquer des sécurités différentes si j'ai besoin (mysql pour l'une, html pour l'autre si je dois réafficher le texte, ...) . Avec l'exemple précédant, ça pourrait donner "$SecMySql_MaVar = mysql_real_escape_string($MaVar);".
J'ai aussi pris pour habitude de préfixer en fonction du contenu de la variable avec vérification du contenu dès l'apparition des données. En pratique l'ensemble des deux me donne :
"$Int_MaVar" pour un entié
"$St_MaVar" pour un texte non sécurisé
"$St_html_MaVar" pour un texte sécurisé à l'aide d'htmlentities (sécurisé pour affichage dans un navigateur)
"$St_mysql_MaVar" pour un texte sécurisé afin d'être mise dans une requête exécuté par mysql
...
 
EDIT : En préfixant les variables ça m'évite aussi d'utiliser des données non sécurisé. Si j'oublie un htmlentities par exemple j'aurais une variable inexistante au lieu d'avoir un trou de sécurité.
Je préfaire considérer qu'il vaut mieux ne rien afficher, s'en rendre compte dessuite et perdre une heure ou deux à chercher d'où ça vient que de ne pas s'en rendre compte avant de subir une attaque, et perdre encore plus de temps puisqu'en plus du temps de la réparation du bug, il y aura le temps passé à réparer les dégâts, à neutraliser les données stockés sans neutralisation de leur contenu (si c'est nécessaire) et qu'en plus de ça bosser en étant très stresser, c'est prendre le risque de faire des erreurs et quand une faille est découverte à la suite d'une attaque, on peut être sur de subir un gros coup de stress.

Merci pour les conseils ça marche bien !
 
Bon mon projet c'est un peu le "bordel" donc je pense que je serais plus organiser la prochaine fois (la j'ai la flegme de tout reprendre) et j'appellerai mes variables de façon plus intelligible !
 
merci bien

Ok, je comprend, moi aussi ça a été pareil au début et j'ai même eu une période transitoire où j'avais des bouts de codes avec des préfixes et des bouts de codes où il n'y en avait pas (gros bordel au final).
 
En fait, je ne pense pas qu'on entende souvent parler de convention de codage quand on fait des études d'informatique et du coup on passe tous par une période où on ne préfixe rien.