Link to database cannot be established: SQLSTATE[HY000] [1203] User 'max_user_connections' active connections

[juju74460]

Bonjour

j'ai un souci au niveau de la gestion de mes produits en backoffice, je n'arrive plus a gérer les quantités, associations, livraisons ....
Le message: Link to database cannot be established: SQLSTATE[HY000] [1203] User  already has more than 'max_user_connections' active connections
Si j'insiste en actualisant la page 6 à 7 fois, j'arrive a faire supprimer ce message.
Le prestashop est un 1.6.1.9

J'ai appelé l'hébergeur qui me dit que c'est le nombre de requête qui pose problème et non l’espace de stockage qu'il me reste.
Auriez vous une idée de comment corriger le problème?
Malgré toutes mes recherches sur le web, je n'ai a ce jour pas résolu ce souci qui dure depuis au moins 1 semaine.

Merci beaucoup a la communauté prestashop pour votre aide



 

[Eolia]

Ce sont les limites du mutu quand la boutique commence à avoir du trafic...

[juju74460]

y a t'il une solution autre que de changer d'hébergement?
pourquoi autant de requête vers la base de donnée maintenant et a tout heure?
Est il possible de faire en sorte que ce message ne puisse s'afficher, au moins pendant 1 a deux mois?

Merci Eolia

[Eolia]

Avec Prestshop (cms dynamique) chaque utilisateur présent sur votre site génère des connexions à la base de données, en plus de vous (et vos employés si vous en avez)

C'est la somme de ces connexions ouvertes qui est limitée sur un mutualisé.

Quand le magasin de 10m² ne peut plus recevoir plus de 4 clients, on agrandit ou on déménage^^

[juju74460]

merci Eolia, oui je comprends bien en effet
Au niveau du trafic, je n'en vois pas plus qu'avant, est ce possible qu'il y en ai qui campent dans la boutique?

pourquoi cela arrive uniquement avec la gestion des produits et pas ailleurs?
 

Edited August 29, 2018 by juju74460 (see edit history)

[Eolia]

cette page lance 14 appels ajax qui chacun génèrent des requêtes sql...

[juju74460]

merci Eolia

mais cela n'a pas changé depuis l'ouverture du site, pourquoi maintenant?
y a t'il quelque chose a faire?

 

[Eolia]

Mettez votre site en maintenance et refaites le test.

[juju74460]

quel test Eolia?
Une mise a jour vers la 1.6.1.20 pourrait elle corriger le problème?

Edited August 29, 2018 by juju74460 (see edit history)

[Eolia]

le test d'afficher/enregistrer votre fiche produit !

La maj Prestashop ne changera rien le fonctionnement est le même.

[juju74460]

cela marche oui en backoffice mais c'est très aléatoire, je dois actualiser 5 ou 6 fois la fiche produit afin de ne plus recevoir le message d'erreur.

la partie information de la fiche produit ne bug pas

Edited August 29, 2018 by juju74460 (see edit history)

[Eolia]

Avec le mode maintenance activé ?

[doekia]

j'aime la réponse de cet hébergeur.

"j'ai atteint mon nombre de connexion max!"

"c'est parce que vous avez trop de connexion!"

 

Là on avance !!!.

- Quel est ce nombre ?

- Pourquoi maintenant ?

- Sachant que tous les prestashop depuis 1.6 fonctionne sur le même scénario avez vous d'autre client avec Prestashop?

 

Nous ne pouvons pas régler les problème de l'hébergeur qui te limite. C'est un peu comme si tu demandais à ton loueur de voiture ... pourquoi je ne pas passer la seconde sur ma boite de vitesse et qu'il te réponde avec la 1ere vous avez atteint le maximum

[juju74460]

Eolia, en mode maintenance le problème persiste malheureusement.
L'hébergeur est 1&1 sur un serveur mutu avec le pack unlimited en plus!

est ce normal d'avoir une base de donné de 782 mo avec une boutique n'ayant que 450 articles en 4 langues?
Je me demandais si cela ne venais pas d'un hacking de ma BDD!

Doekia, merci pour ton intervention
Comment connaitre le nombre ?
C'est la première fois que je rencontre ce problème, mais a en lire les commentaires sur le web, je ne suis pas le seul dans ce cas la.
Y a t'il quelques chose a faire pour retrouver mon site viable?

Merci beaucoup

[Mediacom87]

mutu 1and1 = rame, rameur, ramer ...

Fuyez rapidement vers un autre hébergeur, même en mutualisé cela sera moins pire.

[juju74460]

