Fil wrote:
>
> dans la base on lit \' au lieu de '.
Non, ça c'est le addslashes obligatoire pour MySQL (pour différencier
les guillemets de la requête des guillemets des données). Du coup on
doit évidemment faire un stripslashes au retour.
NON. Dans la base je peux très bien entrer
update ... set titre = 'L\'andouille';
et dans mysql j'aurai "L'andouille". Normal. Mais là dans mysql je lis
"L\'andouille"...
> Antoine : Pas encore essayé. Bon déjà il faut
> set_magic_quotes_runtime(0),
Oui, en testant qu'il existe (version PHP). Pareil pour le
set_magic_quotes_gpc(1).
Il n'y a pas de set_magic_quotes_gpc, je crois. D'où le hack utilisé l'autre
jour.
Quand je fais update spip_articles set titre="l\'idiot" where id_article=5
sous phpMyAdmin sur rezo.net, et que je récupère sous MySQL, j'obtiens bien
"l'idiot" et non "l\'idiot"....
Il y a donc effectivement des addslashes en trop dans SPIP ;))
C'est assez chiant à corriger, tous les champs de toutes les
tables sont concernés....
Il n'y a pas de set_magic_quotes_gpc, je crois.
Ah ben oui, forcément, ça n'aurait aucun effet....
Il y a donc effectivement des addslashes en trop dans SPIP ;))
En fait il manque un stripslashes() au début, avant le addslashes() qui
envoit dans la base. Ce stripslashes ne doit s'effectuer que si
magic_quotes_gpc est 'true'. D'où le code testé l'autre jour :
> <?
>
> // positionne les magic quotes de base de donnees
> set_magic_quotes_runtime(1); <- tu contestais cette ligne...
>
> // convertit le cas echeant les magic quotes de Get/Post/Cookie
> if (get_magic_quotes_gpc() and is_array($GLOBALS)) {
> while(list($key,$val)=each($GLOBALS)) {
> if (is_string($val)) {
> $GLOBALS[$key]=stripslashes($val);
> }
> }
> }
>
> ?>
mis au tout-début de inc.php3 (et à mettre dans l'espace public là où se
trouvent des récepteurs de données : forum, etc.
On peut donc créer ecrire/inc_magic_quotes.php3 qui fait le boulot ?
Ah oui, il y a un autre problème : ça va faire un stripslashes sur
les variables d'environnement aussi. Ca peut être gênant sous Windows,
s'il y a des chemins contenant des antislashes....
Il faudrait plutôt :
if (is_array($HTTP_GET_VARS)) {
reset($HTTP_GET_VARS);
while (list($key, $val) = each($HTTP_GET_VARS)) {
$GLOBALS[$key] = $HTTP_GET_VARS[$key] = stripslashes($val);
}
}
Ah oui, il y a un autre problème : ça va faire un stripslashes sur
les variables d'environnement aussi. Ca peut être gênant sous Windows,
s'il y a des chemins contenant des antislashes....
Il faudrait plutôt :
if (is_array($HTTP_GET_VARS)) {
reset($HTTP_GET_VARS);
while (list($key, $val) = each($HTTP_GET_VARS)) {
$GLOBALS[$key] = $HTTP_GET_VARS[$key] = stripslashes($val);
}
}
Pareil pour $HTTP_COOKIE_VARS et $HTTP_POST_VARS.
OK, je corrige ça.
Autre chose encore : actuellement spip fait comme si la base de données lui
envoyait des chaînes slashées - et utilise donc stripslashes() sur les
valeurs issues de la base. En ayant nettoyé cette partie, et en utilisant
set_magic_quotes_runtime(0), comme on le fait maintenant, ce stripslashes()
ne se justifie plus. Donc, me direz-vous, il suffit de l'enlever. Oui, mais:
les bases déjà constituées sous spip sont (pour certaines?) slashées par les
anciennes versions. Le laisser ? Pas propre, et ne permet pas de faire comme
titre "voici un slash-guill \'"...
Bref, si on veut vraiment que spip gère bien les slashes, il faut proposer
une upgrade qui nettoie, pas un stripslashes(), tous les champs texte/blob
de la base. Et supprimer stripslashes() de pratiquement tout spip, à
l'exception de inc_version.php3 ; pour un tout petit bug, nous voilà avec un
gros boulot... mais maintenant que l'on "sait", c'est l'angoisse de ne pas
pouvoir utiliser de titres contenant \" ou \' ?
> Bref, si on veut vraiment que spip gère bien les slashes, il faut proposer
> une upgrade qui nettoie, pas un stripslashes(), tous les champs texte/blob
ça risque d'être un peu lourd ;(( je testerai.
Oui, c'est ce que je me disais aussi. Genre marteau pour écraser une mouche.