[Feature] 微软账户登录添加《临时登录》选项

[zkitefly]

描述 | Description

RT，当勾选时，不保存 refreshToken，当第二次启动 HMCL 时就会弹出弹窗要求重新登录，这样可以以防账户被盗？

但缺点也如此，第二次启动 HMCL 时，登录微软账户阶段会使用 refreshToken 刷新 accessToken，无论 accessToken 是否过期，这个可能需要优化下？

原因 | Reason

这样可以以防账户被盗？

[8MiYile]

虽说Minecraft不像Steam上的游戏有盗号风险，但网吧那种环境，懂的都懂，这个功能很有必要

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题
引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

[zkitefly]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

[FunnyShadow]

也许可以尝试在关闭 HMCL 时自动清理 refreshToken 或者添加 信任此电脑 相关按钮来保存 refreshToken？

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

但是这个频繁程度很可能会触发微软的风险控制机制，如果盗号的情况下官方客服还是支持的，但是这种很有可能会因为违反 ToS 导致不被受理乃至完全销号）

甚至可能适得其反，在没有被人盗号的情况下被系统误判为存在风险，自动做出某些防止盗号的行为

[zkitefly]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

但是这个频繁程度很可能会触发微软的风险控制机制，如果盗号的情况下官方客服还是支持的，但是这种很有可能会因为违反 ToS 导致不被受理乃至完全销号）

我觉得应该不会有人在短时间内频繁登录吧（

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

但是这个频繁程度很可能会触发微软的风险控制机制，如果盗号的情况下官方客服还是支持的，但是这种很有可能会因为违反 ToS 导致不被受理乃至完全销号）

我觉得应该不会有人在短时间内频繁登录吧（

如果按照你这个设想，重启一次 HMCL 就需要重新登录，这个频次算下来，如果我测试一些 Mod 或者其他什么东西需要频繁重启 HMCL 的话，这在微软的风控系统看来就算是频繁登录了）

[FunnyShadow]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

[zkitefly]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

HMCL因为是开源的，加密了等于没加密。黄鱼说的（

[FunnyShadow]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

这样的话，所有使用了此账号的 HMCL 在尝试进行一次新的启动（乃至游戏内）都会被强行要求重新登录（游戏内应当会提示会话失效，并要求重新启动游戏或重启启动器）

[FunnyShadow]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

HMCL因为是开源的，加密了等于没加密。黄鱼说的（

每个系统单独生成一个加密密钥不就好了）））

[FunnyShadow]

加密算法可以是开源的，但是密钥不一定得是啊）

就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的 refreshToken 进行加密存储，需要时在利用这个加密密钥进行解密

这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个 refreshToken

[zkitefly]

那我觉得可以在使用 refreshToken 前先检验 accessToken 是否有效，如果失效了才进行刷新，所以我说如果加入这个功能就要把刷新机制调整下。

[FunnyShadow]

那我觉得可以在使用 refreshToken 前先检验 accessToken 是否有效，如果失效了才进行刷新，所以我说如果加入这个功能就要把刷新机制调整下。

true，不过我还是建议先把 refreshToken 这种东西加密存储起来，不然仅仅只是 HMCL 这里做了一个判断，有心人还是可以从HMCL 的数据存储中找到 refreshToken

而且最好是加一个必须是官方构建这套加解密功能才能起效的东西，这种东西验证逻辑应该是比较简单的（指对 accessToken 验证是否有效的逻辑），否则如果有人已经被盗号，号主吊销了 accessToken，但是这个人利用一份修改版就可以变相绕开这个限制，直接解密得到 refreshToken

[zkitefly]

加密算法可以是开源的，但是密钥不一定得是啊）

就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的 refreshToken 进行加密存储，需要时在利用这个加密密钥进行解密

这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个 refreshToken

https://github.com/huanghongxun/HMCL/issues/107#issuecomment-279193675
https://github.com/huanghongxun/HMCL/issues/107#issuecomment-279344793

代码是开源的，加密有用？

不公开是不可能的，Java反编译随时都可以知道代码

[FunnyShadow]

加密算法可以是开源的，但是密钥不一定得是啊）
就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的 refreshToken 进行加密存储，需要时在利用这个加密密钥进行解密
这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个 refreshToken

#107 (comment)
#107 (comment)
代码是开源的，加密有用？
不公开是不可能的，Java反编译随时都可以知道代码

我对此表示怀疑态度）

加密算法大多也都是开源的（诸如 RSA 与 DSA 等），他们的加密原理都是众所周知的，但这并没有导致什么问题

加密的算法是所有人都知道的，代码也是，但是加密的密钥除非被泄漏，没有人能知道，只需要在第一次启动时生成密钥即可

不然你说像 AuthMe 这种登录插件怎么给密码加密的，他们也是完全开源的）

[zkitefly]

那，加密的密钥存哪

[FunnyShadow]

那，加密的密钥存哪

可以让用户自行决定，比如让他们自己生成 PGP 密钥或者自己选择保存位置，或者直接调用系统的
（Windows 的我不太清楚，Linux 的桌面环境有专门的 PGP 密钥保管库）

[FunnyShadow]

或者去看看别的一些需要加密但是开源的工具也不是不行）

[zkitefly]

或者去看看别的一些需要加密但是开源的工具也不是不行）

算是个大工程了吧， Glavo 当时尝试搞过但没弄好，就弄个全局账户和便携账户

[FunnyShadow]

或者去看看别的一些需要加密但是开源的工具也不是不行）

算是个大工程了吧， Glavo 当时尝试搞过但没弄好，就弄个了全局账户和便携账户

这种东西确实不算很简单（至少我的技术力实现不了），但是也不应该算是一个很难搞的东西

加密库都是现成的，直接引用就好了，使用教程网上应该也是一抓一大把，毕竟加密存储账户信息这个东西也不算是很冷门）

[FunnyShadow]

不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象

[FunnyShadow]

我觉得这个东西应该去麻将官网使劲骂，这种东西完全是官方自己没做好的锅

据我了解，全球搞 Minecraft accessToken 加密的启动器总共就没几个，这也是为什么偷 refreshToken 的病毒会如此泛滥的原因

[zkitefly]

不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象

目前 HMCL 也是直接塞到一个 json 文件（

[FunnyShadow]

不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象

目前 HMCL 也是直接塞到一个 json 文件（

HMCL 是为了符合官方标准，如果官方都重视，那自然也就没这么多事了）
所以 F**K U SHITJUMP

[burningtnt]

目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token
关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？

[FunnyShadow]

目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？

赞成

[zkitefly]

目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？

我觉得这样可以在一定程度上防止恶意盗号

[burningtnt]

据我了解，全球搞 Minecraft accessToken 加密的启动器总共就没几个，这也是为什么偷 refreshToken 的病毒会如此泛滥的原因

这个真救不了
退一万步说，如果你的电脑真中病毒了，那我直接感染 HMCL 本体，给启动的命令后面加上一个把 Token 写入特定文件的逻辑，不就拿到解密后的 Token 了……

加密能，且仅能拯救的是意外把带有微软便携账户的 HMCL.json 发给别人的情况，对于中病毒这种，没招

[FunnyShadow]

你可以生成一个密钥文件，然后让用户设定主密码对密钥文件进行加密，就和 Firefox 等软件加入主密码是一个道理
Chrome 是个例，同时他的解决方案也是行业内所唾弃的

[FunnyShadow]

或者可以尝调用 Windows 凭证存储或 Linux GPG 密码库进行存储

[burningtnt]

即便是 Chrome 都会把密码库的秘钥明文存放在计算机上，所有软件都可以轻易窃取这些网站的密码。HMCL 没有很可靠的方式在保持易用性的同时去保护这些信息。

