Jump to content

[SECURITE] SPAM Compte Client : solution [1.3 -> 1.7]


Recommended Posts

Merci doekia

Implémenté sur un Prestashop v1.4.8.2 par surcharge de classe (override)

/override/classes/Customer.php

<?php
class Customer extends CustomerCore
{
	protected	$fieldsValidate = array('secure_key' => 'isMd5', 'lastname' => 'isCustomerName', 'firstname' => 'isCustomerName', 'email' => 'isEmail', 'passwd' => 'isPasswd',
		 'id_gender' => 'isUnsignedId', 'birthday' => 'isBirthDate', 'newsletter' => 'isBool', 'optin' => 'isBool', 'active' => 'isBool', 'note' => 'isCleanHtml', 'is_guest' => 'isBool');
}
?>

 

/override/classes/Validate.php

<?php
class Validate extends ValidateCore
{
    public static function isCustomerName($name)
    {
            if (preg_match('/www|http/ui',$name))
        {
                return false;
        }
            return preg_match('/^[^0-9!\[\]<>,;?=+()@#"°{}_$%:\/\\\*\^]*$/u', $name);
    }
}
?>

 

Edited by cmak (see edit history)
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

@Jean André

Citation

J'ai raté quelque chose? 

 

Oui, dans votre cas: 

A partir de la version 1.5, comme toujours en cas d'erreur 500 et pour en savoir plus, il faut modifier cette ligne au début du fichier config/defines.inc.php sur votre ftp :

define('_PS_MODE_DEV_', false);

en remplaçant false par true, ce qui donne:

define('_PS_MODE_DEV_', true);

Et donnez-nous l'erreur après avoir enregistré le fichier et rafraîchi la page

Edited by Eolia (see edit history)
  • Thanks 1
Link to comment
Share on other sites

4 hours ago, Eolia said:

@Jean André

 

Oui, dans votre cas: 

A partir de la version 1.5, comme toujours en cas d'erreur 500 et pour en savoir plus, il faut modifier cette ligne au début du fichier config/defines.inc.php sur votre ftp :

define('_PS_MODE_DEV_', false);

en remplaçant false par true, ce qui donne:

define('_PS_MODE_DEV_', true);

Et donnez-nous l'erreur après avoir enregistré le fichier et rafraîchi la page

Merci pour l'astuce du define.inc cela ma permis de trouver le BOM que j'avais raté. dans mon cas en effet c'était les BOM j'en avais a 2 endroits j'ai nettoyé et j'ai testé sur la 1ere boutique ça a fonctionné du coup j'ai recopié les 2 petits bouts de codes pour la seconde boutique.

Je les ai modifié y a quelques minutes donc je vais voir si ça fonctionne pour contrer notre ami commun

par contre petit point de détail en testant si ça fonctionnait j'ai noté que:

effectivement www.ndd.fr est bien bloqué en nom et en prénom

par contre si le petit emmerdeur s'amuse à faire: 

ndd.fr dans nom ou prénom ça passe comme avant. si d'aventure ça venait à l'esprit d'un emmerdeur je sais pas si cela a été mentionné dans le sujet. 

Link to comment
Share on other sites

il y a 49 minutes, okom3pom a dit :

C'est moi ou le PR empêchera tous les clients avec un . de mettre à jour leur profil ?

Ce n'est pas terrible comme solution ... ou je me trompe ?

. suivi d'un ou plusieurs espace ok cutt.us refusé

Par contre comme mentionné sur github avoir changé la fonction isName pose des problème avec les adresses utilisé par certains modules pickup

  • Like 1
Link to comment
Share on other sites

Bonjour,


Tout d'abord merci d'avoir exposé la solution, je suis comme les autres membres touché par cette vague de spam sur prestashop et cela m'empêche de me connecter à mon ftp via filezila. Je passe du coup direct par le ftp accessible depuis ovh pour effectuer les modifications.

J'ai effectué les modifications gentiment proposées par Doekia, lorsque j'essaye de supprimer un client via mon interface prestashop j'obtiens le message suivant :
"
Property Customer->lastname is not valid "

J'ai sans doute fait quelque chose de travers, je précise que je suis relativement une bille en php :) !
Merci d'avance pour vos conseils !

Link to comment
Share on other sites

il y a 2 minutes, Djoul84 a dit :

Bonjour,


Tout d'abord merci d'avoir exposé la solution, je suis comme les autres membres touché par cette vague de spam sur prestashop et cela m'empêche de me connecter à mon ftp via filezila. Je passe du coup direct par le ftp accessible depuis ovh pour effectuer les modifications.

J'ai effectué les modifications gentiment proposées par Doekia, lorsque j'essaye de supprimer un client via mon interface prestashop j'obtiens le message suivant :
"
Property Customer->lastname is not valid "

J'ai sans doute fait quelque chose de travers, je précise que je suis relativement une bille en php :) !
Merci d'avance pour vos conseils !

Bonjour,

J'espère ne pas me tromper, mais il aurait fallu supprimer ces clients avant de faire les modifs. Du coup, deux options :

- soit modifier les noms des clients pour ensuite pouvoir les supprimer
- soit revenir sur les modifs, supprimer les clients, puis remettre les modifs

Et je crois même qu'il y a une troisième option, avec le script mis à dispo, mais à confirmer par un expert.

  • Thanks 1
Link to comment
Share on other sites

20 minutes ago, Djoul84 said:

je suis comme les autres membres touché par cette vague de spam sur prestashop et cela m'empêche de me connecter à mon ftp via filezila.

(---)
J'ai sans doute fait quelque chose de travers, je précise que je suis relativement une bille en php :) !
 

- Je pense qu'il n'y a aucun rapport entre ces faux comptes et le ftp.

- Pas besoin d'être une bête en php pour appliquer le patch mais sans connaissance, je recommande de passer par un développeur web sinon vous prenez le risque de faire n'importe quoi. Je vous donne une image : je n'y connais rien en mécanique auto. Je démonte quand même mon moteur en ne sachant pas vraiment ce que je fais et après viens sur le forum expliquer que ma voiture ne roule plus et que je n'y connais rien. Ça vous parait absurde ? C'est la même chose pour le php et autres langages.

Edited by Cloud Nine (see edit history)
Link to comment
Share on other sites

Il y a forcément un rapport puisque dès l'application du patch de Doekia cela a été résolu, sachant que cela fait plusieurs jours que le souci était présent. Le robot spam les inscriptions sur le site et surcharge. Avec ce patch il n'y a plus de surcharge donc le ftp redevient accessible via filezila.

Pour ce qui est de mes compétences, j'ai tout de même les bases pour ajouter un code correctement ;) mais je ne saurai faire un site en php à moins de me baser sur de l'existant. Bonne journée

Link to comment
Share on other sites

il y a 9 minutes, Cloud Nine a dit :

- Je pense qu'il n'y a aucun rapport entre ces faux comptes et le ftp.

 

il y a 3 minutes, Djoul84 a dit :

Il y a forcément un rapport puisque dès l'application du patch de Doekia cela a été résolu,

Je confirme aucun rapport entre les 2, sauf a avoir un serveur vraiment mou du sifflet qui pédalait à gérer sa mail queue, d'ailleurs si tu n'arrivais pas a faire de FTP, comment donc as-tu pu appliquer le patch?

 

Link to comment
Share on other sites

On 4/25/2019 at 3:44 PM, Jpc_des_dombes said:

Petit retour d'expérience . J'ai patché le module Sendinblue comme expliqué par @Eolia et depuis maintenant 9h, je n'ai plus de spam dans ma liste de contact Sendinblue.

Grand grand merci @Eolia 👍

Je suis sous prestashop 1.6.1.18 et mon module SendinBlue v2.7.8

Bonjour Jpc

Même soucis que vous dans Sendinblue, ça continue à spammer mon dossier "contacts prrestashop" et pourtant je n'ai plus de créations de nouveaux compte "spams" dans Prestashop

