Discussion :

[FraktaL]

salut à tous!

Voila mon problème aujourd'hui est le suivant:

J'ai écrit un forum en php et j'ai comme probleme que lorsque les messages contiennent un guillemet ("), il rajoute un backslash (\) devant ce qui donne (\"). Ce n'est pas en soit un réel probleme ca m'arrange meme plutot bien; le seul hic c'est qu'il ne le fait que sur le serveur, en local je dois ajouter moi meme ces backslashes (\). Ce qui m'amene a avoir deux codes différents; un pour le serveur et un pour le local.

Y a-t-il une option que je peux désactiver ou activer en local pour qu'il m'ajoute également ces backslashes devant les guillemets?

D'avance merci pour vos réponses.

[CrazyCat]

la fonction addslashes() doit pouvoir t'aider

[ska_root]

Salut,

oui, il te faut mettre la directive "magic_quotes_gpc" a "on" dans ton php.ini en local
(bien que je préfère personnellement gérer moi-même l'échappement... )

bon développement.

[FraktaL]

ce n'est pas une fonction que je cherche; car si j'utilise cette fonction en local ca me donne (\"), coté serveur ca donne (\\") dans la db.

Je cherche seulement a trouver pkoi en local un guillemet inséré dans la db vaut (") et sur le serveur (\").

Si vous avez une autre idée...

[CrazyCat]

heu non, il vaut mieux faire l'inverse... traiter comme si tu n'avais pas magic_quotes_gpc à on.
Les envois par formulaires sont traités différemment en fonction de la méthode d'envoi et des serveurs, il vaut mieux tout faire soi même.
Petit script utile:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
echo get_magic_quotes_gpc();        // 1
echo $_POST['lastname'];            // O\'reilly
echo addslashes($_POST['lastname']); // O\\\'reilly
 
if (!get_magic_quotes_gpc()) {
   $lastname = addslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}
 
echo $lastname; // O\'reilly
$sql = "INSERT INTO lastnames (lastname) VALUES ('$lastname')";
?>

[FraktaL]

dans ce cas ne vaut t-il pas mieux que je mette la directive magic_quotes_gpc à off coté serveur? mais le prob c'est que je ne peux pas modifier le php.ini car je n'y ai pas acces.

Y a t'il une autre solution pour modifier la valeur de magic_quotes_gpc sans modifier le php.ini?

[ska_root]

oui si ton hebergeur le permet tu peux modifier la valeur avec ini_set() mais il faudra le faire sur toutes les pages (ou alors dans un include systèmatique)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ini_set("magic_quotes_gpc","0");

mais j'insiste, tu peux tout simplement mettre ton php.ini local avec la directive a "off" et comme ça tu as pareil que sur le serveur distant.

ou alors fais comme indiqué plus haut en testant la valeur de la directive puis en ajoutant ou non la fonction addslashes(). mais je trouve ça un peu lourd à gérer, c'est surtout bien quand tu destine ton application à devenir portable.

[CrazyCat]

non, le script que je t'ai donné vérifie l'état de magic_quotes_gpc et agit en fonction (donc ajoute ou pas les \ si nécessaire).

Le mieux est de faire une fonction qui traitera toutes tes variables $_POST à leur reception en intégrant l'état de magic_quotes_gpc.

[FraktaL]

le probleme, crazycat c'est que quand tu fais un forums y a des varibles dans tous les sens et sur toutes les pages. C'est pour ca que la solution de modifier les parametres du serveur me paraissent mieux.

ceci dit avant d'essayer je me demandais une chose: d'après vous c'est mieux d'avoir des (") dans la db ou des (\")?

[Fladnag]

mais je trouve ça un peu lourd à gérer, c'est surtout bien quand tu destine ton application à devenir portable.

mouarf... n'est pas le but de tout code ? le jour ou ton FAI changera de version de PHP et changera allegrement sa config sans prévenir personne ca marchera plus... et qu'on ne me dise pas que ca n'arrive jamais, la preuve avec l'introduction des tableaux super globaux en php 4.1

d'après vous c'est mieux d'avoir des (") dans la db ou des (\")?

Pour moi la BDD doit contenir *exactement* ce qu'a tapé l'utilisateur, donc " dans ton exemple... mais la question est mal posée je pense. Deja le probleme ne se pose pas pour " mais pour ', et lorsque tu fera ton INSERT, tu sera obligé de rajouter un \ devant chaque ' sinon la commande SQL plantera
(

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"INSERT INTO truc(champ) VALUES('machin'chose')"

est invalide,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"INSERT INTO truc(champ) VALUES('machin\'chose')"

est valide et le contenu du champ inseré est bien "machin'chose")
Pour ajouter \ devant les ', il est fortement recommandé d'oublier addslashes() et d'utiliser mysql_real_escape_string

Personnellement, je prefere travailler sans les \, c'est a dire qu'au debut de mon script, je verifie si le magic_quotes_gpc est positionné, et si c'est le cas, je fait un stripslashes().
Je travaille donc toujours sur les données réellement saisi par l'utilisateur.
Lors de l'utilisation d'une valeur saisie dans une requete (INSERT, UPDATE et meme SELECT, c'est pareil) j'utilise mysql_real_escape_string

Maintenant, il est *plus prudent* de travailler avec des \ (c'est a dire d'utiliser addslashes() sur toutes les variables si magic_quotes_gpc n'est pas positionné) car si on oublie a un seul endroit d'utiliser mysql_real_escape_string ou addslashes avant l'utilisation dans une requete :
* Ca peut faire planter le script (pas tres grave)
* C'est une faille de sécurité ouvrant aux SQL Injections (et ca ca peut etre TRES grave)
Evidemment, travailler avec des \ est hyper lourd, puisqu'on est obligé d'utiliser stripslashes a chaque fois qu'on veux recuperer la chaine réellement tapée par l'utilisateur, puis quand meme a nouveau mysql_real_escape_string avant le passage en base.

Un petit mot encore sur la "lourdeur" du test de magic_quotes_gpc :
il n'est pas tres lourd d'ajouter, en debut de chaque page (par exemple dans un include) un parcours des tableaux GET et POST pour modifier les variables.
PHP est deja un langage leger qui n'impose pas la déclaration ou le typage des variables, il me semble que ce n'est pas trop contraignant de s'imposer une sorte de "declaration" de variables pour passer un addslashes ou stripslashes

[FraktaL]

donc si g bien compris:

- je mets ini_set("magic_quotes_gpc","0"); au début de tous mes script;
- du coup ma DB contient exactement ce que le user a tapé sauf pour les apostrophes (').
- chaque fois que je prends des données de la DB, je fais un addslashes() et quand je dois remettre en DB je fais un stripslashes().

c bien ca?

[Fladnag]

arg

donc si g bien compris:

- je mets ini_set("magic_quotes_gpc","0"); au début de tous mes script;

si tu veux, mais en général l'hebergeur a désactivé la fonction ini_set donc ca marchera pas.

- du coup ma DB contient exactement ce que le user a tapé sauf pour les apostrophes (').

soit la BD contient exactement ce qu'a tapé l'utilisateur, soit pas, relis mon message... la maniere dont les apostrophes sont STOCKEES n'est pas un cas particulier. Il n'y a que la maniere qu'on utiliser pour les stockées qui l'est (mais au final, elles seront inchangées dans la BDD!!)

- chaque fois que je prends des données de la DB, je fais un addslashes() et quand je dois remettre en DB je fais un stripslashes().

c bien ca?

non plus.
Quand tu prend de la BDD, si tu as stocké exactement ce qu'a rentré l'utilisateur, tu n'a rien a faire
Quand tu met dans la BDD, tu doit utiliser mysql_real_escape_string et pas autre chose
Quand tu prend d'un $_POST ou d'un $_GET, tu devrais faire addslashes ou stripslashes en fonction de la politique choisie et du positionnement de magic_quotes_gpc

[CrazyCat]

Et le mieux pour stocker dans une base de données, c'est de crypter tes données pour qu'elles ne te posent pas de problèmes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$crypted = addslashes(htmlentities($datas));

A la récupération, si tu veux t'en servir dans une page html, tu fais juste un stripslashes, sinon tu fais un html_entity_decode(stripslashes($datas))

[Fladnag]

Et le mieux pour stocker dans une base de données, c'est de crypter tes données pour qu'elles ne te posent pas de problèmes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$crypted = addslashes(htmlentities($datas));

A la récupération, si tu veux t'en servir dans une page html, tu fais juste un stripslashes, sinon tu fais un html_entity_decode(stripslashes($datas))

Je ne suis pas d'accord non plus. C'est certes plus simple, mais pour moi la base de données doit contenir *exactement* ce qu'a saisi l'utilisateur. Cela pour respecter l'integrité des données.
La fonction htmlentities est une fonction dediée a la mise en forme, en l'utilisant pour stocker des données, on la détourne de sa fonction. De plus, html_entity_decode est relativement recente (>= PHP4.3.0) et n'existait pas avant, ce qui obligeait a la code "a la main" rendant la restitution d'une donnée tres difficile.

Pour moi la mise en forme doit se faire a l'affichage, pas au stockage, ou alors pour des raisons de performances bien identifiées, et en sachant ce que l'on fait...

[ska_root]

mais je trouve ça un peu lourd à gérer, c'est surtout bien quand tu destine ton application à devenir portable.

mouarf... n'est pas le but de tout code ? le jour ou ton FAI changera de version de PHP et changera allegrement sa config sans prévenir personne ca marchera plus... et qu'on ne me dise pas que ca n'arrive jamais, la preuve avec l'introduction des tableaux super globaux en php 4.1

hemm, mon FAI ne changera rien du tout car il ne me sert qu'a me fournir l'ADSL Mes applications fonctionnent sur des serveurs dédiés...
et pour re-situer la question de départ, on veut que le serveur local et le serveur distant ait le même comportement, sachant que l'on a pas la main sur le serveur distant, modifier la conf du serveur local me paraissait le plus adapté, on ne m'a pas laissé imager qu'il y avait possibilité de refonte de l'application entière...

quant au fait de rendre portable le code, je suis d'accord avec toi, cela devrait être une possibilité naturelle, mais c'est malheureusement encore loin d'être le cas...

désolé pour le léger HS FraktaL

[CrazyCat]

Je ne suis pas d'accord non plus. C'est certes plus simple, mais pour moi la base de données doit contenir *exactement* ce qu'a saisi l'utilisateur. Cela pour respecter l'integrité des données.
La fonction htmlentities est une fonction dediée a la mise en forme, en l'utilisant pour stocker des données, on la détourne de sa fonction. De plus, html_entity_decode est relativement recente (>= PHP4.3.0) et n'existait pas avant, ce qui obligeait a la code "a la main" rendant la restitution d'une donnée tres difficile.

Sauf que... ça permet aussi d'éviter l'injection de code
Et je suis désolé de te contredire sur un point: l'utilisateur entre bien un "é" par exemple, mais il devrait normalement rentrer é car il ne connait pas le charset de la page ou de la base.

[ska_root]

désolé CrazyCat, je ne suis pas d'accord non plus

un utilisateur n'a pas a gérer le charset c'est au développeur à l'imposer, il faut pour ceci indiquer au navigateur quel est l'encodage choisi grâce aux directives passées aux headers, puis définir le même encodage dans le fichier, et enfin dans le choix de l'interclassement MySQL

l'utilisateur rentre ainsi "é" et la base prends alors aussi "é" et on affiche bien un "é" dans le browser (a moins bien sûr que l'utilisateur force le charset bien sûr)