Annonce

Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

Résumé de la discussion (messages les plus récents en premier)

SabCBien
2015-03-15 20:09:44

Bonjour à tous,

D'abord merci à tous pour les explications.
Après m'être "un peu" amusé avec la gestion des noms de fichiers pour la synchro (apostrophes, accents, tout ça...), je déterre ce sujet, car il me semble (mais je peux hautement me tromper !) qu'il y a une correction en plus à apporter au fichier /include/dblayer/functions_mysql.inc.php (et  /include/dblayer/functions_mysqli.inc.php)

En effet, même en modifiant les 5 lignes indiquées par OBones, une erreur d'insert survenait encore.
Je ne l'ai plus après avoir modifié également la ligne 467 (functions_mysql.inc.php) et 544 (functions_mysqli.inc.php) telle que :

Code:

foreach ($dbfields as $field_id => $dbfield)
      {
        if ($field_id > 0)
        {
          $query .= ',';
        }

        if (!isset($insert[$dbfield]) or $insert[$dbfield] === '')
        {
          $query .= 'NULL';
        }
        else
        {
          $query .= "'".pwg_db_real_escape_string($insert[$dbfield])."'";
        }
      }
      $query .= ')';

Sans ces corrections, je n'arrive pas à ajouter de photos comportant des apostrophes. Cependant, les versions ayant pas mal avancé, peut-être n'est-ce plus la bonne correction ?
Pour ma part je suis à l'heure actuelle en 2.7.4.

D'autre part, j'en profite pour ajouter une question sur le fichier i.php : en ligne 471, il affiche maintenant

Code:

WHERE path=\''.addslashes($page['src_location']).'\'

ce qui n'était pas le cas en version 2.6.1 (et peut être autres, j'ai fait un gros saut).
Ce addslashes va-t-il suffire, car OBones préconisait un pwg_db_real_escape_string (ce que j'avais fait en 2.6.1 et qui fonctionnait).
Je demande cela car il me semble pour les échappements bdd sont gérés expressément par les "_real_escape_string() ".
Mais peut-être l'échappement ds i.php ne concerne-t-il pas les accés à la mysql.

Merci de votre attention !

plg
2013-10-13 11:07:17

Parfait, merci obones (il y a le lien vers ce topic dans le bugtracker, donc si nécessaire on repassera ici)

obones
2013-10-10 13:44:11

C'est fait pour i.php : [Bugtracker] ticket 2971
Pour le reste, vous vous en chargez ?

flop25
2013-10-10 13:13:43

donc Import tree et i.php doivent être patchés
vous pouvez ouvrir un ticket pour i.php ? merci

obones
2013-10-10 13:11:17

Non, i.php doit être patché aussi, il fait ça :

    $query = '
SELECT *
  FROM '.$prefixeTable.'images
  WHERE path=\''.$page['src_location'].'\'
;';

Et là, pas de bol y'a une apostrophe dans src_location (on en revient à Surfer's Paradise) du coup, paf, la requête échoue.
Il faut donc bien patcher pour appeler  mysql_real_escape_string (ou plutôt pwg_db_real_escape_string)

flop25
2013-10-10 13:07:38

en fait c'est juste import tree non ?
i.php utilise sync_chars_regex

obones
2013-10-10 13:06:21

Ah bah ça, je n'en sais rien, je pense que l'équipe en saura plus que moi.
Mais visiblement, les fonctions d'import de masse ne sont utilisés que par piwigo et clairement, les chaînes ne sont pas traitées...
Et i.php ne traite pas non plus comme il faut.

mistic100
2013-10-10 11:52:09

je parle des nombreux plugins qui échappent déjà les données avant

ce que je veux dire c'est que la correction n'est pas forcement à faire dans le fichier de fonctions SQL mais en amont

obones
2013-10-10 11:45:39

Bah pour autant que j'ai pu le tester, mysql_real_escape_string n'est pas appelé et les valeurs sont filées tel quel aux fonctions de functions_mysql.inc.php, d'où les plantages.
Ca fait presqu'un an que je tourne avec ce patch et hormis le soucis des miniatures que j'ai aussi résolu par un appel à mysql_real_escape_string, je n'ai rencontré aucun autre problème.
Après, peut être que les modifs ne sont nécessaires que pour les insertions en masse (je ne fait que ça) mais je ne peux pas en dire plus.