Pourriez vous SVP me donner le nom du fichier à modifier dans le module sendinblue ?

D'avance merci

Link to comment
Share on other sites

On 4/25/2019 at 12:27 PM, Eolia said:

Je vous conseille aussi de patcher le module sendinblue hein^^

Merci beaucoup à tous les deux et à Deokia. J'espère voir la fin de ce cauchemar avec ce dernier patch sur sendinblue :) 

Bon week-end !

Je remets le code à modifier donné par Eolia :

patch du module sendinblue.jpg

Edited by ikaris (see edit history)
Link to comment
Share on other sites

Sinon,

J'ai le "patch + recaptcha" et le robot spam encore les créations de compte, puisque je retrouve ses spams dans sendinblue. (et plus de nouveaux comptes clients dans l'admin)

Que faire de plus ? Il va me spammer mon site à vie ce con ?

C'est quand même une sacrée attaque...car je pense que nous sommes des milliers à avoir été touchés en même temps dimanche dernier. 

D'ailleurs, comment ils trouvent les sites presatshop ? J'ai un second site avec une url en .ovh et là par miracle il a pas été touché comme le .fr. 

Bon WE

 

Edited by ikaris (see edit history)
Link to comment
Share on other sites

Je me suis mal exprimé, je n'ai plus non plus de création de faux comptes dans prestashop :)

Je parlais des créations de comptes mails qui continuaient dans sendinblue (avant que je le patch le module sendinblue sur vos instructions), et  c'est ce qui me faisait dire que le robot continuait à s'acharner sur mon site "vacciné" contre lui...

Mais on peux sans doute rien faire, tant qu'il me spam une fois par heure, ça va encore...

Edited by ikaris (see edit history)
Link to comment
Share on other sites

Bonjour Eolia et merci beaucoup d'avoir jeté un oeil sur mon fichier sendinblue. 

J'avais bien une erreur de syntaxe.... A priori c'est ok, ton morceau de code fonctionne bien depuis cette nuit :)

En fait JPC m'avait envoyé son propre fichier sendinblue.php vers 23 h hier soir (sans faute de syntaxe, voir ligne 283) que j'avais mis sur le FTP avant de me coucher cette nuit à 1 h du mat :) 

Et ce matin pas de nouveau spam dans sendinblue, un grand bravo pour avoir trouvé le problème chez eux et un grand merci pour autant d'implication.

Je mets le bon fichier sendinblue ci-dessous (j'ai supprimé celui du post au-dessus).

Bon week-end et merci

sendinblue.php

Edited by ikaris (see edit history)
Link to comment
Share on other sites

Bonjour

J'ai applique les modification de Doekia... pas d'erreur et ce matin encore des isncriptions pourries...
J'ai  captcha au formulaire de création de compte et j'ai interdit l’accès au serveur de cette adresse IP via Htacces

je seche... que faire ??? si qq peux m'aider je ne vois plus comment eradiquer cela...
merci

Link to comment
Share on other sites

il y a 1 minute, val a dit :

Bonjour

J'ai applique les modification de Doekia... pas d'erreur et ce matin encore des isncriptions pourries...
J'ai  captcha au formulaire de création de compte et j'ai interdit l’accès au serveur de cette adresse IP via Htacces

je seche... que faire ??? si qq peux m'aider je ne vois plus comment eradiquer cela...
merci

Bonjour,

Tu as supprimé class_index.php ?

Link to comment
Share on other sites

Si c'est le module eicaptcha, autant ne rien mettre il ne bloque aucun robot^^

Bloquer les adresses IP ne sert à rien, celles-ci changent constamment.

Si vous avez utilisé le système d'override:

- Il faut effectivement supprimer le fichier /cache/class_index.php 

- Il faut également contrôler qu'elles sont activées dans Paramètres avancés -> Performances

Link to comment
Share on other sites

il y a 9 minutes, val a dit :

oui cutt.us
je n'ai pas utiliser un systeme d'overide mais j'ai modifier le fichier les deux fichiers php directement...

que faut il verifier dans performance ?

Post ici ou sur pastebin tes 2 fichiers

Link to comment
Share on other sites

Non quand l'encéphalogramme est plat, plus d'idée.

PS: Je réponds tout de suite a @ttoine qui va venir me vendre ça morale du CoC en me disant que je ne dois pas faire de cynisme. Commençons pas punir, banir les usages toxiques de phrases se terminant par triple point d'interrogation et dénonçons à l'inquisition les post avec les phrases "merci de votre aide <point d'exclamation>". Nous ne sommes les esclaves de personne. Nous ne somme pas payé. Nous n'avons à obéir à personne. Encore moins: "schnell", j'attends, merci de vous manier les fesses! ! ! !

Edited by doekia (see edit history)
  • Haha 1
Link to comment
Share on other sites

il y a 5 minutes, val a dit :

            'lastname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32),
            'firstname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32),

ça ne risque pas de marcher

Edited by doekia (see edit history)
Link to comment
Share on other sites

Jusqu'à présent, je luttais après-coup contre ces inscriptions.

C'est-à-dire qu'une fois l'inscription faite, je récupérais son adresse IP, soit dans la base de données dans la table ps_customers > ip_registration_newsletter, soit dans la fiche du client si elle apparaît (elle n'apparaît pas toujours)
et je la rajoutais dans le .htacces :

