HMCL-dev
[Feature] 微软账户登录添加《临时登录》选项
描述 | Description
RT，当勾选时，不保存 refreshToken，当第二次启动 HMCL 时就会弹出弹窗要求重新登录，这样可以以防账户被盗？
但缺点也如此，第二次启动 HMCL 时，登录微软账户阶段会使用 refreshToken 刷新 accessToken，无论 accessToken 是否过期，这个可能需要优化下？
原因 | Reason
这样可以以防账户被盗？
这会导致频繁的重新登录的，根据 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
这会导致频繁的重新登录的，根据 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 那差不多直接算把你号盗了
这会导致频繁的重新登录的，根据 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 导致不被受理乃至完全销号）
甚至可能适得其反，在没有被人盗号的情况下被系统误判为存在风险，自动做出某些防止盗号的行为
这会导致频繁的重新登录的，根据 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 导致不被受理乃至完全销号）
我觉得应该不会有人在短时间内频繁登录吧（
这会导致频繁的重新登录的，根据 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 的话，这在微软的风控系统看来就算是频繁登录了）
而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能
而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的
accessToken和refreshToken失效的，采用应用验证登录方式的启动器都有这个功能
HMCL因为是开源的，加密了等于没加密。黄鱼说的（
而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的
accessToken和refreshToken失效的，采用应用验证登录方式的启动器都有这个功能
这样的话，所有使用了此账号的 HMCL 在尝试进行一次新的启动（乃至游戏内）都会被强行要求重新登录（游戏内应当会提示会话失效，并要求重新启动游戏或重启启动器）
而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的
accessToken和refreshToken失效的，采用应用验证登录方式的启动器都有这个功能HMCL因为是开源的，加密了等于没加密。黄鱼说的（
每个系统单独生成一个加密密钥不就好了）））
加密算法可以是开源的，但是密钥不一定得是啊）
就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的 refreshToken 进行加密存储，需要时在利用这个加密密钥进行解密
这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个 refreshToken
那我觉得可以在使用 refreshToken 前先检验 accessToken 是否有效，如果失效了才进行刷新，所以我说如果加入这个功能就要把刷新机制调整下。
那我觉得可以在使用
refreshToken前先检验accessToken是否有效，如果失效了才进行刷新，所以我说如果加入这个功能就要把刷新机制调整下。
true，不过我还是建议先把 refreshToken 这种东西加密存储起来，不然仅仅只是 HMCL 这里做了一个判断，有心人还是可以从HMCL 的数据存储中找到 refreshToken
而且最好是加一个必须是官方构建这套加解密功能才能起效的东西，这种东西验证逻辑应该是比较简单的（指对 accessToken 验证是否有效的逻辑），否则如果有人已经被盗号，号主吊销了 accessToken，但是这个人利用一份修改版就可以变相绕开这个限制，直接解密得到 refreshToken
加密算法可以是开源的，但是密钥不一定得是啊）
就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的
refreshToken进行加密存储，需要时在利用这个加密密钥进行解密这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个
refreshToken
https://github.com/huanghongxun/HMCL/issues/107#issuecomment-279193675 https://github.com/huanghongxun/HMCL/issues/107#issuecomment-279344793
代码是开源的，加密有用？
不公开是不可能的，Java反编译随时都可以知道代码
加密算法可以是开源的，但是密钥不一定得是啊） 就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的
refreshToken进行加密存储，需要时在利用这个加密密钥进行解密 这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个refreshToken#107 (comment) #107 (comment) 代码是开源的，加密有用？ 不公开是不可能的，Java反编译随时都可以知道代码
我对此表示怀疑态度）
加密算法大多也都是开源的（诸如 RSA 与 DSA 等），他们的加密原理都是众所周知的，但这并没有导致什么问题
加密的算法是所有人都知道的，代码也是，但是加密的密钥除非被泄漏，没有人能知道，只需要在第一次启动时生成密钥即可
不然你说像 AuthMe 这种登录插件怎么给密码加密的，他们也是完全开源的）
那，加密的密钥存哪
可以让用户自行决定，比如让他们自己生成 PGP 密钥或者自己选择保存位置，或者直接调用系统的 （Windows 的我不太清楚，Linux 的桌面环境有专门的 PGP 密钥保管库）
或者去看看别的一些需要加密但是开源的工具也不是不行）
算是个大工程了吧， Glavo 当时尝试搞过但没弄好，就弄个了全局账户和便携账户
这种东西确实不算很简单（至少我的技术力实现不了），但是也不应该算是一个很难搞的东西
加密库都是现成的，直接引用就好了，使用教程网上应该也是一抓一大把，毕竟加密存储账户信息这个东西也不算是很冷门）
我觉得这个东西应该去麻将官网使劲骂，这种东西完全是官方自己没做好的锅
据我了解，全球搞 Minecraft accessToken 加密的启动器总共就没几个，这也是为什么偷 refreshToken 的病毒会如此泛滥的原因
不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象
目前 HMCL 也是直接塞到一个 json 文件（
不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象
目前 HMCL 也是直接塞到一个 json 文件（
HMCL 是为了符合官方标准，如果官方都重视，那自然也就没这么多事了） 所以 F**K U SHITJUMP
目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？
目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？
赞成
目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？
我觉得这样可以在一定程度上防止恶意盗号
据我了解，全球搞 Minecraft accessToken 加密的启动器总共就没几个，这也是为什么偷 refreshToken 的病毒会如此泛滥的原因
这个真救不了 退一万步说，如果你的电脑真中病毒了，那我直接感染 HMCL 本体，给启动的命令后面加上一个把 Token 写入特定文件的逻辑，不就拿到解密后的 Token 了……
加密能，且仅能拯救的是意外把带有微软便携账户的 HMCL.json 发给别人的情况，对于中病毒这种，没招
这个功能还是有用的 对于网吧等不安全地方，这个可以降低盗号风险。
如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题
只是不保存到本地，在hmcl的生命周期里面依旧是存在的。在网吧这类环境中基本上hmcl只启动一遍，不会出现频繁关闭和启动hmcl这样的过程。
