Tag : Bugs

Prestahop : import d'images sur un hébergement mutualisé OVH

http://www.maraumax.fr/medias/Billets/prestashop_web_design.pngAprès avoir passé de nombreuses minutes heures sur l'import prestashop et en consultant les différents forums j'ai faillit désespérer ! Mais finalement en allant voir un peu le code source et à coup de var_dump j'ai compris l'origine de mon soucis d'import. Enfin...

A chaque import j'avais l'erreur suivante :

Erreur lors de la copie de l'image: ../import/toto.jpg

Avant toute chose je suis sur la version 1.6 de prestahop donc faites attention à la votre car le problème est peut-être différent. Pensez lors de vos tentatives d'import à avoir qu'un seul produit et image dans votre CSV dans un premier temps afin de gagnez en vitesse wink Surtout quand vous effectuez une bonne dizaine voir centaine de tentatives.

En regardant dans le fichier classes/Tools.php avec la fonction static copy() je me suis rendu compte que Prestashop ajoutait un slash en début de chaine source si il n'y en avait pas. Si bien que mes dossiers relatifs n'étaient pas correcte. Par exemple ../images/toto.jpg était transformé en /../images/toto.jpg et forcément ça fonctionne moins bien...

J'en suis arrivé à la conclusion suivante : il faut partir de la racine de l'hébergement. Ainsi chez OVH pour obtenir le chemin complet, voici la structure à respecter :

/home/prestashop/www/imgs/toto.jpg
prestashop = votre login FTP OVH
imgs = un dossier crée à la racine du répertoire FTP

Il vous suffit ensuite de reprendre ce chemin complet dans votre fichier d'import et vos images fonctionnerons parfaitement !

Merci a la communauté prestashop pour leurs différentes pistes.

Problème avec Pure Ftp Mysql et Inetd

Inetd est un démon très avantageux qui active automatiquement un service lorsqu'un client tente de s'y connecter. Il permet donc d'allouer des ressources uniquement quand c'est nécessaire. Suite à une mise à jour des paquets un serveur Debian, je me suis retrouvé avec une erreur lors de la connexion au ftp.

Can't exec "/usr/sbin/pure-ftpd": No such file or directory at /usr/sbin/pure-ftpd-wrapper line 174.

Cette erreur apparaît car inetd a mal été configuré avec pure ftp mysql. Pour la corriger il suffit d'éditer les quelques premières lignes du fichier /usr/sbin/pure-ftpd-wrapper.

Remplacez les trois lignes suivantes :

my $daemon = '/usr/sbin/pure-ftpd';
my @capabilities = @ARGV;
 
if ($ARGV[0]) {
$daemon = "$daemon-$ARGV[0]";
}

Par ceci :

my $daemon = '/usr/sbin/pure-ftpd-mysql';
my @capabilities = @ARGV;
 
#if ($ARGV[0]) {
#$daemon = "$daemon-$ARGV[0]";
#}

On a donc remplacer le chemin du démon et commenté les quelques lignes qui normalement auraient du ajouter "-mysql" au nom du démon.

Vous pouvez ensuite redémarrer inetd, et tout devrait à nouveau fonctionner !
/etc/init.d/openbsd-inetd restart

En espérant vous avoir rendu service !

Petite faille sur le site comment ça marche

J'effectuais tranquillement une recherche sur un comportement javascript avec les champs textarea lorsque je me suis retrouvé sur une page du site généralement intéressant commentcamarche.net

Je me suis rapidement aperçu que la page sur laquelle je naviguait présentait un soucis : un champ textarea (sujet de ma recherche) présent dans le titre et contenant de nombreux caractères. (Tout le code suivant à vrai dire car la balise textarea n'était pas fermée)

Pour vérifier tout ça rien de bien compliqué : ajouter directement un code javascript dans le titre du sujet à crée.

Et voici le résultat...

http://www.maraumax.fr/medias/Billets/faille_commentcamarche.png
Ironie du sort j'ai posté dans le forum programmation... bref. Je contacte de suite les administrateurs du site afin d'éviter tout autre tentatives avec des scripts présents sur des serveurs distants ce qui serait bien plus conséquent.

Pour information il s'agit d'une des failles les plus communes, communément appelées failles XSS.