ok merci mais en attendant, il n'y a rien d'autre a faire?

[Eolia]

On ne va pas réécrire Prestashop en 5 min donc voyez avec votre hébergeur ce qu'il vous propose ou déménagez^^

[juju74460]

je vais déménager effectivement, bonne déduction Eolia!

1&1, je pense avoir fais le tour.

[DoOm06]

Bonjour,

je reviens sur le sujet car je suis confronté depuis ce matin au même problème que Juju, avec un accès aléatoire à mon site (prestashop 1.7.3) et ce même message : Link to database cannot be established: SQLSTATE[HY000] [1203] User  already has more than 'max_user_connections' active connections.

Hébergé également chez 1&1 en mutualisé, je les ai appelé, car en 5 ans c'est la 1ère fois que ça arrive. Ils me disent que c'est un problème de scripting Prestashop ?? et qu'ils ne peuvent rien faire pour moi, sans plus d'infos, même pas à me proposer un serveur dédié ... Je ne comprend pas bien car je n'ai pas plus de trafic qu'auparavant , j'ai migré en novembre de la 1.5 vers 1.7 et tout fonctionnait jusque là. Si ce n'est trouver une solution au problème, pouvez-vous me dire vers quel hébergeur me tourner ? N'y a t il pas un moyen de contourner ce max user connections ? Je suis un peu dégoûté quand même de devoir tout refaire ailleurs, mais je dois agir rapidement ....

[doekia]

La bonne question à leur poser dans un 1er temps est quelle est la valeur max_user_connections qu'ils ont de configuré.

 

[Eolia]

Controlez quand même vos logs de connexions chez 1&1 pour être sûr qu'il n'y aurait pas une attaque en masse vers votre url...

[DoOm06]

6 hours ago, Eolia said:

Controlez quand même vos logs de connexions chez 1&1 pour être sûr qu'il n'y aurait pas une attaque en masse vers votre url...

Merci pour ce retour rapide Eolia.

J'ai récupéré et ouvert les logs, effectivement il y a de la requête Aujourd'hui !!! Par contre, comment je peux comprendre si il s'agit d'une attaque ou pas ? J'avoue ne pas avoir une grande expertise du sujet  

[DoOm06]

6 hours ago, doekia said:

La bonne question à leur poser dans un 1er temps est quelle est la valeur max_user_connections qu'ils ont de configuré.

 

Merci aussi pour ce retour rapide à doekia.

J'appellerais donc 1&1 pour leur demander, demain matin ...

En attendant mon site est en maintenance  ... histoire de ne pas effrayer les visiteurs avec d'intempestives erreurs 500.

[Eolia]

Il y a 9 heures, DoOm06 a dit :

Merci pour ce retour rapide Eolia.

J'ai récupéré et ouvert les logs, effectivement il y a de la requête Aujourd'hui !!! Par contre, comment je peux comprendre si il s'agit d'une attaque ou pas ? J'avoue ne pas avoir une grande expertise du sujet  

Si des requêtes sont "bizarres", avec des paramètres inconnus ou de multiples requêtes en quelques secondes depuis la même ip ou de nombreuses 404.

Faites nous un screen d'une partie de ces logs on pourra peut être vous en dire plus.

[DoOm06]

2 hours ago, Eolia said:

Si des requêtes sont "bizarres", avec des paramètres inconnus ou de multiples requêtes en quelques secondes depuis la même ip ou de nombreuses 404.

Faites nous un screen d'une partie de ces logs on pourra peut être vous en dire plus.

Bon, je ne vois pas de requêtes bizarres ou de 404, enfin je ne crois pas ( pas simple à lire ce truc) .

Le fait est que pour la journée du 6, j'ai quand même 988797 lignes et en y regardant de plus près, je vois des ip récurrentes qui envoient des requêtes dans toutes les langues et toute la sainte journée. Comment distinguer les robots et comment les bloquer (si toutefois cette solution est bonne ) ? 

J'ai approfondi la recherche et je crois que les chinois en ont après moi ...

Je joins comme demandé une impression écran quand il commence à y avoir des retours en code 500 ...

Pour ce qui est du max_user_connections, il est limité à 100, mais du coup je dois pouvoir le modifier puisque j'ai accès au php.ini. Pourtant je ne vois pas 100 connections simultanées dans les logs .... je suis un peu perdu là ...

Edited February 7, 2019 by DoOm06 (see edit history)

[doekia]

Moi je vois des attaques dans ce log

Demande à @Eolia d'intervenir, il a justement de bons outils pour bloquer ce genre de saletés

[DoOm06]

24 minutes ago, doekia said:

Moi je vois des attaques dans ce log

Demande à @Eolia d'intervenir, il a justement de bons outils pour bloquer ce genre de saletés

ok, je peux te demander quels sont les éléments qui te font dire ça ? Et quels sont les outils pour régler le problème ? j'ai vu des modules sur l'addon ... je ne sais pas si ça peut faire l'affaire ...

Je me doute que tu as raison car j'ai comparé ce fichier à un fichier de fin janvier et je passe effectivement de 19776 à 988797 requêtes !! Les quelques IP que j'ai recherché viennent de Chine ...  ...

Sinon pour le max_user, 100 c'est correct non ?

Merci pour votre aide en tout cas ... le bout du tunnel me parait se rapprocher ... doucement ...

[doekia]

Je te parle de quelqu'un avec sa compétences qui connaît et déploie plein de technique pour bloquer les pouilleux. Pas d'un module de 3 lignes vendu a prix d'or sur addons qui ne fait que mettre en place des recettes éculées que les hacker/spammer ont déjoué depuis des années.

max_user à 100 c'est bon (mais j'ai des doutes qu'un hébergeur grand public soit aussi haut). De toute manière 100 ou 1000 ne change rien en cas d'attaque - c'est juste repousser le problème de quelques minutes

 

[DoOm06]

3 minutes ago, doekia said:

Je te parle de quelqu'un avec sa compétences qui connaît et déploie plein de technique pour bloquer les pouilleux. Pas d'un module de 3 lignes vendu a prix d'or sur addons qui ne fait que mettre en place des recettes éculées que les hacker/spammer ont déjoué depuis des années.

max_user à 100 c'est bon (mais j'ai des doutes qu'un hébergeur grand public soit aussi haut). De toute manière 100 ou 1000 ne change rien en cas d'attaque - c'est juste repousser le problème de quelques minutes

 

Le max_user est bien à 100 dans mon php.ini (est-ce qu'en pratique c'est vrai ...aucune idée).

Je vais donc attendre le retour du compétent Eolia afin de voir ce qu'il peut faire pour moi  ...

[Eolia]

Bonjour

Pour en savoir un peu plus serait-il possible de naviguer sur votre site ?

ce sont tous les q= qui me semblent bizarres surtout dans vos logs, mais peut-être est-ce du à un module. Sinon, oui, il s'agit de spamBots et donc d'attaques DDos

[doekia]

max_user et max_user_connections sont des paramètres MySQL, rien n'a voir avec PHP, php.ini

Dans phpmyadmin:

show global variables like 'max%conn%';
show variables like 'max%conn%';

 

[DoOm06]

2 hours ago, Eolia said:

Bonjour

Pour en savoir un peu plus serait-il possible de naviguer sur votre site ?

ce sont tous les q= qui me semblent bizarres surtout dans vos logs, mais peut-être est-ce du à un module. Sinon, oui, il s'agit de spamBots et donc d'attaques DDos

Bonjour,

et bien sûr, avec plaisir ! https://www.lesterrassesdaragon.com

Je le remet en ligne de suite ... prévenez-moi quand c'est fait que je puisse repasser en maintenance. D'ailleurs même en maintenance j'ai toujours cet affichage dans le backoffice :

[PrestaShopException]
Link to database cannot be established: SQLSTATE[HY000] [1203] User xxx already has more than 'max_user_connections' active connections
at line 120 in file classes/db/DbPDO.php

 

[DoOm06]

1 hour ago, doekia said:

max_user et max_user_connections sont des paramètres MySQL, rien n'a voir avec PHP, php.ini

Dans phpmyadmin:

show global variables like 'max%conn%';
show variables like 'max%conn%';

 

