真不明白求着注册 L 站的心理，还要强迫自己写小作文申请，无法理解...

昨晚注册的 [email protected] ，期间还有机票报销发票邮件进来。

凌晨 1 点半收到被官方回收邮件，但是到现在貌似有些地方显示还有 bug ，依旧显示 [email protected] ，另外 QQ 加好友搜 [email protected] 也依旧能搜到我的这个 QQ 号。

https://imgur.com/a/vQ5uDh4

今天刚续费的 腾讯轻量云 CPU4 核、内存 4GB 、系统盘 70GB 、带宽 6Mbps

730R / 3 年 （ 2.7 折）

这台机器之前开过两年.

《那天下雨了》正在单曲循环...听久了还可以

我也是有这个情况，已经登录了两年的账号，前几天清理手机将 tg 卸载后，再下载回来登录提示需要 SMS 收费

实测解决办法：

使用海外苹果 ID ，从 https://telega.me/ 下载俄语版第三方客户端，登陆后界面和 TG 原版一样。
登录上去后，还能通过扫码，在官方 web 端或者客户端登录, 数据是相通的。

如图： https://imgur.com/a/jJMScYr

目前来看的话还只是一个玩具，架构也不难，自己手搓一个简化版也很快，要不也不会一下有这么多类似项目出现...
但对于非专业程序开发者来说，那就很强大了，毕竟 deepseek 也只是在简单的聊天界面和 AI 聊天，现在通过各种集成，改变了这种玩法。

很多时候有信息差，比如 2022 年 12 月我就开始使用 chatgpt3.5, 但这种聊天生成式 AI 在国内被大家熟知 比如 gpt3.5 可能很多人在 24 年才有了解使用过，而国内普通人熟知 AI 并开始使用，还是在 25 年过年 deepseek 爆火后...

现在是玩具不代表以后不能当生产力，我觉得后面会出现更多类似集成强大的项目。


>如何看 OpenClaw 超越 Linux 登顶 Github Star 第一？

我觉得这个只要爆火起来有关注度，无论其设计和架构是否 nb, 都会有人先手点个 star 的，当收藏吃灰也行，所以登顶 Github Star 第一也不奇怪。

欲买桂花同载酒，终不似，少年游。

逆天，重点在于“婚前隐瞒”，为什么评论区这么多人都针对女的说？真离谱！
觉得男方没问题的，代入一下以后自己女儿遇到这种男的吧...

>如果人生是场游戏，我的幸运值恐怕是负数

同感。在任何领域，任何时间和地点，我的运气 跟上帝跟我开玩笑似的 特别特别差。

当时 2025-9 高位 0.011 买的 1400 刀，现在只剩 220 刀 /(ㄒoㄒ)/~~

交易的对手从来都不是别人，而是自己的内心。

遇到过很多这种，比如之前遇到有一男一女带着 10-15 岁左右的女孩，说钱包丢了，小孩两天没吃饭了，能不能帮助一下给点饭钱让小孩吃饭，那一男一女看我在犹豫，还拉着那女孩让她叫我哥哥并说求求你了...

还有就是从小到大看到无数次，看着像女大或者女高中生那种（有些看着像学生装），蹲在那，面前摆张卡纸，纸上写着 xxx 困难（要饭钱/车钱），她们共同特征是 都披着头发都散下来，看不到脸 (ˉ▽ˉ；)...

这个我要吐槽一下 iPhone ，电信、联通和移动，用哪个运营商都一样，和朋友一起在动车上，他在旁边用 Android 手机随便刷抖音，我却连微信消息都发不出去，大部分时间都是在重连...啥都不错，信号这方面真就不敢恭维了。

这博客看的好舒服，排版很棒，写的很用心，照片拍的好！

@hackerwgf

>哎，曾经很骄傲可以从一堆下载中找到真实的下载按钮

死去的回忆突然攻击我 :)

另外, 双 token 比单 Token 也有利于日志分析：

