DuckBurnIncense

> 会有request事件。一般来说官方客户端上能收到的邀请，都可以收到。 没收到的话可能是邀请根本没发出，原因可能是某一方被风控，导致邀请被过滤。 邀请应该已经发出了的, 同时登录 `oicq` 和 `电脑版qq`, `电脑版qq` 可以收到邀请, `oicq` 却没有任何输出 (`oicq` 已订阅 `request` 事件)

个人理解, 前端应该仅作为向用户展示信息和交互的工具, 不应该 (只) 在前端做关于安全方面的校验或在前端存储应该保密的 API Keys 等. 重要的逻辑和应该保密的信息等应该在后端处理. 再者, 即使将 `Vue Force Dev` 拓展使用的方法封禁, 前端 (打包后的) 源码依然可以被用户下载. 如果不怀好意的人想知道前端里的重要信息一样可以通过阅读源码来获得, 只是稍微麻烦一点而已. (我就这样对一些 Webview 套壳 Android apps 做过, 还抓包改了前端源代码获得了一些权限. 这些软件就是安全校验只在用户端进行的反面教材). 综上, 我认为封禁...

Same issue, Edge version: 116.0.1923.0 (Standard) dev (64 bit) 

Edge version 116.0.1938.29 (Standard) dev (64 bit). It appeared. (￣ ‘i ￣;) 

[icqq](https://github.com/icqqjs/icqq) 也不再维护了 (`This repository has been archived by the owner on Oct 20, 2023. It is now read-only.`), 这个项目不会也要凉了吧

Same issue here, since I upgraded Ubuntu from 23.04 to 24.04 LTS. Nothing happen after pressing `Prt sc`. The `/var/log/syslog` is as follows: ```text 2024-06-10T14:07:38.231260+08:00 DuckBurnIncense systemd[4192]: Started app-gnome-flameshot-19390.scope -...

刚遇到了同样的问题 (我是注册的时候填邮箱 `[email protected]` 漏了最后那个小数点 (当时没发现), 导致我后期登录不上), 翻了下源码, 应该是 (我不会 Rust, 所以只能说是应该) 后端就没写更新邮箱的接口导致的, 相关源码如下: https://github.com/Privoce/vocechat-server-rust/blob/4f14fe0d59703c3cf85a31c01582c508190bfc2f/src/api/user.rs#L54C1-L71C2 https://github.com/Privoce/vocechat-server-rust/blob/4f14fe0d59703c3cf85a31c01582c508190bfc2f/src/api/user.rs#L80C1-L92C2 https://github.com/Privoce/vocechat-server-rust/blob/4f14fe0d59703c3cf85a31c01582c508190bfc2f/src/api/user.rs#L702C1-L813C6 709 行 `req.is_empty()` 为真则返回 `BAD_REQUEST`, 而第 90 行的 `req.is_empty` 方法表明如果 `name`, `gender` 和 `language`...

api的锅, [新闻联播官网(https://tv.cctv.com/lm/xwlb/index.shtml)](https://tv.cctv.com/lm/xwlb/index.shtml)至今没更新那一段视频的文字稿, 所以我的程序也就没抓到 >  > 截图于2023-02-03 10:41:54

> 是因为二进制导致的么，和 #304 问题类似，提供个rawBody只读字段, 表示二进制，需要修改字节还是改 body，会判断修改的body字段是二进制还是字符串，这样是否可以解决 我认为比较好的解决方案是把 `body` 以类似 nodejs 中的 `Buffer` 类型提供，由脚本开发者自己根据 request / response header 的 `Content-Type` 判断，并通过给定 API 转换为自己所需的类型，完成修改后再将数据转换为 `Buffer` 填回 `body` 中返回。这样可以确保不会因为 proxy pin 的强制类型转换改变脚本的返回内容。 如果不是这样的话，需要考虑一些特殊情况，如脚本期望返回一张图片（二进制数据，而不是普通文本）、脚本希望返回与原服务器响应类型不一致的数据（如服务器返回...

> 都是字节数组使用起来不够简化，不能因为少部分场景，而影响大部分 这个确实，但我仍然保留我的观点，因为其一，“脚本” 本就是为 “高级” 用户准备的 “以灵活的方式操作请求/响应” 的工具，如果因为需要适应 “大部分” 而舍弃 “灵活性”，我认为这是舍本逐末的。其二，总有一天，“小白” 也会碰上一些奇奇怪怪的需求，了解到编解码，二进制数据，成为 “大佬”。若为二进制数据定义一个完全不同的操作逻辑，显然非常影响开发体验。 如果要既保留简洁性，又保留这些对二进制数据加工的灵活性，我想到了一种可能的解决方式：效仿 [`"use strict"`](https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Strict_mode)，新增一个 `"use high-level"` 模式，若脚本开发者用 `"use high-level"` 声明自己需要一些高级功能，才将 `body` 作为 `Buffer` 传递给脚本，否则默认按最简便的来。