RewriteEngine on

RewriteCond %{REMOTE_ADDR} ^85\.10\.56\.3 [OR]
RewriteCond %{REMOTE_ADDR} ^37\.235\.49\.244 [OR]
RewriteCond %{REMOTE_ADDR} ^151\.236\.24\.142
RewriteRule .* /1ndex.php [R=500,L]

le R=500 sert à afficher l'erreur correspondante si l'une des adresses ci-dessus tente de se connecter
 

puis dans la base de données, j'ai bricolé une commande pour les supprimer tous, proprement, complètement.
 

DELETE FROM ps_address WHERE id_customer > 80;DELETE FROM ps_cart WHERE id_customer > 80;DELETE FROM ps_cart_rule WHERE id_customer > 80;DELETE FROM ps_customer WHERE id_customer > 80;DELETE FROM ps_customer_group WHERE id_customer > 80;DELETE FROM ps_customer_thread WHERE id_customer > 80;DELETE FROM ps_guest WHERE id_customer > 80;DELETE FROM ps_message WHERE id_customer > 80;DELETE FROM ps_mr_selected WHERE id_customer > 80;DELETE FROM ps_orders WHERE id_customer > 80;DELETE FROM ps_specific_price WHERE id_customer > 80;DELETE FROM ps_wishlist WHERE id_customer > 80;ALTER TABLE ps_customer auto_increment = 81;

 Les '80' et '81' sont évidemment à remplacer par vos valeurs.

 

 

Link to comment
Share on other sites

il y a une heure, mikae a dit :

Jusqu'à présent, je luttais après-coup contre ces inscriptions.

C'est-à-dire qu'une fois l'inscription faite, je récupérais son adresse IP, soit dans la base de données dans la table ps_customers > ip_registration_newsletter, soit dans la fiche du client si elle apparaît (elle n'apparaît pas toujours)
et je la rajoutais dans le .htacces :


RewriteEngine on

RewriteCond %{REMOTE_ADDR} ^85\.10\.56\.3 [OR]
RewriteCond %{REMOTE_ADDR} ^37\.235\.49\.244 [OR]
RewriteCond %{REMOTE_ADDR} ^151\.236\.24\.142
RewriteRule .* /1ndex.php [R=500,L]

le R=500 sert à afficher l'erreur correspondante si l'une des adresses ci-dessus tente de se connecter
 

puis dans la base de données, j'ai bricolé une commande pour les supprimer tous, proprement, complètement.
 


