Hex-Dragon
pcl储存的账户可能丢失
检查项
- [x] 我已在 Issues 页面 和 常见&难检反馈及问题列表 中搜索，确认了这一 Bug 未被提交过。
描述
假如浏览器登陆了a账号，在pcl尝试切换b账号时（两个都有正版），浏览器登陆时会跳转至a账号的登陆页面
登陆a账户后
先前pcl存在的b账户将会消失
重现步骤
如上
日志与附件
无需
这可能是微软的问题，微软会尝试自动使用之前已经登录过的账户…… 不过我只有一个账号，我这里也没法确认，谁能帮帮忙.jpg
微软登录会复用之前的会话数据（被这东西坑了好几次，总是登到没有许可的账号）
Author 的情况下应该是错误登录到 A 账号，因为名称变了，所以 B 账号就消失了，如果没有去重的话理论上会有两个 A 账号在可选列表内？（不太清楚）
Author 的情况下应该是错误登录到 A 账号，因为名称变了，所以 B 账号就消失了，如果没有去重的话理论上会有两个 A 账号在可选列表内？（不太清楚）
- https://github.com/Hex-Dragon/PCL2/issues/5919#issuecomment-2745275633
这可能是微软的问题，微软会尝试自动使用之前已经登录过的账户……
Microsoft 登录时，如果选择保持登陆状态（如下图），则会在下一次访问登录门户（login.live.com）时自动使用上一次登录且保持的账户，除非主动登出或 Cookie 被清除，否则这应当没有办法解决。
（登陆错误时）回来的是 A 账户的 Token，去重之后就只剩 A 账户了……
想了想，能匹配访问令牌吗？如果可以的话尝试做一下如果重新登录既有账户时回来了不匹配的令牌则提醒用户而不是直接覆盖数据？ 我重开再看看
（登陆错误时）回来的是 A 账户的 Token，去重之后就只剩 A 账户了……
想了想，能匹配访问令牌吗？如果可以的话尝试做一下如果重新登录既有账户时回来了不匹配的令牌则提醒用户而不是直接覆盖数据？
我觉得不是不行，毕竟这个问题容易把某些人搞迷糊（
（登陆错误时）回来的是 A 账户的 Token，去重之后就只剩 A 账户了……
想了想，能匹配访问令牌吗？如果可以的话尝试做一下如果重新登录既有账户时回来了不匹配的令牌则提醒用户而不是直接覆盖数据？ 我重开再看看
AccessToken 不能作为判断依据，因为 Mojang 可以签发内容不同的令牌
如果要判别，应该在 OAuth 过程中请求 openid 和 profile 权限，根据 ID 令牌编码的信息确定，或者通过 Minecraft 账号档案来进行判断
（登陆错误时）回来的是 A 账户的 Token，去重之后就只剩 A 账户了……
想了想，能匹配访问令牌吗？如果可以的话尝试做一下如果重新登录既有账户时回来了不匹配的令牌则提醒用户而不是直接覆盖数据？ 我重开再看看
AccessToken 不能作为判断依据，因为 Mojang 可以签发内容不同的令牌
如果要判别，应该在 OAuth 过程中请求 openid 和 profile 权限，根据 ID 令牌编码的信息确定，或者通过 Minecraft 账号档案来进行判断
refresh_token 怎么说。
refresh_token 怎么说。
RFC 6749 并没有规定授权服务器所签发的 AccessToken/RefreshToken 必须和上次所签发的相同，也没有规定具体格式，RFC 6749 要求客户端始终将上述令牌视为不透明的字符串，这也意味着授权令牌和刷新令牌所提供的信息 并不可靠，也不能保证令牌格式（这也意味着不能从上述令牌中解码信息），总之通过 OAuth 认证侧不能获取到任何有效信息
对于用户信息获取，我建议用 OpenID 规范 所提供的 IDToken（也就是上文提到的添加 openid 和 profile 权限，然后通过解码 IDToken 获取用户信息），因为 IDToken 格式必须是 JWT，或者附加 User.Read 然后使用 AccessToken 请求用户信息端点，亦或是通过 Minecraft Yggdrasil Server 获取玩家档案信息
refresh_token 怎么说。
RFC 6749 并没有规定授权服务器所签发的 AccessToken/RefreshToken 必须和上次所签发的相同，也没有规定具体格式，RFC 6749 要求客户端始终将上述令牌视为不透明的字符串，这也意味着授权令牌和刷新令牌所提供的信息 并不可靠，也不能保证令牌格式（这也意味着不能从上述令牌中解码信息），总之通过 OAuth 认证侧不能获取到任何有效信息
对于用户信息获取，我建议用 OpenID 规范 所提供的 IDToken，因为 IDToken 格式必须是 JWT，或者附加 User.Read 然后使用 AccessToken 请求用户信息端点，亦或是通过 Minecraft Yggdrasil Server 获取玩家档案信息
那么为什么必须通过解析 Token 获取信息而不是 API？就不能选中一个用户刷新一个用户？
那么为什么必须通过解析 Token 获取信息而不是 API？就不能选中一个用户刷新一个用户？
我在上文至少提出了三种方案，麻烦您仔细阅读，其中两种（请求用户信息端点和通过 Minecraft Yggdrasil Server）是 API 侧返回信息，OpenID 才是解码令牌
那么为什么必须通过解析 Token 获取信息而不是 API？就不能选中一个用户刷新一个用户？
我在上文至少提出了三种方案，麻烦您仔细阅读，其中两种（请求用户信息端点和通过 Minecraft Yggdrasil Server）是 API 侧返回信息，OpenID 才是解码令牌
那么目前看来请求 UUID 是最省事的。