登录时滑块和设备锁事件建议

[BennettChina]

环境信息

go-cqhttp版本: dev 环境：Docker容器

问题背景描述

登录时触发的设备锁事件等待时间过短，仅仅 5 秒的等待时间有点反人类设计了，我在登录时等我复制好链接->访问链接->等待加载二维码->掏出手机扫描二维码，完成整个事件后返回看日志发现已经再次触发登录事件，于是我还需要再滑动一次验证码，好在这一次登录没有再触发设备锁，否则将成为死循环了。

需要添加的功能内容

以下内容仅基于容器无交互终端的方式考虑。

首先这个等待时间最好优化一下，最起码要有1分钟的等待时间，其次是是否可以做一个网页去输入短信验证码达到滑动验证码自动提交的方式，个人感觉短信验证码的方式会比扫码更好用一点，可以考虑在这种方式下无交互终端时优先用短信验证码方式。

---

以下是触发事件时的日志：

[2023-08-02 11:39:19] [WARNING]: 登录需要滑条验证码, 请验证后重试. 
[2023-08-02 11:39:19] [WARNING]: 请选择提交滑块ticket方式: 
[2023-08-02 11:39:19] [WARNING]: 1. 自动提交 
[2023-08-02 11:39:19] [WARNING]: 2. 手动抓取提交 
[2023-08-02 11:39:19] [WARNING]: 请输入(1 - 2)： 
[2023-08-02 11:39:19] [WARNING]: 请前往该地址验证 -> https://captcha.go-cqhttp.org/captcha?id=8KivdbMk&style=simple&aid=16&uin=********&sid=*******&cap_cd=7LRQ6p1oQ********************1YKwmr1lbHOEb9qC3Q**&clientype=1&apptype=2  
[2023-08-02 11:39:20] [ERROR]: Protocol -> parse incoming packet error: return code unsuccessful: -10005 
[2023-08-02 11:39:35] [WARNING]: callback error: Packet timed out 
[2023-08-02 11:39:37] [ERROR]: Protocol -> parse incoming packet error: return code unsuccessful: -10005 
[2023-08-02 11:39:51] [WARNING]: callback error: Packet timed out 
[2023-08-02 11:39:52] [WARNING]: 账号已开启设备锁，请选择验证方式: 
[2023-08-02 11:39:52] [WARNING]: 1. 向手机 1*1*******0 发送短信验证码 
[2023-08-02 11:39:52] [WARNING]: 2. 使用手机QQ扫码验证. 
[2023-08-02 11:39:52] [WARNING]: 请输入(1 - 2)： 
[2023-08-02 11:39:52] [WARNING]: 未检测到输入终端，自动选择2. 
[2023-08-02 11:39:52] [WARNING]: 账号已开启设备锁，请前往 -> https://accounts.qq.com/safe/verify?_wv=2&_wwv=128&envfrom=double-check&uin=***********&sig=eUH930FosFF5Z6tdWOq07uGNHPyU%2F*********************dRrWJDlAJjxqe%2BVHlGNQHMcDu0HNyxeYb18Qzg******************************65hns2X9q6L87lOWXXZvDe2TGJ1UrCjDU9wX6vMHlzu51lZoFFICSyq%2Bqz1Ucat7R4J9nAQSF4j9pLQ2FQqLoNjzHujdoLZlnbhPEk546Q7WzuzB1Un2bBoi8Nj2HidhP <- 验证后重启Bot. 
[2023-08-02 11:39:52] [INFO]: 按 Enter 或等待 5s 后继续.... 
---Setup Timezone to Asia/Shanghai---
---Checking if UID: 99 matches user---
usermod: no changes
---Checking if GID: 100 matches user---
usermod: no changes
---Setting umask to 002---
---Taking ownership of data...---
Starting...
[2023-08-02 11:39:53] [INFO]: 当前版本:(devel) 
[2023-08-02 11:39:53] [INFO]: 将使用 device.json 内的设备信息运行Bot. 
[2023-08-02 11:39:53] [INFO]: 使用服务器 http://adachi-qsign:80 进行数据包签名 
[2023-08-02 11:39:59] [INFO]: 连接至签名服务器: http://adachi-qsign:80 
[2023-08-02 11:40:12] [INFO]: 注册QQ实例 *************** 成功: The QQ has already loaded an instance, so this time it is deleting the existing instance and creating a new one. 
[2023-08-02 11:40:12] [INFO]: Bot将在5秒后登录并开始信息处理, 按 Ctrl+C 取消. 
[2023-08-02 11:40:12] [INFO]: 每 40 分钟将刷新一次签名 token 
[2023-08-02 11:40:17] [INFO]: 开始尝试登录并同步消息... 
[2023-08-02 11:40:17] [INFO]: 使用协议: Android Pad 8.9.63.11390 
[2023-08-02 11:40:18] [INFO]: 正在检查协议更新... 
[2023-08-02 11:40:20] [INFO]: Protocol -> connect to server: [::ffff:49.7.253.177]:8080 
[2023-08-02 11:40:25] [WARNING]: 登录需要滑条验证码, 请验证后重试. 
[2023-08-02 11:40:25] [WARNING]: 请选择提交滑块ticket方式: 
[2023-08-02 11:40:25] [WARNING]: 1. 自动提交 
[2023-08-02 11:40:25] [WARNING]: 2. 手动抓取提交 
[2023-08-02 11:40:25] [WARNING]: 请输入(1 - 2)： 
[2023-08-02 11:40:25] [WARNING]: 请前往该地址验证 -> https://captcha.go-cqhttp.org/captcha?id=BGr4gieV&style=simple&aid=16&uin=*************&sid=*************&cap_cd=A7Ys7Q-haKo7ts8yoT******************jCsGEfd79p0cYEoWg**&clientype=1&apptype=2  
[2023-08-02 11:40:26] [ERROR]: Protocol -> parse incoming packet error: return code unsuccessful: -10005 
[2023-08-02 11:40:41] [WARNING]: callback error: Packet timed out 
[2023-08-02 11:40:42] [ERROR]: Protocol -> parse incoming packet error: return code unsuccessful: -10005 
[2023-08-02 11:40:57] [WARNING]: callback error: Packet timed out 
[2023-08-02 11:43:05] [WARNING]: Protocol -> device lock is disabled. HTTP API may fail. 

