结论:90%的AuthenticationFailed错误源于authSource配置错误,它必须等于用户创建所在的数据库名(如admin或myapp),而非目标业务库;未指定时默认为admin,易导致认证失败。
直接说结论:90% 的 OperationFailure: authentication failed 错误,不是密码输错了,而是 authSource 没配对 —— 它必须等于用户实际创建所在的数据库名,而不是你打算操作的业务库。
很多人凭直觉把 authSource 设成自己要访问的库(比如 myapp),但 MongoDB 认证只看“用户在哪建的”。查证方式很简单:进 mongosh,执行 use admin → db.getUsers(),看每个用户的 db 字段值。
admin 库创建 → authSource="admin"(MongoDB Atlas 强制如此)myapp 库创建 → authSource="myapp",哪怕你要连的是 otherdb
authSource 参数 → 默认用 admin,容易失败示例正确写法:mongodb://user:pass@localhost:27017/myapp?authSource=myapp
新版本 MongoDB 默认启用 SCRAM-SHA-256,但旧版 PyMongo(SCRAM-SHA-1,导致握手失败。错误现象是连接不报错,但首次操作(如 list_collection_names())才抛出认证失败。
立即学习“Python免费学习笔记(深入)”;
authMechanism=SCRAM-SHA-256(注意大小写)mongodb://user:pass@localhost:27017/?authSource=admin&authMechanism=SCRAM-SHA-256
密码里有 @、/、:、+ 等字符时,URI 解析会提前截断。例如密码是 pa@ss/w+rd,不编码就会被当成 host 或 port 的一部分。
from urllib.parse import quote_plus → quote_plus("pa@ss/w+rd") 得到 pa%40ss%2Fw%2Brd
mongodb://user:pa%40ss%2Fw%2Brd@localhost:27017/...
即使所有配置都对,MongoDB Atlas 有时会卡住旧用户的状态(尤其改过密码或角色后)。现象是:控制台显示用户存在、权限已分配,但连接仍报 bad auth : authentication failed。
readWrite 或对应业务库的权限,仅 dbAdmin 不够用真正棘手的点往往不在代码里,而在用户账户本身的状态一致性 —— 它不报错,也不提示,就静默拒绝。