Effectivement après vérification dans phpmyadmin (compliquée car même problème d'accès que pour le site), les valeurs affichées sont :

max_connect_errors	1000
max_connections	240
max_user_connections	18

Du coup on est loin des 100 annoncés dans le php.ini

Edited February 7, 2019 by DoOm06 (see edit history)

[doekia]

Donc 18 connections à la BDD

[Eolia]

Bon, après avoir réussi à afficher le site je vois que les q= sont rajoutés par une sorte de navigation à facettes, mais pas celle du module de base, le souci vient peut-être de là. Pas de cache ou trop de requêtes.

si vous pouviez m'envoyer vos logs d'accès en MP je pourrais peut-être vous en dire plus.

[DoOm06]

8 minutes ago, Eolia said:

Bon, après avoir réussi à afficher le site je vois que les q= sont rajoutés par une sorte de navigation à facettes, mais pas celle du module de base, le souci vient peut-être de là. Pas de cache ou trop de requêtes.

si vous pouviez m'envoyer vos logs d'accès en MP je pourrais peut-être vous en dire plus.

euh .... par Logs d'accès vous voulez dire un accès au Back Office ? ou le fichier des logs? Le fichier des logs il fait quand même plus de 26 Mo

Edited February 7, 2019 by DoOm06 (see edit history)

[Eolia]

le fichier acces.log

[DoOm06]

Just now, Eolia said:

le fichier acces.log

il fait 45 Mo zippé, ça passe en MP ça ?

 

[Eolia]

posez le fichier dans un répertoire de votre site et envoyez-moi l'url^^

[DoOm06]

1 hour ago, doekia said:

Donc 18 connections à la BDD

est-ce que je peux le modifier manuellement dans la bdd ?

[doekia]

2 hours ago, DoOm06 said:

est-ce que je peux le modifier manuellement dans la bdd ?

 

6 hours ago, doekia said:

De toute manière 100 ou 1000 ne change rien en cas d'attaque - c'est juste repousser le problème de quelques minutes

Est-ce que tu lis les réponses?

[DoOm06]

1 hour ago, doekia said:

 

Est-ce que tu lis les réponses?

Oui je lis les réponses et toi tu lis les questions ??

1 hour ago, doekia said:

est-ce que je peux le modifier manuellement dans la bdd ?

Si tu ne veux pas répondre ne le fais pas ...

[doekia]

Alors la réponse est non tu ne peux pas le changer puisque tu n'es pas administrateur de la bdd (root sql)

Et quand bien même tu le changerais ça ne donnerai au final que plus de possibilité pour l'attaque et le resultat serait exactement le même

18 connections SQL simultanées c'est déjà beaucoup pour un seul site.

[DoOm06]

Bonjour,

je reviens vers vous après avoir fait quelques recherches et appels chez 1&1.

- Du coté de 1&1, c'est formidable car quand on leur pose une question technique, ils répondent qu'ils sont hébergeur et qu'ils ne répondent pas aux problèmes de scripting. Je suis quand même tombé sur un gars plutôt avenant et bien qu'il me dise qu'il n'y a pas de restriction au niveau GeoIp, les seuls règles de blocages proposées passent par uniquement par des IP ou des plages d'IP . Toutes les règles proposés par Eolia par pays ne fonctionne pas chez moi .... Je ne comprend d'ailleurs pas pourquoi les bases du genre Allow, Deny non plus ...

- J'ai entre temps activé la Géolocalisation par IP dans le back Office de Prestashop, et j'ai décoché la Chine et la Russie. Bilan de cette opération : Les requêtes sont toujours aussi importantes mais retournent maintenant une 403 à mes amis chinois. Cela ne résout pas mon problème puisque ce sont les requêtes qui saturent ma bdd.

- J'ai essayé également sur un clone du site de poser cette règle de filtrage par plages d'IP  :

RewriteCond %{REMOTE_ADDR} ^93\.[0-9]+\.[0-9]+\.[0-9]+
RewriteRule .* - [F]

Celle-ci fonctionne et me retourne une 403 quand je veux ouvrir le site en question. Mais finalement quelque soit la solution de blocage cela ne réduit pas le nombre de requêtes et mon problème perdure, bien que moins systématique (j'arrive un peu plus à accéder à mon back-office avant d'avoir une erreur max-user).

QUESTION 1 : Est-ce je peux espérer que les chinois se lassent de tomber sur une 403 ou pas ?

J'ai trouvé ça aussi sur le net :

RewriteCond %{HTTP:VIA}                 !^$ [OR]
RewriteCond %{HTTP:FORWARDED}           !^$ [OR]
RewriteCond %{HTTP:USERAGENT_VIA}       !^$ [OR]
RewriteCond %{HTTP:X_FORWARDED_FOR}     !^$ [OR]
RewriteCond %{HTTP:PROXY_CONNECTION}    !^$ [OR]
RewriteCond %{HTTP:XPROXY_CONNECTION}   !^$ [OR]
RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR]
RewriteCond %{HTTP:HTTP_CLIENT_IP}      !^$
RewriteRule ^(.*)$ - [F]

QUESTION 2 : Est-ce utile d'ajouter ça à mon htaccess par rapport à mon problème ?

Enfin, le gars de 1&1 me dit que de passer en dédié ne m'aidera en rien ... du coup vous travaillez avec quel hébergeur ? Parce que là ... je commence à saturé ...

Edited February 8, 2019 by DoOm06 (see edit history)

[doekia]

Tous les ranges des ip chinoises sont là:

https://lite.ip2location.com/china-ip-address-ranges

Donc faire un filtrage dessus c'est remplacer la peste par le choléra car ton .htaccess mettra des heures à être parsé

[Aurelou]

Bonjour,

J'avais la même erreur qui revenait sans cesse sur ma version 1.7.4.2 en mutualisé OVH. Ca ne pouvait pas venir du nombre de visites car mon site n'est même pas encore ouvert au public.

J'ai mis à jour Prestashop vers la version 1.7.5 et j'ai modifié les paramètres de mon mutualisé OVH en éditant un fichier .ovhconfig à envoyer à la racine du site avec les éléments suivants (je ne connais pas l'équivalent chez  1&1 donc à chercher) :

app.engine=php
app.engine.version=7.0
http.firewall=none
environment=production
container.image=stable

Depuis je n'ai plus ce message d'erreur. Je ne sais pas si c'est le fait d'avoir mis à jour Prestashop ou d'avoir changé la configuration chez OVH qui a résolu mon problème.

 

 

[DoOm06]

15 minutes ago, Aurelou said:

Bonjour,

J'avais la même erreur qui revenait sans cesse sur ma version 1.7.4.2 en mutualisé OVH. Ca ne pouvait pas venir du nombre de visites car mon site n'est même pas encore ouvert au public.

J'ai mis à jour Prestashop vers la version 1.7.5 et j'ai modifié les paramètres de mon mutualisé OVH en éditant un fichier .ovhconfig à envoyer à la racine du site avec les éléments suivants (je ne connais pas l'équivalent chez  1&1 donc à chercher) :

app.engine=php
app.engine.version=7.0
http.firewall=none
environment=production
container.image=stable

Depuis je n'ai plus ce message d'erreur. Je ne sais pas si c'est le fait d'avoir mis à jour Prestashop ou d'avoir changé la configuration chez OVH qui a résolu mon problème.

 

 

Bonjour Aurelou,

et merci pour ce retour. Je vais regarder un peu plus en détails cette histoire de config mais de mon coté les logs sont là pour confirmer les requêtes massive des chinois depuis 2 jours. Face à l'absence de réelle assistance de mon hébergeur, je vais devoir en trouver un autre un peu plus à l'écoute de ses clients.

[DoOm06]

52 minutes ago, doekia said:

Tous les ranges des ip chinoises sont là:

https://lite.ip2location.com/china-ip-address-ranges

Donc faire un filtrage dessus c'est remplacer la peste par le choléra car ton .htaccess mettra des heures à être parsé

J'avais bien compris que ce n'était pas la solution idéale . Et de toute façon si je fais ça (et d'après les tests que j'ai fait), je vais retourner une 403 de la même façon que le système de Géolocalisation de Prestashop, et donc cela ne m'apportera rien de plus ... d'ou ma question : Est-ce je peux espérer que les chinois se lassent de tomber sur une 403 ou pas ?

Tu es très réactif Doekia mais tu réponds toujours à coté ... ...

[doekia]

Et bien je réponds plus... quand je vois ceux qui te répondent qu'ils font une mayonnaise et ça marche .

Bonne continuation

[DoOm06]

5 minutes ago, doekia said:

Et bien je réponds plus... quand je vois ceux qui te répondent qu'ils font une mayonnaise et ça marche .

Bonne continuation

Hahaha, je savais que ma réponse ne te plairais pas .... je plaisantais un peu ... parce qu'en vérité je suis en panique ... d'habitude j'arrive à résoudre tous mes problèmes, mais là je vois vraiment pas quoi faire ...

Vous êtes les seuls avec Eolia à répondre et, à priori, à avoir les compétences pour le faire ... ne m'abandonnes pas stp ... 

Par contre ( ... et avec tout le respect que je te dois ...blablabla... ) si tu peux répondre à mes questions, ça pourrait m'aider à avancer, parce que j'attaque le 3ème jour de merdier et j'aimerais en voir le bout 

[Aurelou]

Désolée pour ma mayonnaise 😆🤐

[doekia]

44 minutes ago, DoOm06 said:

si tu peux répondre à mes questions, ça pourrait m'aider à avancer, parce que j'attaque le 3ème jour de merdier et j'aimerais en voir le bout 

Est-il possible qu'il te vienne à l'esprit que si je ne répond pas c'est que je n'ai pas la réponse.

Je ne connais rien aux offres mutus/vps/etc de tel ou tel  -

[DoOm06]

7 minutes ago, doekia said:

Est-il possible qu'il te vienne à l'esprit que si je ne répond pas c'est que je n'ai pas la réponse.

Je ne connais rien aux offres mutus/vps/etc de tel ou tel  -

et bien je reconnais que non ...c'est pas monté au cerveau ... mais est-ce que la question : "Est-ce je peux espérer que les chinois se lassent de tomber sur une 403 ou pas ?" ou "vous travaillez avec quel hébergeur ?"  a un rapport avec l'offre d'hébergement ?

 

[Eolia]

Il y a 4 heures, DoOm06 a dit :

J'avais bien compris que ce n'était pas la solution idéale . Et de toute façon si je fais ça (et d'après les tests que j'ai fait), je vais retourner une 403 de la même façon que le système de Géolocalisation de Prestashop, et donc cela ne m'apportera rien de plus ... d'ou ma question : Est-ce je peux espérer que les chinois se lassent de tomber sur une 403 ou pas ?

Tu es très réactif Doekia mais tu réponds toujours à coté ... ...

Ben non, tu n'as rien compris car le blocage d'ip par Apache n'a rien à voir avec celui de la géoloc de Prestashop. 

Apache intervient AVANT la couche php et si l'ip est ban elle ne va pas déclencher des écritures en bdd.

[DoOm06]

15 hours ago, Eolia said:

Ben non, tu n'as rien compris car le blocage d'ip par Apache n'a rien à voir avec celui de la géoloc de Prestashop. 

Apache intervient AVANT la couche php et si l'ip est ban elle ne va pas déclencher des écritures en bdd.

Ah bah voilà ... on avance là ... j'ai appris un truc. C'est gentil de m'aider, en plus maintenant on se tutoie nous aussi, donc je sens qu'on devient plus intime. 

Effectivement j'ai fait un test pour bloquer mon propre accès (donc 403 en retour sur le front) mais je reconnais que je ne suis pas allé voir ce que cela donnait dans les logs.

Ce que je disais que j'avais compris, et c'est ce que tu m'as expliqué il me semble, c'est que d'ajouter toutes ces plages IP dans mon htaccess allait ralentir l'accès à mon site et que ce n’était pas la solution idéale. J'ai bon là ? Ou je suis vraiment très con ?

[Eolia]

Tu as bon pour le ralentissement.

le truc, c'est que sur un mutu on n'a pas accès à failtoban qui serait bien pratique dans ton cas donc tu n'a pas trop le choix que de mettre tous ces ranges d'IP dans ton htaccess en attendant.

[DoOm06]

4 hours ago, Eolia said:

Tu as bon pour le ralentissement.

le truc, c'est que sur un mutu on n'a pas accès à failtoban qui serait bien pratique dans ton cas donc tu n'a pas trop le choix que de mettre tous ces ranges d'IP dans ton htaccess en attendant.

Merci pour ce retour. 

J'ai voulu tester de mettre ça à 11h ce matin dans le htaccess pour voir ce que ça donne :

Order deny, allow
Deny from 218.68.108.0
Allow from all

Et bien ce soir j'ai toujours des requêtes dans les logs avec cette ip Tu me peux confirmer qu'elle ne devrait plus apparaître et que cette règle ne fonctionne pas du coup ?. Si j'ai bon je vais rappeler ces c...... de 1&1  pour leur remettre une couche, parce que selon le dernier interlocuteur que j'eu, ça devrait fonctionner.

[Eolia]

Que cette IP soit dans les logs Apache, c'est normal, ce qu'il faut contrôler c'est que le code reçu est bien une 403.

Dans ce cas, l'utilisateur ne rentre pas et Prestashop ne fait aucun appel à la bdd.

[doekia]

Mais au lieu de faire de la mousse sur les forums ... ce ne serait pas plus simple pour une fois de lire un minimum la documentation?

Je traduis donc pour les copieurs/colleurs sans cervelle:

Order deny, allow
Appliquer d'abord les deny puis les allow

Deny from 218.68.108.0
Interdire  cette ip

Allow from all
Mais autoriser tout le monde

Donc on autorise tout le monde

 

https://httpd.apache.org/docs/2.4/fr/mod/mod_access_compat.html

Quote

La directive Order, associée aux directives Allow et Deny, implémente un système de contrôle d'accès en trois passes. Au cours de la première passe, ce sont soit toutes les directives Allow, soit toutes les directives Deny qui sont traitées, selon la définition de la directive Order. Le reste des directives (Deny ou Allow) est traité au cours de la seconde passe. La troisième passe s'applique à toutes les requêtes qui ne sont concernées par aucune des deux premières passes.

Quote

Deny,Allow

Dans un premier temps, toutes les directives Deny sont évaluées ; Si au moins une d'entre elles correspond, la requête est rejetée, à moins qu'elle corresponde aussi à une directive Allow. Toute requête qui ne correspond à aucune directive Allow ou Deny est autorisée.

 

 

 

[DoOm06]

On 2/10/2019 at 12:39 AM, doekia said:

Mais au lieu de faire de la mousse sur les forums ... ce ne serait pas plus simple pour une fois de lire un minimum la documentation?

Je traduis donc pour les copieurs/colleurs sans cervelle:

alors je vais commencer par te dire merci pour l'information transmise, parce que je suis poli et je vais tacher de le rester.

Ensuite je vais préciser que je ne suis pas codeur mais juste administrateur du site.

Enfin, ce n'est pas parce que tu sais faire du code qu'il faut prendre le melon, et que ça t'empêche d'être correct avec les gens qui viennent demander de l'aide sur un forum qui est fait pour ça, même si il est vrai qu'il est très facile de cracher sur quelqu'un quand on est caché derrière son écran .... 

[doekia]

Ce n'est pas parce que tu t'es auto proclamé administrateur que cela te donne la connaissance.

Etre administrateur et ne pas s'interroger sur ce que l'on fait c'est juste un comportement irrationel

Tu es tout autant caché que moi derrière ton écran - et en face à face je t'aurais répondu la même chose

Tu viens demander de l'aide sur le forum prestashop à un problème qui n'a rien a voir avec ce dernier.

Si tu es au bord du gouffre et que tu fais un pas en avant, tu tombe. C'est comme cela, rien a voir avec des considération philosophique. C'est comme cela que l'univers fonction et la gravité n'a que faire de qui tu es. Ici c'est pareil. Apache a écrit une méthode pour bloquer les IP et l'a clairement documenté, y compris en français. Tu peux le voir en mode calimero que c'est trop injuste ou prendre note que chaque manipulation que tu exerce doit a préalable être vérifié pour l'exactitude du comportement que tu attends.

Je ne t'ai pas craché dessus comme tu le dit, je t'ai montré ton erreur, pointé sur la documentation et mis en lumière les paragraphes traitant spécifiquement de ton problème.

 

Maintenant, ça fait 6 mois que tu as ouvert ce topic et à chaque fois je vois des remises en question de nos réponses ou des réponses hors sujet mais, jamais tu ne précise ce que tu as fait, ce que tu as obtenu quand ce n'est pas juste pour dire "marche pô". Donc là maintenant? As-tu mis les bonnes directives? As-tu constaté que celles-ci fonctionnent? Par ailleurs, si tu lis correctement la documentation, tu verra également que tu peux préciser des blocages d'ip par CIDR

 

Un bon entendeur salut

 

 

[JeromeGD]

Bonjour à tous,

Je fais un petit "up" de ce problème, car je m'y trouve moi aussi confronté.

Je pense avoir identifié une des (la?) sources du problème, et j'en appelle aux lumières des développeurs compétents pour savoir si j'ai mis le doigt sur LE problème, une partie du problème, ou si je suis complètement à coté de la plaque.

Je refais l'historique (un peu long, je m'en excuse), mais je pense toujours à ceux, qui comme moi, font des recherches pour trouver des solutions à leurs problèmes et à qui, le détails de recherches déjà faîtes peut épargner du temps ... et des crises de nerfs!...)