DELETE FROM ps_address WHERE id_customer > 80;DELETE FROM ps_cart WHERE id_customer > 80;DELETE FROM ps_cart_rule WHERE id_customer > 80;DELETE FROM ps_customer WHERE id_customer > 80;DELETE FROM ps_customer_group WHERE id_customer > 80;DELETE FROM ps_customer_thread WHERE id_customer > 80;DELETE FROM ps_guest WHERE id_customer > 80;DELETE FROM ps_message WHERE id_customer > 80;DELETE FROM ps_mr_selected WHERE id_customer > 80;DELETE FROM ps_orders WHERE id_customer > 80;DELETE FROM ps_specific_price WHERE id_customer > 80;DELETE FROM ps_wishlist WHERE id_customer > 80;ALTER TABLE ps_customer auto_increment = 81;

 Les '80' et '81' sont évidemment à remplacer par vos valeurs.

Sans vouloir te vexer tu as inventé la pire solution de l'univers.

Non seulement tu vas vite te retrouver avec un .htaccess gigantesque (n'oublions pas que celui-ci est relu, re-analysé pour chaque appel - ce qui dégrade fortement les performances), mais en plus dans ton scénario si un vrai client s'inscrit, tu vas soit le perdre soit devoir faire des bouts de requêtes pénible.

 

IMPORTANT: régler un problème d'attaque par filtrage IP est TOUJOURS la plus mauvaise solution possible (surtout en .htaccess), et ce quelque soit le scénario de l'attaque

Link to comment
Share on other sites

Bonjour,

Pour les clients de Sendinblue qui utilisent le service SMTP, vérifiez qu'ils ne vous l'on pas désactivé. 

Ils m'ont dit l'avoir fait pour des clients qui ont été victimes de Spams via prestashop :

"Nous avons constaté que quelques sites Prestashop ont été attaqués par de fausses inscriptions, ce qui a généré des mauvais résultats entraînant le blocage de plusieurs comptes, ce qui est le cas du vôtre, comme vous pouvez constaté à l'aide de l'image du lien ci-dessous:"

Bonne journée

Edited by Jpc_des_dombes (see edit history)
Link to comment
Share on other sites

 

20 hours ago, mikae said:

C'est-à-dire qu'une fois l'inscription faite, je récupérais son adresse IP, soit dans la base de données dans la table ps_customers > ip_registration_newsletter, soit dans la fiche du client si elle apparaît (elle n'apparaît pas toujours)
et je la rajoutais dans le .htacces :


RewriteEngine on

RewriteCond %{REMOTE_ADDR} ^85\.10\.56\.3 [OR]
RewriteCond %{REMOTE_ADDR} ^37\.235\.49\.244 [OR]
RewriteCond %{REMOTE_ADDR} ^151\.236\.24\.142
RewriteRule .* /1ndex.php [R=500,L]

 

 

pour apache 2.4. vous pouvez utiliser cette règle:

<RequireAll>
Require all granted
Require not ip 85.10.56.3
Require not ip 37.235.49.244
Require not ip 151.236.24.142
</RequireAll>

Dans ce cas, l'adresse IP nommée recevra automatiquement une response http 403.

Link to comment
Share on other sites

il y a 6 minutes, selectshop.at a dit :

 

pour apache 2.4. vous pouvez utiliser cette règle:


<RequireAll>
Require all granted
Require not ip 85.10.56.3
Require not ip 37.235.49.244
Require not ip 151.236.24.142
</RequireAll>

Dans ce cas, l'adresse IP nommée recevra automatiquement une response http 403.

 

A part faire du trolling inutile sur ce topic? Quel interrêt à cela?

c'est déjà assez compliqué pour les visiteurs de suivre ce topic, si c'est pour partir dans tout les sens à leur donner des conseils boiteux, on ne va pas s'en sortir

Merci de respecter le but de ce topic.

  • Like 2
Link to comment
Share on other sites

Bonjour JPC

