masterblaster

hai cambiato template o formati immagine in Design > Impostazioni Immagine ? Puoi comunque rigenerarle tutte in Design > Impostazioni Immagine (in fondo alla pagina) scegliendo il formato di tuo interesse. Attenzione perchè se hai molte immagini il tuo server potrebbe andare in timeout, in tal caso devi lanciare la procedura più volte avendo cura di NON attivare "Cancella immagini precedenti", oppure ci sono diversi moduli (a pagamento) che rigenerano le miniature a cicli con interfaccia grafica.

oui, nous ne savons pas ce qui se passe dans la communication entre les deux serveurs, probablement quelque chose n'a pas pu faire face au pic de trafic dû au black friday ?

Ho avuto lo stesso problema per tutto lo scorso fine settimana, sembra che si ripeta tuttora ma con minore frequenza. (Potete controllare i vari timeout nel file di log /var/logs/ps_checkout-xxxx per vedere quanto siete stati colpiti dal problema) La cosa negativa è che a volte i clienti hanno segnalato la pre-autorizzazione del pagamento sulla loro carta di credito, ma nessun ordine effettivo e nessun pagamento risulta trasferito al commerciante. Controllando il codice del modulo, il problema sembra essere un timeout nella comunicazione verso https://api-live-checkout.psessentials.net/ , non c'è risposta entro il timeout di 10 secondi hard-codato nel modulo. Credo che questo dominio possa essere legato ai servizi di Prestashop - tuttavia, il servizio clienti PsCheckout di Addons indica che ci sono problemi lato Paypal. Aprendo un ticket con Paypal, ci è stato mostrato questo link https://www.paypal-status.com/product/production dove non viene indicato alcun problema ai loro servizi. Al momento abbiamo cambiato modulo in attesa che venga chiarita la situazione...

J'ai eu le même problème tout le week-end dernier, il semble se reproduire maintenant mais avec moins de fréquence. Vous pouvez consulter les différents fichiers journaux /var/logs/ps_checkout-xxxx pour voir dans quelle mesure vous êtes/avez été impacté par le problème. Le problème est que parfois les clients avaient la pré-autorisation du paiement sur leur carte de crédit, mais pas de commande réelle ni de paiement transféré au marchand. En vérifiant dans le code du module, le problème semble être un timeout dans la communication vers https://api-live-checkout.psessentials.net/ , Il n'y a pas de réponse dans le délai de 10 secondes codé en dur dans le module. Je suppose que ce domaine peut être lié aux services Prestashop - cependant, le service client Addons indique que c'est la faute de Paypal. En ouvrant un ticket avec Paypal, on nous a montré ce lien https://www.paypal-status.com/product/production où aucun problème n'est indiqué. Pour faire court, nous sommes obligés de changer de méthode de paiement au moins jusqu'à ce que la situation soit clarifiée 🤔

Hai letto male... Il secondo sottodomino deve essere configurato in Apache e deve puntare alla Document Root di Prestashop (la stessa ovviamente dello shop 1) in questo modo sia il webserver che Prestashop possono "servire" correttamente le richieste in ingresso.

Hello, well I see no other ways other than inspecting logs, given the situation considering hiring a specialist if you can't handle it.

Già, se scopri qualcosa non esitare a condividere, potrebbe essere utile ad altri nella tua situazione.

E' molto probabile ti abbiano bucato il sito , controlla questo post :

It seems to me that the main intent of this kind of hack is to steal credit cards. However, core files are also modified to send logins to remote servers so if you care about your shop perform a dedicated analysis.

List of public disclosed PS vulnerabilites is available here , as long as there isn't any new exploit in the wild, I would rather think of an outdated module as an attack vector. Regarding attack itself, this is known to send plaintext credentials to remote server + add fake credit card forms during checkout. Anyway, since attackers got your webspace, the only way to be sure to clean up the threat is to restore a clean backup and remove the attack vector.

You are checking the wrong folder ( /classes/controller ) and not controllers/admin/

It's hard to tell, you should check the access logs carefully to understand the attack vector. There may have been a vulnerable/outdated module.

I had to deal with a similar report lately - Check : classes/db/Db.php controllers/admin/AdminLoginController.php before the restoration and see if there are any lines added in the files that send data via php Curl to a remote server. In which case yes you have been attacked by some kind of "MageCart" variant.

I had to deal with a similar report lately - Check : classes/db/Db.php controllers/admin/AdminLoginController.php before the restoration and see if there are any lines added in the files that send data via php Curl to a remote server. In which case yes you have been attacked by some kind of "MageCart" variant.

Hi @Estian , did you managed to fix it in some way ? I'm struggling with the same problem... SymfonyContainer::getInstance(); is returning null in StockManager class when called by PS webservice to update order status, preventing stock movement from being registered. Looks like a PS bug, but I can't figure out how to properly boot the container. Tried already with boostrapping the Kernel or loading the container from context using the adapter but always getting Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "prestash op.core.api.stock_movement.repository".