"Accès refusé pour l'utilisateur 'test'@'ip'(en utilisant le mot de passe :OUI)" est une erreur MySQL.
Cela signifie qu'au niveau du réseau tout fonctionne , car se voir refuser l'accès en tant qu'utilisateur donné , le serveur doit avoir compris sous quel utilisateur vous tentiez de vous connecter . Ainsi, le réseau, le pare-feu, le routage, etc., doivent tous fonctionner; le serveur doit être à l'écoute, etc.
Le problème réside "simplement" dans l'authentification .
Essayez de vous connecter localement à la base de données (pour remplacer l'authentification) et inspectez la table des privilèges :
USE mysql;
SELECT User, Host, Password from user WHERE User = 'test';
et rappelez-vous que la ligne qui vous intéresse est celle mentionnant l'IP (puisque le message d'erreur spécifie l'IP , et pas le nom d'hôte - auquel cas, il pourrait s'agir d'un problème DNS ; le nom d'hôte est le nom d'hôte d'où le serveur pense que vous venez , pas le nom d'hôte d'où vous venez réellement).
La correspondance utilisateur/hôte va de plus spécifique à moins spécifique . Donc si vous aviez déjà :
user host password
test 1.2.3.4 foo
et a couru,
GRANT... TO [email protected]'%' ... PASSWORD bar
...cette subvention fonctionnerait de partout sauf 1.2.3.4, où le mot de passe resterait 'foo'.
Extrait du manuel (lien ci-dessus) :
Vous pourriez être obligé de le faire
USE mysql;
DELETE FROM user WHERE User = 'test';
GRANT ALL PRIVILEGES ON database.* TO 'test'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
pour s'assurer qu'il n'y a pas de fausses lignes dans le tableau des autorisations faisant référence à l'utilisateur "test".
(De plus, le GRANT devrait être, je pense,
GRANT ALL PRIVILEGES ON databasename.*
)
Doute de sécurité (sans rapport avec la réponse)
Le manuel ci-dessus indique :La spécificité d'une adresse IP littérale n'est pas affectée par le fait qu'elle possède un masque de réseau, donc 192.168.1.13 et 192.168.1.0/255.255.255.0 sont considérés comme également spécifiques .
Maintenant, au premier coup d'œil 127.0.0.1/0.0.0.0
semble très spécifique (et inoffensif) pour localhost . Le netmask, si je ne me trompe pas, assure qu'il est équivalent à %
, sauf qu'il est incroyablement spécifique et s'exécutera en premier . Par conséquent
test bar %
test localfoo 127.0.0.1/0.0.0.0
signifie que le mot de passe pour test
de n'importe où ce n'est pas "bar" du tout, mais c'est "localfoo".
Personne n'insérerait une telle subvention par erreur, mais il y a erreur et erreur .