8791 sujets

Développement web côté serveur, CMS

Bonsoir à tous.

Me voilà face à un problème que je n'avais encore jamais vue, après des heures de recherche, je me dirige vers vous Smiley smile

J'ai pour projet de réaliser un site pour un studio d'enregistrement, le seul soucis est que quand je rentre une biographie d'un artiste et que j'envoie le formulaire, je me retrouve avec une erreur.

L'erreur s'execute uniquement lorsque la bio est d'une certaine taille, si par exemple je met quelques caractères, tout s'enregistre correctement, au contraire si je fais un copier coller de Lorem Ipsum, aucun enregistrement.

Donc vous aurez compris mon titre, dans ma BDD, le type TEXT à t-il une certaine limite de caractère ou est-ce un problème dans mon script ?

voici l'erreur en question :
Warning: mysql_error() expects parameter 1 to be resource, boolean given in C:\wamp\www\Artevox\admin\artistes.php on line 45


Voici les lignes correspondante :

if(isset($_POST['ajouter']) && !empty($_POST['ajouter'])) {
					if (isset($_POST['ajout_name']) && !empty($_POST['ajout_name'])) {
						
						extract($_POST);
						$ajout_name = trim(htmlspecialchars($ajout_name));
						$ajout_date = htmlspecialchars($ajout_date);
						$ajout_bio = htmlspecialchars($ajout_bio));
						$ajout_site = htmlspecialchars($ajout_site);
						$insert = mysql_query("INSERT INTO artistes VALUES('', '". $ajout_name ."', '". $ajout_bio ."', '". $ajout_site ."', '". $ajout_date ."')") or die(mysql_error($insert));
						mkdir ("../collectif/artistes/$ajout_name"); 
						echo "Elément enregistré" ;
					}
		}


Merci à tous pour votre aide Smiley smile
Salut,

alors dans le désordre :
* soit tu utilises juste mysql_error(), soit tu utilises mysql_error($link) où $link est comme suit :
$link = mysql_connect("localhost", "mysql_user", "mysql_password");
* il ne faut pas utiliser htmlspecialchars mais mysql_real_escape_string.
* il faut être prudent quand on utilise extract (ce que tu n'es pas) : lire les avertissements en se rappelant qu'on peut recevoir n'importe quelles données en POST avec CURL.
* il ne faut pas créer un répertoire sans faire aucun test sur ce que contient une variable postée par un visiteur !

D'une manière générale je pense que tu devrais passer un peu de temps à relire quelques tutos sur php/mysql... et sur la sécurisation. Smiley cligne
Modifié par Heyoan (22 Aug 2010 - 22:30)
Merci de ta réponse,

En faite tous ça c'est dans la partie administration... afin que l'admin ajoute un artiste.

Pourquoi utiliser mysql_real_escape_string que htmlspecialchars ?

En effet, il faut que je revois les tutos ^^

Pour mon problème, j'ai chercher sur le web, je n'ai pas trouvé grand chose Smiley decu
Désolé pour ce double post,

après l'essai de mysql_real_escape_string, tout fonctionne.
Faut vraiment que je retourne sur les tutos Smiley smile

Merci beaucoup en tous cas.
Bonne soirée
Pour que tu comprennes, quand même, la différence entre html* et mysql_real_escape_string, il faut que tu comprennes à quoi elles servent, et quel est ton but.

Objectif : éviter les injections SQL par l'insertion de caractères foireux dans une requête: NUL (le vrai), ', \ et pléthores.

html* : transforme les entités éligibles HTML en entités non-traduisibles. Techniquement, on va utiliser, pour chaque entité rencontré, le code HTML correspondant; pour <, &gt;, etc.

mysql_real_escape_string : "protège" les éventuels caractères foireux d'une requête.

html* (CQFD htmlspecialchars et htmlentities) ne servent qu'à protéger des failles XSS, à l'affichage. mysql_real_escape_string est là à l'enregistrement.

Et n'appliques pas html* à l'enregistrement. Ce comportement irresponsable provient d'un bug de historique de phpmyadmin.
Salut,

Lpu8er a écrit :
Et n'appliques pas html* à l'enregistrement. Ce comportement irresponsable provient d'un bug de historique de phpmyadmin.
Et d'une flopée de tutos (notamment ceux du SDZ) qui ont présentés cette manière de faire pendant des années avant d'être enfin mis à jour. Smiley cligne
C'est se voiler la face, ça.
Ces tutos ne viennent pas de nulle part.
Mais là n'est pas la discussion, et j'espère que l'auteur aura compris les différences. Petite subtilité (quand même), html* peut prendre un troisième (en plus du second) paramètre : l'encodage, défini à ISO-8859-1 par défaut (et il faudra attendre PHP 6, donc un long moment avant d'avoir de l'UTF-8 par défaut).
Lpu8er a écrit :
C'est se voiler la face, ça.
Euh... pas compris en quoi je me "voile la face". Smiley rolleyes

Tu veux dire que ce n'est que la faute de ce bug de phpMyAdmin et que le fait que les tutos n'aient proposé que cette façon de faire pendant de nombreuses années n'a rien à voir avec le fait qu'on retrouve cela encore un peu partout ? De même qu'on a vu pendant des années l'utilisation de htmlentities au lieu de htmlspecialchars qui convient pourtant dans 99% des cas dès lors qu'on a la main sur l'encodage ?