连接的错误无非几点:身份验证失败、没有权限访问、用户访问被拒绝、用户不存在(目前遇到)
注:使用 ctrl + f 粘贴你的错误提示关键字,可快速定位该连接错误。
关于身份验证失败:
Client does not support authentication protocol requested by server; consider upgrading mysql client;
上方的错误提示码翻译成中文的大概意思是说:客户端不支持服务器请求的认证协议,考虑升级MySQL客户端。
那么,不妨换个思路想,有没有可能是服务器的协议与 MySQL 客户端的协议不同呢?
锁定关键字:认证协议。
继续思考下去,身份认证
是连接的首要步骤,那么即可能是身份认证
环节中出错了。
关键是,认证过程中发生了什么?我们编写的软件、服务器通过密码,或者是SSH之类的密令进行连接:是不是连接过程中密码错误或编码问题?
检查了配置是否启用 utf8 连接,结果是启用;
之后转到终端进行手动连接,我发现我可以正常进入,那么这个问题 Pass 掉
其实我对数据库的认识仅限于CURD,以及优化查询速度,但是对于深层原理只知悉一点,而我觉得问题应该出在 MySQL 里
这意味着我得进入 MySQL 的用户表看看密码长什么样子:
然后我发现了 插件 字段下的关于密码的字符串
(我已经修改了后面两个,起初都是 caching_sha2_password )
其实我也不知道它们的意思,便只好去搜索引擎(bing)中查看对应的插件作用。
最后得知:MySQL 为了更安全的连接,将‘身份验证插件’升级了,且默认为 caching_sha2_password ,而大多数的服务器、软件中并没有内置相关协议。
也就导致了上方所述的错误代码了。
所以,为了兼容旧的服务器、软件的连接方式,我们可以修改关于此用户的身份验证协议。
比方:你想要让 root 用户在服务器中登录(通常不推荐这样做,只是比喻)
那么对应的修改方案如下:
# 修改身份验证插件为旧的加密方式,否则部分后台将无法连接
ALTER USER \'root\'@\'localhost\' IDENTIFIED WITH mysql_native_password BY \'password\';
# 刷新
flush privileges;
(题外话)
当然,建议创建一个用户,只具备查询权限,这意味着即使被服务器被暴力破解(我还有其它方法应对这个攻击方式),最坏的结果就是当前登录用户所连接的数据库数据泄露,不过重要字段都被加密,如手机号使用可逆加密,密码采用不可逆的加密方式;这样一来,短时间内应该可以反应过来。
# 创建新的用户 并指定使用旧的‘身份验证’
CREATE USER `test`@`localhost` IDENTIFIED WITH mysql_native_password BY \'test_password\';
关于用户访问被拒绝错误
Access denied for user \'xxx\'@\'localhost\' (using password: YES)
上方的错误翻译成中文,大概意思是说:用户XXX访问被拒绝
错误原因是:访问
被拒绝,所以我们从访问的途径中来思考:
我分步了测试,大致如下:
测试一:会不会是字符编码问题而导致的“密码错误”,从而导致访问被拒绝
由于在相同的时间段中,我创建了两个用户,所以我使用的测试一方案是:
使用两个不同的连接实例去连接数据库
结果是:第一个用户登录成功,第二个用户登录失败(即报错的那个)
不是字符编码的错,我还是挺相信自己写的服务器不会出现这种错误
测试二:会不会是验证方式的问题?而且服务器真的有尝试过链接?
方法:移出身份验证,再尝试连接:
直接就引发了:Client does not support authentication protocol requested by server; consider upgrading MySQL client;
这说明服务器是尝试连接的,也说明不是用户的问题。改回“旧的身份验证”继续测试
测试三:由于测试二,推断可能是密码问题,所以修改密码试试
结果:成功登录
再修改回原来的密码,结果也是登录成功。
我们来总结下过程:
原用户 => 密码 123
登录时: 密码 123; 登录错误
删除用户,创建该用户继续尝试 => 密码 123
登录时: 密码 123; 登录错误
修改密码:abc
登录时:密码 abc;登录成功
修改回旧密码:123
登录时:密码 123;登录成功
再转到 user 表,看着 password 字段是加密的,那么如果 mysql 的登录过程中根据时间戳等来加密密码之后再进行 user 表比对,
那么 mysql 报出 访问被拒绝
也是意料之中。
而 Mysql 的用户管理极有可能存在缓存,因此即便删除,重新创建也会报出相同错误(猜测)。
更新密码后也更新了密码字段,所以原有密码也可以登录了。
这样就解释得通了,可是经常登录的为什么不会报错?
这个有待测试,我觉得 MySQL 会更新密码字段。当然仅仅是推测。