Encore une nouvelle galère potentielle :(

Merci pour ton retour. En effet, il est important que ceux qui utilisent le module sendinblue se préoccupent dare-dare d'aller voir ce qui se passe sur leur compte de mailing, car le robot continue de vous remplir vos listes de contacts chez sendinblue si vous n'avez pas fait la modif donnée par Eolia sur le module sendinblue.

Voilà 10 jours que l'attaque a commencé (ça fait potentiellement des centaines de spams dans vos listes de newsletters) et sendinblue n'a toujours pas fait de mise à jour dans leur module prestashop. Il sont bien au courant du problème mais le renvoie sur Prestashop. Voilà la réponse qu'ils m'ont fait :

Bonjour XXX

Merci pour votre retour. Pour information, Prestashop est victime d'une attaque de robots et est en train de corriger cette faille.
Cordialement.

XXX

Edited by ikaris (see edit history)
Link to comment
Share on other sites

il y a 6 minutes, ikaris a dit :

Bonjour JPC

Encore une nouvelle galère potentielle :(

Merci pour ton retour. En effet, il est important que ceux qui utilisent le module sendinblue se préoccupent dare-dare d'aller voir ce qui se passe sur leur compte de mailing, car le robot continue de vous remplir vos listes de contacts chez sendinblue si vous n'avez pas fait la modif donnée par Eolia sur le module sendinblue.

Voilà 10 jours que l'attaque a commencé (ça fait potentiellement des centaines de spams dans vos listes de newsletters) et sendinblue n'a toujours pas fait de mise à jour dans leur module prestashop. Il sont bien au courant du problème mais le renvoie sur Prestashop. Voilà la réponse qu'ils m'ont fait :

Bonjour XXX

Merci pour votre retour. Pour information, Prestashop est victime d'une attaque de robots et est en train de corriger cette faille.
Cordialement.

XXX

C'est en effet "amusant" et mesquin car leur module intervient même lorsque la faille est fermée. En effet le module enregistre le contenu dès le constructeur du module sans contrôle.

Link to comment
Share on other sites

Encore une petite info sur Sendinblue. Chez moi, le test d'envoi de message (SMTP) depuis le module (version v2.7.8) ne fonctionne pas. Message d'erreur SMTP non-activé.

En revanche les mails partent bien de prestashop et le test depuis  "Paramètres avancés /Emails" fonctionne

Bonne soirée

Link to comment
Share on other sites

Prestashop 1.4.10.0 --> Grand merci à doekia.

(juste un petit pb de copier-coller du code, PS: ne pas oublier d'encoder en ANSI pour trouver les caractères fantômes...)

j'imagine qu'il faudra une extension pour gérer le spam sur prénom dès qu'ils auront compris.

Link to comment
Share on other sites

Bonjour Tout le monde, J'ai essayé de faire toutes les procédures indiquées, mais je rencontre un seul soucis.

Le champs nom et prénom sont invalides (nico / test)

J'ai utilisé les codes du 1er post, supprimer le cache_index, les comptes conflictuels ont été retiré, utilisé également le script 122, mais cette erreur reviens sans arret.

Je me demandais si c'était les 1er champs du formulaire (création du compte), ou celui de l'adresse.

Si vous avez une idée de ce que j'ai pu oublié?

Merci

Presta 1.6.1.14

Edited by lescrocs (see edit history)
Link to comment
Share on other sites

Le patch a justement pour but d'interdire les / dans les noms. Il est donc normal que ton nom nico / test soit rejeté.

Si j'ai mal compris ton scénario, alors PM moi ton FTP que je vienne regarder ton problème

Link to comment
Share on other sites

6 minutes ago, doekia said:

Le patch a justement pour but d'interdire les / dans les noms. Il est donc normal que ton nom nico / test soit rejeté.

Si j'ai mal compris ton scénario, alors PM moi ton FTP que je vienne regarder ton problème

enfaite Nico est le prénom et test le nom lol

Je fais vite fait le ménage chez moi (car c'est férié lol) et je vois pour les acces au ftp.

Merci

Edited by lescrocs (see edit history)
Link to comment
Share on other sites

1 hour ago, doekia said:

Le patch a justement pour but d'interdire les / dans les noms. Il est donc normal que ton nom nico / test soit rejeté.

Si j'ai mal compris ton scénario, alors PM moi ton FTP que je vienne regarder ton problème

Salut l'ami Merci encore a toi pour ce partage, doekia je joins ton patch le mettre dans le dossier Admin c'est bien ca ?

 

patch122.php

Edited by TCHOUPI (see edit history)
Link to comment
Share on other sites

Bonjour à tous...

j'ai un nouveau pb... j'ai applique les correctifs de validate et customer plus d'inscription de sites vaseux..

mais lorsque l'on veut modifier son identite dans son compte j'ai une erreur 500 et en mode debug ca donne ca...(voir image jointe)

une idee forcement :)

 

IMG_0852.jpg

Link to comment
Share on other sites

vous avez modifié les fichiers customer et validate ou utilisé les overrides ?

Car ca se trouve vous avez déjà une override sur validate ou comme le dit @doekia, les overrides ne sont pas actives.

Link to comment
Share on other sites

Bah, je ne vous avais pas dit de faire un copier/coller sur le forum non plus. Juste glisser les fichiers ici.

L'override de customer ne concerne que la déconnexion.

Le fichier Validate.php semble correct.

 

Pas de cache serveur Memcache ou autre ? Car il semblerait que cette classe n'est pas lue, enfin pas cette dernière version...

Et je préfèrerai le fichier ici car avec les c/c l'encodage n'est pas le bon.

Link to comment
Share on other sites

15 hours ago, Eolia said:

Bah, je ne vous avais pas dit de faire un copier/coller sur le forum non plus. Juste glisser les fichiers ici.

L'override de customer ne concerne que la déconnexion.

Le fichier Validate.php semble correct.

 

Pas de cache serveur Memcache ou autre ? Car il semblerait que cette classe n'est pas lue, enfin pas cette dernière version...

Et je préfèrerai le fichier ici car avec les c/c l'encodage n'est pas le bon.

 

15 hours ago, Eolia said:

Bah, je ne vous avais pas dit de faire un copier/coller sur le forum non plus. Juste glisser les fichiers ici.

L'override de customer ne concerne que la déconnexion.

Le fichier Validate.php semble correct.

 

Pas de cache serveur Memcache ou autre ? Car il semblerait que cette classe n'est pas lue, enfin pas cette dernière version...

Et je préfèrerai le fichier ici car avec les c/c l'encodage n'est pas le bon.

 

Customer.php

Validate.php

Customer.php

Link to comment
Share on other sites

il y a 20 minutes, val a dit :

voila je viens de poster les 3 fichiers

je viens de regarder le choix dans performance est Memcached par PHP::Memcache

 

Franchement pourquoi continuer à perdre du temps là dessus? Donne en MP ton accès FTP et le problème sera réglé ...

Link to comment
Share on other sites

Bonjour. Eh bien Eolia et Doekia, vous êtes bien sympa et patients car c'était indiqué dès le début de ce post d'activer l'override pour ceux qui passaient par cette méthode...

Merci à tous ceux qui ont aidé à boucher cette faille potentiellement grave pour nos activités et à vous deux en particulier ;)

Edited by ikaris (see edit history)
Link to comment
Share on other sites

Question sans doute très bête, mais pourquoi ne pas ajouter ceci  simplement a la déclaration de la variable "isname" dans validate.php, au lieu de créer un "iscustomername" dans customer.php ? :

public static function isName($name)
    {
        if (preg_match(Tools::cleanNonUnicodeSupport('/www|http/ui'),$name)) {
            return false;
        }
        return preg_match(Tools::cleanNonUnicodeSupport('/^[^0-9!<>,;?=+()@#"°{}_$%:]*$/u'), stripslashes($name));
    }

 

Y a t'il une déclaration qui poserait problème ?

Edited by Jean Francois G (see edit history)
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...