Jump to content
juju74460

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

Recommended Posts

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



 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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^^

  • Like 1

Share this post


Link to post
Share on other sites

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 by juju74460 (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

merci Eolia

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

 

Share this post


Link to post
Share on other sites

le test d'afficher/enregistrer votre fiche produit !

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

Share this post


Link to post
Share on other sites

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 by juju74460 (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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^^

Share this post


Link to post
Share on other sites

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 ....

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
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 :huh2: 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :huh2: 

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.

Share this post


Link to post
Share on other sites
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à ...:unsure:

extrait-logs-0206.jpg

Edited by DoOm06 (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 ... :blink: ...

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 ...

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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 ;) ...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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%';

 

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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 by DoOm06 (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by DoOm06 (see edit history)

Share this post


Link to post
Share on other sites
Just now, Eolia said:

le fichier acces.log

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
1 hour ago, doekia said:

Donc 18 connections à la BDD

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 ...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by DoOm06 (see edit history)

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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é ...:D ...

Share this post


Link to post
Share on other sites

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

Bonne continuation

Share this post


Link to post
Share on other sites
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 :(

Share this post


Link to post
Share on other sites
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  -

Share this post


Link to post
Share on other sites
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 ?

 

Share this post


Link to post
Share on other sites
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é ...:D ...

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.

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

 

 

Share this post


Link to post
Share on other sites
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 .... 

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More