构建自定义验证码登录系统及研究语音验证码实战

Fri, 21 Mar 2025 07:22:34 +0000

当我使用小程序码登录网站时，我发现了一个问题，在手机端不方便登录。我们都知道手机号验证码可以登录网站，但是我没有资源去实现手机号验证码功能，我使用一个变通的方案，在手机端不使用手机号验证码也能登录。

小程序实现验证码登录

它的核心还是鉴权，我在小程序端制作了一个获取验证码界面，它可以生成模拟编号和验证码。当用户点击获取验证码时，会向后台请求返回编号和验证码，后台这个时候会记录为哪个用户openid生成了哪个验证码。那为什么不单单使用验证码呢？还要再添加一个编号，不麻烦吗？因为单单使用验证码会发生撞车的可能。要知道，验证码一般4位或者6位，很容易被暴力攻击的。

当用户在网站端输入编号和验证码时，后端会校验是否存在这对编号和验证码，如果校验正确，将取出openid并绑定到sessionID上，然后返回给前端，存入cookie中。可以看看前面的文章，扫描二维码登录，同样的道理。

除了在小程序生成验证码外，我们还可以在公众号中发送消息获取验证码。它其实也是使用了微信的账号体系。

公众号实现验证码登录

要知道公众号不仅是内容分发平台，更是一个强大的身份认证中间件。我们使用发送消息来获取验证码信息。

1. 握手与回调 (Webhook)

当你在公众号消息发送验证码三个字时，微信会推送事件到你的服务器。我使用go对接了微信公众号消息。

要在 Go 中接收微信消息，你必须先在微信公众平台配置一个 服务器地址 (URL)。** 微信会向你的 URL 发送一个 GET 请求，包含签名、随机数等。你必须按照规定的算法计算并返回正确的 echostr，这被称为“服务器验证”。验证通过后，每当用户发送消息，微信服务器就会以 POST 方式将消息体推送给你。

2. 解析 XML 数据

与现代 API 不同，微信公众号的推送采用的是 XML 格式。Go 的标准库 encoding/xml 提供了强大的解析能力：

type WxMsg struct {
 ToUserName string `xml:"ToUserName"`
 FromUserName string `xml:"FromUserName"` // 这就是用户的 OpenID
 Content string `xml:"Content"` // 用户发来的文字
}

3. 验证码生存逻辑

当用户发送“验证码”关键字时，我们的 Go 后端会生成一个 4-6 位的随机数和一个编号。并将消息中的 OpenID 与编号和随机数存入 Redis，并设置 TTL（如 5 分钟）。然后通过 XML 响应将验证码发回给用户。

4. 身份绑定，完成登录

我们在Web HTML页面提供了登录表单，提供编号和验证码输入框。用户输入编号和验证码后提交到后端，后端从 Redis 中根据编号和验证码反查 OpenID，若存在且有效，则代表身份验证成功，返回包含身份的TOKEN。

基于 Go + 小程序实现网页端“扫码登录”实战

Sat, 15 Mar 2025 07:22:34 +0000

不想使用账号和密码登录，害怕被攻击，也不想做注册等功能；不想使用手机号和验证码登录，没有钱也没有资质去做这些。我想到了二维码，通过二维码进行登录。这里有一个核心的问题还是如何鉴权？

在了解小程序后，我就决定使用小程序扫描二维码登录，使用小程序自带的微信账户体系完成鉴权。

我们要知道，二维码（QR Code）是连接物理世界与数字世界的“虫洞”。在登录系统中，它承载着一个临时的身份信标。

在实现这个Web登录功能的过程中，我们需要：

1. 生成有效二维码

这个二维码需要显示在网页上，供用户扫码登录，登录二维码通常包含一个加密的 URL 或一个唯一的 UUID（通用唯一识别码）。

这个唯一识别码需要具备的特性：

唯一性： 每一对扫描动作都必须对应一个独一无二的 ID。
时效性： 二维码必须配合 Redis 设置过期时间（如 2 分钟），逾期自动失效。

在本项目中，我们将用户的微信 OpenID 作为 Key，生成的验证码作为 Value，使用Redis进行存储：

// 存储验证码，并设置 5 分钟过期
err := rdb.Set(ctx, "user:123:code", "8888", 5*time.Minute).Err()

// 读取验证码
val, err := rdb.Get(ctx, "user:123:code").Result()

当有了二维码内容后，我们需要工具来生成二维码，在 Go 生态中，我们使用 skip2/go-qrcode 库来完成像素的绘制：

// 生成二维码字节数组
var png []byte
png, _ = qrcode.Encode("91demo.top"+sessionID, qrcode.Medium, 256)

为了防止用户伪造扫码请求，二维码里的内容通常是加密的或者是不可预测的长随机数（UUID）。只有真实存在的 ID 才能通过后端的 Redis 校验。

2. 传输二维码

当在服务端生成二维码后，还需要传递给浏览器，让浏览器进行显示，用户才可以扫码。这里有两个方法：1，生成图片文件，然后浏览器下载后显示。2，将图片内容转为Base64字符串传递给浏览器。这里我们选择了后者，我们不希望在用户硬盘上产生大量的临时 .png 文件。

在Go中可以这样操作：

// 转换为前端可直接识别的 Data URL
base64Img := "data:image/png;base64," + base64.StdEncoding.EncodeToString(png)

为了让前端不至于崩溃，后端必须返回统一的格式。

func HandleLogin(c *gin.Context) {
 // 逻辑处理...
 c.JSON(200, gin.H{
 "code": 1,
 "content": base64Img,
 })
}

在前端，我们不再需要引入沉重的第三方库来做简单的请求。浏览器原生提供的 Fetch API 简洁且基于 Promise。

登录 on 豆子技术站