Je suis sous Presta 1.7.6.3 / Php 7.2.27  / Mysql  5.7.28-log / xado-france.com hébergé chez 1and1.

Je pensais avoir fais le nécessaire en insérant ceci dans mon .htaccess :

# DÉSACTIVATION DE LA SIGNATURE DU SERVEUR
ServerSignature Off

# Empêche la mise sous frames (clickjacking)
Header always append X-Frame-Options SAMEORIGIN

# Désactivation du "MIME sniffing"
Header set X-Content-Type-Options "nosniff" 

# Blocage des attaques XSS (nb : propre à Internet Explorer 8/9)
Header set X-XSS-Protection "1; mode=block" 

# SECURISATION DES ACCES AUX FICHIERS
<Files ~ "^.*\.([Hh][Tt][Aa])">
 order allow,deny
 deny from all
 satisfy all
</Files>
<FilesMatch "\.(inc|tpl|h|ihtml|sql|ini|conf|class|bin|spd|themes|modules|exe|asa|bak|old)$">
deny from all
</FilesMatch>

# PRÉVENTION DES ATTAQUES DDOS
LimitRequestBody 10240000

Mais il semble que non.

Les pages s'affichent toutes lentement, souvent en erreur 500 ou avec des messages effrayant et bandeaux rouges... 