mistic100
2013-10-10 10:11:34

est-ce que ça ne va pas poser des soucis ? dans certains cas real_escape_string sera appliquée deux fois sur les données (une fois fois par le script/plugin une fois par la fonction SQLà

plg
2013-10-10 08:07:55

Bonjour obones,

Peux tu ouvrir un ticket dans le bugtracker http://piwigo.org/bugs et proposer ton patch ?

obones
2013-10-09 22:41:34

Bonjour,

Je viens de faire la MAJ en 2.5 et paf, mes modifs ont été écrasées. Ca aurait été vraiment sympa si elles avaient été incluses, et prises en considération pour la suite.
En effet, une nouvelle fonction est apparue (mass_inserts) et doit elle aussi être patché.

Par ailleurs, en poursuivant plus loin, je me suis aperçu de deux choses :

1.
i.php doit lui aussi être patché, il fait un select sans appel à mysql_real_escape_string

2.
Mettre l'esperluette dans les caractères autorisés est une très mauvaise idée, ce caractère étant réservé pour les URLs. A ce titre, sa présence dans le chemin d'un fichier provoque divers plantages et comportements erratiques, notamment dans i.php
Il faut donc le retirer de la regex et renommer les répertoires/fichiers incriminés, c'est bien plus sûr.

obones
2012-12-22 11:26:12

Bonjour,

Le problème se situait dans /include/dblayer/functions_mysql.inc.php, voici le fichier diff au format unified:

--- functions_mysql.inc.php~    2012-11-12 13:08:24.000000000 +0100
+++ functions_mysql.inc.php    2012-11-12 13:08:24.000000000 +0100
@@ -235,7 +235,7 @@

         if (isset($data[$key]) and $data[$key] != '')
         {
-          $query.= $separator.$key.' = \''.$data[$key].'\'';
+          $query.= $separator.$key.' = \''.mysql_real_escape_string($data[$key]).'\'';
         }
         else
         {
@@ -258,7 +258,7 @@
           }
           if ( isset($data[$key]) )
           {
-            $query.= $key.' = \''.$data[$key].'\'';
+            $query.= $key.' = \''.mysql_real_escape_string($data[$key]).'\'';
           }
           else
           {
@@ -372,7 +372,7 @@

     if (isset($value) and $value !== '')
     {
-      $query.= $separator.$key.' = \''.$value.'\'';
+      $query.= $separator.$key.' = \''.mysql_real_escape_string($value).'\'';
     }
     else
     {
@@ -395,7 +395,7 @@
       }
       if ( isset($value) )
       {
-        $query.= $key.' = \''.$value.'\'';
+        $query.= $key.' = \''.mysql_real_escape_string($value).'\'';
       }
       else
       {
@@ -514,7 +514,7 @@
       }
       else
       {
-        $query .= "'".$value."'";
+        $query .= "'".mysql_real_escape_string($value)."'";
       }
     }
     $query .= ')';


J'ai fait les changements partout où j'ai pu même si dans mon cas précis, il n'y avait que deux endroit vraiment utiles pour l'import en masse. Mais comme je fais des mises à jour plus tard, j'ai décidé de changer partout où c'était possible.

flop25
2012-12-19 16:25:54

je reviens sur le sujet : normalement Piwigo échappe les caractères spéciaux
Dans quel cas cela posait problème ?

obones
2012-11-12 13:35:40

Merci pour la suggestion, je suis effectivement passé par sync_chars_regex à qui j'ai donné cette valeur :

/^[a-zA-Z0-9-_. àäéèëêîïôöùûç\&\(\)\',!°]+$/

Bon, ok, ça fait un peu beaucoup, mais là, j'ai tout qui s'importe.
Enfin, au détail près que j'ai du rajouter des appels à mysql_real_escape_string dans le fichier des fonctions DB pour que les noms avec apostrophe (Surfer's Paradise par exemple) ne provoquent pas de plantage dans les requêtes.

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact