MySQL2 客户端在 Deno 环境下的认证问题分析与解决方案

MySQL2 是一个流行的 Node.js MySQL 客户端库，提供了高性能的 MySQL 数据库连接能力。近期有开发者报告在使用 Deno 运行时环境中遇到了一个特殊的认证问题：在 MySQL 服务器重启后首次连接时会遭遇"Access Denied"错误，但通过命令行客户端登录一次后，应用就能正常连接。本文将深入分析这一问题的根源，并介绍最终的解决方案。

问题现象

开发者在使用 MySQL2 客户端库连接 MySQL 8.x 数据库时，观察到以下现象：

1. 当 MySQL 服务器刚启动时，应用首次连接会失败，报错"Access denied for user"
2. 通过命令行客户端（如 mysql CLI）使用相同凭据成功登录一次后
3. 应用后续连接就能正常工作，直到服务器再次重启

这个问题仅在 Deno 环境下出现，在 Node.js 环境中则表现正常。

技术背景

MySQL 8.0 引入了新的默认认证插件 caching_sha2_password，取代了旧的 mysql_native_password。这种新的认证机制采用了更安全的 SHA-256 哈希算法，并引入了缓存机制来提高性能。

认证过程分为两种模式：

1. 快速认证（FAST_AUTH）：当客户端已被服务器"记住"时使用
2. 完整认证（FULL_AUTH）：首次连接时使用，涉及公钥加密交换

问题分析

通过调试日志，我们发现关键差异在于认证过程中服务器返回的数据包类型：

• 失败时：服务器返回 PERFORM_FULL_AUTHENTICATION_PACKET (0x04)
• 成功时：服务器返回 FAST_AUTH_SUCCESS_PACKET (0x03)

深入分析发现，问题出在 Deno 和 Node.js 在 crypto.publicEncrypt() 方法的默认填充方式不同：

• Node.js 默认使用 RSA_PKCS1_OAEP_PADDING (4)
• Deno 默认使用 RSA_PKCS1_PADDING (1)

这种差异导致 Deno 环境下生成的加密数据与服务器预期不符，从而认证失败。

解决方案

修复方案是在调用 publicEncrypt 时显式指定填充方式为 RSA_PKCS1_OAEP_PADDING：

return crypto.publicEncrypt({
  key,
  padding: crypto.constants.RSA_PKCS1_OAEP_PADDING
}, stage1);

这一修改确保了无论运行环境如何，都会使用与 MySQL 服务器兼容的加密填充方式。

实际应用

对于使用 MySQL2 库的 Deno 开发者，建议：

1. 确保使用 MySQL2 v3.9.8 或更高版本
2. 如果无法升级，可以手动指定认证插件配置：

const connection = mysql.createConnection({
  // ...其他配置
  authPlugins: {
    caching_sha2_password: mysql.authPlugins.caching_sha2_password({
      overrideIsSecure: true
    })
  }
});

总结

这个问题展示了不同 JavaScript 运行时环境在加密实现细节上的差异可能导致兼容性问题。MySQL2 库通过明确指定加密参数，确保了在各种环境下的稳定运行。对于开发者而言，理解底层认证机制有助于快速诊断和解决类似问题。

此问题的解决也提醒我们，在使用较新的数据库认证机制时，需要特别注意客户端库与运行环境的兼容性，特别是在非 Node.js 环境中。