[PrestaShopException]

Link to database cannot be established: SQLSTATE[HY000] [1203] User XXX already has more than 'max_user_connections' active connections
at line 127 in file classes/db/DbPDO.php

Ayant parcouru plusieurs forums et sites traitant plus ou moins de sujets similaires, je me suis lancé dans mes fichiers logs, parce qu'avec un nombre d'utilisateurs max de la BDD dépassé, je me suis dit que ca devait bien se voir dans les logs.

Et là... dans les logs, j'a trouvé des requêtes, parfois massives, parfois plus espacées avec des adresses IP qui, je ne sais pourquoi me paraissait suspectes (je me dois de préciser que, sur raison d'entente commerciale entre les revendeurs étrangers et la concession française que mon boss représente, il m'a été demandé de restreindre l'accès du site uniquement aux clients Français, Belges et Monégasques et je l'ai fais avec avec GeoIP - base de donnée insérée dans .../app/Resources/geoip/). Alors je me suis connecté à un site, permettant de faire des recherches géolocalisées d'adresses IP ( Géolocalisation d'adresses IP) et je me suis rendu compte que les IP provenaient de Chine, d'Ukraine, etc., qui, comme tout le monde le sait, sont bien en France (lol jaune).

J'ai donc poursuivi mes recherches et je suis tombé sur un autre site, riche en informations et qui peut être utile a certains qui ne s'y connaissent pas encore beaucoup et qui, comme moi, cherchent à en apprendre un peu plus tous les jours :  html5.immo-scope.com et plus particulièrement sur cette page qui permet d'apprendre à analyser le contenu d'un fichier log et celui-ci qui explique comment bloquer les bots indésirables (et pour l'instant, j'en suis là).

Parce que je pense, et c'est là que j'aimerais avoir l'avis de certains pro (cf. Doekia, Eolia, ou d'autres, je suis ouvert à tous les avis), que tout le problème vient de là. Tous ces spambots qui mangent de la bande passante et créent tous ces bugs / ralentissements.