[KafuuEriri]

这个应该是策略，如果短时间不处理会被qq认为是bot风控

[BennettChina]

个人感觉不会因为这个被风控，5秒反应时间根本不是人能反应过来的，如果能在5秒内处理完反而才只有bot能达到秒处理。而在使用官方客户端时停在设备锁界面的用户也大有人在，甚至杀掉程序完全不去处理的也不少，反而短时间内多次尝试登录说不定会被风控。

[rhwong]

我有点没看懂此问题的诉求。 这个扫码验证完成后，本来也要重新走登录流程啊，为什么要等待1分钟，等待什么？ 这里的操作是提示扫码后，复制链接去扫码。 完成设备锁认证后，重新运行程序即可，并不需要你实时的去解锁。

[wiketool]

我打开设备锁那个链接页面是空白，有人遇到过一样的问题吗？

[BlackcatWatcher]

我打开设备锁那个链接页面是空白，有人遇到过一样的问题吗？

换浏览器大法。

我有点没看懂此问题的诉求。 这个扫码验证完成后，本来也要重新走登录流程啊，为什么要等待1分钟，等待什么？ 这里的操作是提示扫码后，复制链接去扫码。 完成设备锁认证后，重新运行程序即可，并不需要你实时的去解锁。

在windows平台，用批处理方式启动的情况下，结束了窗口直接关闭了，没机会复制链接，甚至不知道有这个设备锁。导致又一次重新验证后又一次关闭。解决方法可能是批处理里加个pause，或者用cmd打开gocq不会自动关闭。

[BennettChina]

我有点没看懂此问题的诉求。 这个扫码验证完成后，本来也要重新走登录流程啊，为什么要等待1分钟，等待什么？ 这里的操作是提示扫码后，复制链接去扫码。 完成设备锁认证后，重新运行程序即可，并不需要你实时的去解锁。

正常来说你滑动验证码处理完，再处理设备锁（扫码/短信验证码），都处理完后再登录就要么45啊等错误码出错登不上去，要么就直接登上去开始加载个人信息，而实际情况是5秒等待还没处理完设备锁等事件，此时去登录就会再次触发滑动验证码等事件，就凭空又多处理了一次事件，这肯定不会是友好的使用情况。

[rhwong]

正常来说能到设备锁这一步，基本就不会出现code45了。目前的流程是如果你选择了（或者被迫选择）2，那么会返回设备锁解锁链接，然后解锁后，重启程序再次操作登录即可完成。 但是我大概懂你的意思了，是说结束的太快导致你还没扫完码，docker容器就自动重启了？ 我从没用过go-cqhttp的容器所以不是很了解这个。 但是从理论上来说不影响你滑块与否，因为再次重启的容器也只会停到滑块这一步，你完全可以不滑直接重启容器，或者滑一下也不会影响账号的安全。 不过我觉得确实可以增加将默认选项改为1，这样可能会更加友好，我不是很喜欢那个扫码的方式。

[BennettChina]

之前我确实没意识到后面的日志是容器重启后打印的，那么gocq这边的登录流程跟我之前使用的 oicq 就有点不一样了，是不是也可以优化一下这个登录流程，在事件处理完后程序再调用一次登录函数而不是结束进程让用户重启程序触发登录，由程序自己调用的话整个流程就会比较连贯，这样也比较符合大多数程序设计的方式，即在用户处理完风控后直接登录然后再加载对应的各种信息。

[rhwong]

之前我确实没意识到后面的日志是容器重启后打印的，那么gocq这边的登录流程跟我之前使用的 oicq 就有点不一样了，是不是也可以优化一下这个登录流程，在事件处理完后程序再调用一次登录函数而不是结束进程让用户重启程序触发登录，由程序自己调用的话整个流程就会比较连贯，这样也比较符合大多数程序设计的方式，即在用户处理完风控后直接登录然后再加载对应的各种信息。

这是因为go-cqhttp无法感知到用户已经完成设备锁扫码认证。 或许可以修改成用户确认扫码已完成后，按回车，然后重新调用登录流程。（mirai好像是这样的）

[BennettChina]

之前我确实没意识到后面的日志是容器重启后打印的，那么gocq这边的登录流程跟我之前使用的 oicq 就有点不一样了，是不是也可以优化一下这个登录流程，在事件处理完后程序再调用一次登录函数而不是结束进程让用户重启程序触发登录，由程序自己调用的话整个流程就会比较连贯，这样也比较符合大多数程序设计的方式，即在用户处理完风控后直接登录然后再加载对应的各种信息。

这是因为go-cqhttp无法感知到用户已经完成设备锁扫码认证。 或许可以修改成用户确认扫码已完成后，按回车，然后重新调用登录流程。（mirai好像是这样的）

我的意思是扫完码回车是一种感知方式，另一种就是设置固定的等待超时时间，超时后直接调用登录流程，这种情况下即使未扫完重新登录遇到的也是跟我一样再滑动一次验证码。最好的就是使用短信验证码的方式，和滑动验证码自动获取方式一样提供一个网页，这样在用户输入验证码提交后就可以感知到用户已完成验证，然后结束兜底的超时等待直接调用登录流程。