Nicowcow

M. Baquet, Je voudrais vous rappeler que vous vous adressez à vos clients sur ce forum. Un peu de tenue serait la bienvenue. Il faudrait vraiment revoir votre communication, être méprisant n'arrange en rien votre image sur ce topic. Manifestement, plusieurs de vos clients sont mécontents (mon agence comprise) de votre stratégie commerciale, peu importe à qui la faute, nous attendions au minimum des excuses.

Je ne suis pas sûr que couper le fonctionnement d'un module payant soit quelque chose de normal. Je sais bien qu'Amazon impose sa loi mais certains appelleraient cela de l'obsolescence programmée...

+1 même souci que Giga_Boss L'API du module AMAZON Common Service ne fonctionne plus. Module périssable à fuir absolument. Je vais également faire une réclamation auprès de Prestashop addons.

Bonjour à tous ! J'ai un multiboutiques 1.7.6 qui est hébergé sur un serveur dédié avec une version PHP 7.1 Pour le back office, j'utilise le même domaine qu'une boutique en front office. Mon problème est que lorsque j'effectue un processus en back (par exemple une sauvegarde d'un produit via domaine1.com), si j'essaye d'actualiser ce même domaine en front office en même temps, la boutique va attendre que le processus du back se termine pour afficher la page. Même chose si on essaye par exemple de modifier 2 produits en back en même temps, les processus ne se lancent pas en même temps. Le deuxième va attendre que le premier soit terminé pour s’exécuter. Et ça devient gênant lorsque l'on a une équipe de 3 à 4 personnes qui bosse en même temps sur le back. Est-ce un comportement normal ou cela vient-t'il de la configuration php du domaine en question ? Voici la configuration php du domaine : memory_limit = 512M max_input_time = 300 max_execution_time = 300 max_input_vars = 20000

Bonjour, J'ai une demande un peu particulière de la part d'un client sur une boutique B2B. Il voudrait appliquer des promotions en cascade pour certains clients, exemple : valeur de départ 100€ Client 1 = 5% (95€) de remise Client 1, remise additionnelle = 3% de 95€ et non de 100% (donc 92,15€). Connaissez-vous un module avoir des remises en cascade comme ça ?

Bonjour, Merci pour votre réponse ! Je pense que c'est du hack vu les horaires (plus de minuit...). J'ai supprimé phpmyadmin de mon FTP.

Bonjour, Je voudrais savoir si ce genre de requête est normale ? XX.XXX.XXX.XXX - - [08/Oct/2017:00:00:00 +0200] "POST /adminXXXX/ajax.php?rand=1507413603911 HTTP/1.1" 200 489 boutiquesinternet.fr "http://boutiquesinternet.fr/adminXXXXX/index.php?controller=AdminProducts&conf=19&token=274decacd415928b796dd479a7256275" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0" "-" J'avais également installé phpmyadmin il y a longtemps XX.XX.XXX.XX - - [08/Oct/2017:00:00:07 +0200] "POST /phpmyadmin/index.php HTTP/1.1" 200 1379 boutiquesinternet.fr "http://boutiquesinternet.fr/phpmyadmin/index.php?db=dbXXXXXX&table=ps_customer_message&target=sql.php&token=0476bd7d7179818c3c5af3bc39a17479" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "-"

Ce ne sont pas des fichiers Prestashop. Sinon côté FTP, à part utiliser une connexion avec le protocole SFTP, on peut rien faire de plus pour le protéger ?

Bonjour, La version de Prestashop est 1.6.0.8. J'ai passé une analyse avec malwarebytes. Il a trouvé 7 fichiers infectés qu'il a mis en quarantaine donc il est possible que ça soit ça...

Bonjour, Nous venons d'avoir exactement le même souci sur un Prestashop multiboutiques (1.6.0.8). Quelqu'un a réussi à s'introduire dans notre FTP et a modifié le fichier AdminLoginController pour récupérer nos mots de passe BO. Il a également installé le logiciel PWM à deux endroits. Nous avons suivi les directives d'Olivier (sauf pour la mise à jour du Prestashop car nous avons effectué trop de modifs...). Je vais essayer d'améliorer la sécurité mais nous ne savons pas comment ce hacker a réussi son coup. Juste pour info, ayant accès à notre back office, il a modifié le RIB du module virement bancaire par le sien.

Euh un petit peu quand même...

Merci pour ta réponse ! C'était bien ça, il y avait trop de posts en queue. Tout est redevenu calme dans mon SAV \o/ Peux-tu m'en dire plus sur le "sniffer" ? Comment mettre en place un sniffer ? Si tu as un bon tuto sous la main

J'ai installé le recaptcha de Google sur mon formulaire mais les spams continuent d'affluer. http://vaisongroupeb.com/nous-contacter Peut être faut-il attendre que le script du hacker soit terminé ? Log du vilain hacker chinois 121.58.209.251 - - [24/May/2017:15:10:26 +0200] "POST /nous-contacter HTTP/1.1" 200 22750 vaisongroupeb.com "http://vaisongroupeb.com/nous-contacter" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36" "-"

Effectivement cette variable est utilisée dans le fichier global.js, notamment pour la fonction resizeCatimg() J'ai commenté cette fonction car je ne l'utilise pas. Le HTTPS semble être correct avec cette modif function resizeCatimg() { var div = $('.cat_desc').parent('div'); var image = new Image; $(image).load(function(){ var width = image.width; var height = image.height; var ratio = parseFloat(height / width); var calc = Math.round(ratio * parseInt(div.outerWidth(false))); div.css('min-height', calc); }); if (div.length) image.src = div.css('background-image').replace(/url\("?|"?\)$/ig, ''); }

Le problème semble résolu lorsque je supprime cette ligne dans le fichier global.tpl {addJsDef page_name=$page_name|escape:'html':'UTF-8'} Bizarre