La seule chose qui m'ennuie dans cette idée, c'est que j'ai contacté, en début d'après midi (avant d'avoir trouvé toutes ces infos), des développeurs de modules de protection sur Prestashop Addons qui annoncent, dans leur module, bloquer les bots indésirables. Mais quand je leur ai exposé mon problème en leur précisant que je voulais acheter leur module mais qu'avant je souhaitais savoir leur module pourrait résoudre mon problème, (j'ai joints les erreurs, les codes, et autres informations à mon mail),  2 sur 3 m'ont répondu que leur module ne pourrait rien faire pour leur problème (le dernier tarde à me répondre mais il est aux Etats-unis, donc probablement décallé et peut-être occupé à quelque chose de plus intéressant pour lui... enfin bref! passons!).

Je me demande donc s'ils n'ont pas voulu prendre de risque en m'annonçant une résolution du problème qui aurait pu finalement persister et donc leur "causer du tors" (d'un point de vue commercial... et que par conséquent ils n'ont voulu prendre aucun risque), ou bien s'ils ont vu quelque chose que je ne vois pas et qu'ils ont bien raison, "un module pour bloquer les bot indésirables ne m'aidera pas...", ou bien, (peut-être dois-je voir avec un autre module? le patron est prêt à en acheter un si l'ont est sûr que ça résoudra notre problème).
En attendant votre aide, je continue donc mes recherches.

[JeromeGD]

Juste un petit mot pour celle-et ceux qui se trouveraient confronté au même problème.

J'ai acheté le module SecurityPro sur prestashop Addons, et quand j'ai contacté le développeur (un type super!!!) il m'a proposé de développer un nouvel outil dans son module intitulé (Anti-Flood).

Il m'a envoyé le module ce matin, et nous sommes en train de le tester sur notre site.

Ca a l'air de fonctionner super bien.

Je pense que l'expérience nous en dira plus avec le temps, mais en tout cas, POUR LE MOMENT, plus aucune erreur depuis ce matin....

 

[pegperego77]

Bonjour JeromeGD,

Te serait il possible de m'indiquer les coordonnées du devloppeur du module SecurityPro car j'ai le meme probleme que toi sur mon site.

Merci pour ton aide