检测到 access_token 异常 → 可能是网络攻击
检测到 refresh_token 异常 → 可能是账户被盗


场景 A：Access Token 被重复使用, 重放攻击
时间线：
T0: 用户请求 GET /workflows ，Access Token 在网络中传输
T1: 攻击者在网络中拦截到这个 Access Token
T2: 攻击者立即用这个 Access Token 发起请求
T3: 15 分钟内，Access Token 仍然有效 → 攻击成功

# 日志中看到：
- 同一个 Access Token 来自不同 IP
- 同一个 Access Token 在短时间内高频使用
- User-Agent 不一致

影响范围： 相对局部（只影响当前 token 时间窗口）



# 场景 B：Refresh Token 被重复使用
时间线：
T0: 用户登录，得到 RT_1 ，存储在 localStorage
T1: 攻击者通过某种方式窃取了 RT_1 （钓鱼、数据库泄露、恶意软件等）
T2: 用户的浏览器自动刷新，用 RT_1 → 得到 RT_2 ，RT_1 进黑名单
T3: 攻击者尝试用 RT_1 刷新 → ❌ 触发第 133-135 行的检测


而如果是单 token ，则无法区分是哪种场景导致的黑名单 Token 被重复使用

单 Token 重复使用的多种可能性. 有可能是
1.并发刷新（正常行为）
用户打开页面，5 个 API 同时发起：
──────────────────────────────────────
T0: 5 个请求都带着过期的 token_v1
T1: 5 个请求都返回 401
T2: 5 个响应拦截器同时触发刷新
- 请求 1: POST /refresh { token: token_v1 } → 成功，返回 token_v2 ，token_v1 进黑名单
- 请求 2: POST /refresh { token: token_v1 } → ❌ 黑名单检测触发
- 请求 3-10: 同样被拒绝

2.多 Tab/多窗口（正常行为）
用户同时打开多个 Tab：
──────────────────────────────────────
Tab A: 用户正在浏览，token 刚好过期
Tab B: 用户也在操作，同一个 token 过期

Tab A 先刷新：
POST /refresh { token: token_v1 } → 成功，token_v1 进黑名单
localStorage.setItem('token', token_v2)

Tab B 延迟几秒刷新（还没来得及读取新 token ）：
POST /refresh { token: token_v1 } → ❌ 黑名单检测触发

# 后端日志：
# 以上问题检测到 token_v1 被重复使用，但不能确定是不是网络攻击！


3.账户被盗（异常行为
真正的攻击场景：
──────────────────────────────────────
T0: 攻击者窃取了 token_v1
T1: 合法用户刷新：POST /refresh { token: token_v1 } → token_v2 ，token_v1 进黑名单
T2: 攻击者尝试刷新：POST /refresh { token: token_v1 } → ❌ 黑名单检测触发

# 后端日志：
# 检测到 token_v1 被重复使用
# 这次是真的攻击！

问题 1：

单 Token 方案：同一个 token 既用于访问又用于刷新

问题场景：
用户在 Tab A 刷新了 token ，得到 token_v2
用户在 Tab B 仍然持有 token_v1
Tab B 的请求会失败（因为 token_v1 已在黑名单），无法刷新
需要复杂的跨 Tab 同步机制


问题 2：
单 Access Token 的暴露场景：
每个 API 请求的 HTTP Header 中
浏览器开发者工具的 Network 面板
可能被记录在服务器日志中
可能通过中间代理服务器
如果有 XSS 漏洞，容易被窃取

假设你每天发送 1000 个请求 → Access Token 暴露了 1000 次，用作刷新 token 不安全


而双 token 中 Refresh Token 仅在以下情况使用：
✅ Access Token 过期时（比如每 8 小时一次）
✅ 只发送到特定的刷新接口
✅ 不会出现在普通业务请求中


虽然 Refresh Token 也有被窃取的风险，但是风险小很多

云 GPU 可以试试 Autodl: https://www.autodl.com/