是的，所以我们不考虑应对计算机病毒

[zkitefly]

所以，这种不加密的方案如何？

[burningtnt]

这个方案的适用范围也就是网吧等只用登录一次的场地？即 refreshToken 只保存在内存里

[liumingedwin]

即使保存在内存中，不做隔离，同等级或更高等级进程可通过注入获取内存中token
这是所有方案共有的bug

[LJS08]

即便是 Chrome 都会把密码库的秘钥明文存放在计算机上，所有软件都可以轻易窃取这些网站的密码。HMCL 没有很可靠的方式在保持易用性的同时去保护这些信息。

但是 Chrome 在尝试改变，就比如尝试用TPM等技术...

[LJS08]

即使保存在内存中，不做隔离，同等级或更高等级进程可通过注入获取内存中token 这是所有方案共有的bug

使用TPM保存RT

[FunnyShadow]

实际上这就是加一个主密码进行加密保存的问题）

[LJS08]

对于加密，尝试给每个HMCL生成一个密钥对用来加/解密（或者用对称加密？） 甚至可以配合安全硬件（比如USB-Key）(但是没必要)
对于临时登录，建议不在任何地方保存RT（即使是非持久的），过期就得再次登录，由HMCL控制冷却登录。(什么银行交易系统）

最后，如果考虑计算机病毒就没边了，鬼知道这计算机病毒能搞些什么，SYSTEM? 侧信道攻击？
就算在TPM也不一定安全，因为谁知道TPM有没有被动手脚？就算TPM本身是安全的，主板电路也有可能被监听, HMCL 再厉害能防住宇宙射线翻转比特吗？能面对 IP 寄存器失效吗？能在逻辑语句有概率失效的情况下继续稳定运行吗？
如果都能，估计 HMCL 能够登上火星了。

就跟在 TeaCon 里有一次讨论对Mod进行保护时一样，这些手段也只能起到阻拦作用。

[LJS08]

实际上这就是加一个主密码进行加密保存的问题）

确实...

[zkitefly]

我当时测试微软登录问题测试登录了 30 多遍，除了邮箱有点满任何事都没有

[wifi-left]

有没有可以让key失效的api？
可以搞个“退出登录（使key失效）”
就算忘了退如果能使key失效也是可以的
（目前只发现修改密码会退）

[FunnyShadow]

有没有可以让key失效的api？
可以搞个“退出登录（使key失效）”
就算忘了退如果能使key失效也是可以的
（目前只发现修改密码会退）

没有吧
如果有的话，access token 泄漏就没有那么可怕了

[LJS08]

有没有可以让key失效的api？
可以搞个“退出登录（使key失效）”
就算忘了退如果能使key失效也是可以的
（目前只发现修改密码会退）

退出前重申请key，但不保存(直接丢弃)？

[zly2006]

有没有可以让key失效的api？ 可以搞个“退出登录（使key失效）” 就算忘了退如果能使key失效也是可以的 （目前只发现修改密码会退）

有的。https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc#send-a-sign-out-request

还有你们都说的什么乱七八糟的，临时登录就不应该请求refresh token，谁家风控会ban成功登录的正常用户？？就算你的逻辑是这么nt巨硬也不会，implicit grant本来就没有refresh token需要多次登录，oauth协议都不清楚就来瞎咧咧

[zly2006]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

@FunnyShadow 我不知道你有什么开发经验，我想请问你是从哪里看出来access token过期之后重新请求登录会被风控的，还是说你的参考文献就是大学生选修课论文里拿来凑数的？

请求登录本来就是必要的安全要求，是保证hmcl必须要在用户监督授权下才能访问数据，我想问临时登录要refresh token干嘛？巨硬会傻到因为这个封禁你？除了这么做没有更方便的办法保证用户隐私和安全，请问巨硬为何堵上这条路？找骂？（虽然骂也不少了）

[zly2006]

这东西写起来也不难，记录一下过期时间，过期了没有refresh token就要求登录，添加一个登出，按照我上面给的文档，改不了几行代码。

应该说，为了这么点破事吵这么多，诸位不看文档瞎咧咧能力真强，这完全是一个不错的功能建议。

虽说Minecraft不像Steam上的游戏有盗号风险，但网吧那种环境，懂的都懂，这个功能很有必要

反对 @8MiYile ，我们保存的是微软账户token，权限scope是整个xbox而不是只有mc，你只是不玩Xbox才无所谓...

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

@FunnyShadow 我不知道你有什么开发经验，我想请问你是从哪里看出来access token过期之后重新请求登录会被风控的，还是说你的参考文献就是大学生选修课论文里拿来凑数的？

请求登录本来就是必要的安全要求，是保证hmcl必须要在用户监督授权下才能访问数据，我想问临时登录要refresh token干嘛？巨硬会傻到因为这个封禁你？除了这么做没有更方便的办法保证用户隐私和安全，请问巨硬为何堵上这条路？找骂？（虽然骂也不少了）

就是说，有没有一种可能，我说了频繁二字？
有人频繁调用你 API 你不对它进行一定限制，所有人都来使劲调你 API，得了，成 DDoS 了
就这 GitHub 你 API 调用频繁了还会给你来 ratelimit，你微软登录 API 就没了？
哥们你没试过我可试过太多了，我们之前做微软 Azure 号的时候，这种账号成天被封，新号老号你调多了别的条件再可疑点直接翻车，你隔着儿跟我讲这个？

[burningtnt]

请两位稍微冷静冷静…… 这里是 GitHub，不是给你们互骂的。指出错误可以，但请不要使用侮辱性称呼……

[zly2006]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

@FunnyShadow 我不知道你有什么开发经验，我想请问你是从哪里看出来access token过期之后重新请求登录会被风控的，还是说你的参考文献就是大学生选修课论文里拿来凑数的？
请求登录本来就是必要的安全要求，是保证hmcl必须要在用户监督授权下才能访问数据，我想问临时登录要refresh token干嘛？巨硬会傻到因为这个封禁你？除了这么做没有更方便的办法保证用户隐私和安全，请问巨硬为何堵上这条路？找骂？（虽然骂也不少了）

就是说，有没有一种可能，我说了频繁二字？ 有人频繁调用你 API 你不对它进行一定限制，所有人都来使劲调你 API，得了，成 DDoS 了 就这 GitHub 你 API 调用频繁了还会给你来 ratelimit，你微软登录 API 就没了？ 哥们你没试过我可试过太多了，我们之前做微软 Azure 号的时候，这种账号成天被封，新号老号你调多了别的条件再可疑点直接翻车，你隔着儿跟我讲这个？

每小时调用一次如何定义为频繁？你的登录服务一个小时只能完成一次请求吗？请注意我说的实现是要把现在不检查过期时间的小bug修了的前提下说的

[zly2006]

不知道你们的序列化怎么做的，过期时间long搞成double了……

先把这个修了吧， @FunnyShadow 请注意这是HMCL的bug，而不是不能登录

[FunnyShadow]

请两位稍微冷静冷静…… 这里是 GitHub，不是给你们互骂的。指出错误可以，但请不要使用侮辱性称呼……

我承认我前面语言太过激了，很抱歉，昨天晚上没睡好早上起的又很早，看见这个真的很心烦（尤其是本来这 issue 和我就没啥关系，对方对我语言又有些激烈的情况下）

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

@FunnyShadow 我不知道你有什么开发经验，我想请问你是从哪里看出来access token过期之后重新请求登录会被风控的，还是说你的参考文献就是大学生选修课论文里拿来凑数的？
请求登录本来就是必要的安全要求，是保证hmcl必须要在用户监督授权下才能访问数据，我想问临时登录要refresh token干嘛？巨硬会傻到因为这个封禁你？除了这么做没有更方便的办法保证用户隐私和安全，请问巨硬为何堵上这条路？找骂？（虽然骂也不少了）

就是说，有没有一种可能，我说了频繁二字？ 有人频繁调用你 API 你不对它进行一定限制，所有人都来使劲调你 API，得了，成 DDoS 了 就这 GitHub 你 API 调用频繁了还会给你来 ratelimit，你微软登录 API 就没了？ 哥们你没试过我可试过太多了，我们之前做微软 Azure 号的时候，这种账号成天被封，新号老号你调多了别的条件再可疑点直接翻车，你隔着儿跟我讲这个？

每小时调用一次如何定义为频繁？你的登录服务一个小时只能完成一次请求吗？请注意我说的实现是要把现在不检查过期时间的小bug修了的前提下说的

我不确定 HMCL 以及本 Issue 目前的情况以及目的是什么
按照我的理解，本 Issue 的核心目的在于不存储 refreshToken 或者 accessToken，仅将其用于本次启动游戏时登录，也就是说，如果重启一下 HMCL 就会导致登录失效
同时，HMCL 在默认情况下启动后是自动关闭窗口或进程的，也就是说，如果有一个玩家现在别人的电脑上，需要临时登录，同时也需要频繁重启游戏客户端，且不论其复杂程度，就请求数量这一点便算是频繁了罢？
虽然这种情况不属于常规情况，但也不属于一个很不常见的情况，我认为这应当算入用户预期行为

[zly2006]

按照我的理解，本 Issue 的核心目的在于不存储 refreshToken 或者 accessToken，仅将其用于本次启动游戏时登录

你的理解是错的，access token一个小时后就会过期，所以其实可以保存，实在介意可以选择在ms那里logout

也就是说，如果有一个玩家现在别人的电脑上，需要临时登录，同时也需要频繁重启游戏客户端，且不论其复杂程度，就请求数量这一点便算是频繁了罢？ 虽然这种情况不属于常规情况，但也不属于一个很不常见的情况，我认为这应当算入用户预期行为

绷，你手速多块才能达到rate limit？

[FunnyShadow]

RT，当勾选时，不保存 refreshToken，当第二次启动 HMCL 时就会弹出弹窗要求重新登录，这样可以以防账户被盗？

我不觉得我的理解有任何问题，原文里面就这么说的

同时 ratelimit 是一段时间内的累计总值，一般时间在 5~30 分钟之间动态变化，而且 ratelimit 的值也是动态变化的
而且风控系统这种东西判断条件很多，又不止是 ratelimit 这一条，如果你的 IP 地址本身就存在风险，这种限制可能会变得极为严格，再加上国内特殊的环境，部分玩家都会使用梯子来登录正版，异地频繁登录这一条直接就是高危风险，你怎么能确保不被风控？

如果你执意抬杠我觉得这讨论也没啥必要了，无论我给出什么证据你都会杠回来
而且此 Issue 也差不多快该结束了吧？HMCL 开发者那边也算是表示过了这东西不会做或者没法实现了，你可以自己去前面的 comment 里面翻一翻，黄鱼和 Glavo 都已经说过相关的事情了

[zly2006]

如果你执意抬杠我觉得这讨论也没啥必要了，无论我给出什么证据你都会杠回来 而且此 Issue 也差不多快该结束了吧？HMCL 开发者那边也算是表示过了这东西不会做或者没法实现了，你可以自己去前面的 comment 里面翻一翻，黄鱼和 Glavo 都已经说过相关的事情了

可以实现，issue的原话不一定是最终功能，而且频繁登录这个错误前提是谁提出来的我有点健忘记不清了

[zly2006]

算了，感觉这功能是真的没意思，谁想做自己参考吧 https://github.com/zly2006/HMCL/tree/temporary-login