@tmfeixiang123 #40 https://i.imgur.com/stQd8vN.jpeg 最下面的二维码

@tmfeixiang123 收费的小红圈还在发言，去微博上搜下这个 id 能找到小红圈的二维码。

推荐阅读这篇： https://zhuanlan.zhihu.com/p/35491200
TLDR：早期的现金贷公司月化利息都能搞到 60%，剥削的就是没能力还钱的这群人

推荐阅读这篇： https://zhuanlan.zhihu.com/p/35491200

@nathadai 淘宝花 98 换块电池。

Apple Watch 4 运行 watchOS10 不卡，耗电也就那么回事儿吧，都得一天一充。

支持一下

看下电池里面的统计，就知道啥原因了。

@chanChristin #5 再买一件回来，退上一单。

@Bigstupidcat 对我没影响，我睡得晚，1 点左右睡。

晚饭后一小时以上就可以了，一般 10 点左右。

可以试一下「还原所有设置」，这个不需要重装 App 。

@nobject #9 OIDC 只是一套协议，目前还有一套流行的协议叫 SAML2.0 。支持这两种协议的 SSO 服务，第三方接入会非常方便，因为有很多开源的 SDK 。

我觉得选车要先确定自己刚需的配置，比如 360 影像、座椅通风、HUD 之类。然后再根据自己的刚需进行过滤，就容易选了。

再回复下「那理论上在同一个浏览器下，访问 b.com 应该也是登录状态的。那这个登录状态是怎么判断呢？」。

答案非常简单，假设你的 oidc 的 provider 是在 oidc.com ，用户的登录态实际上是用的 oidc.com 的 cookie 来维持的。

a.com 和 b.com 进行 oidc 登录，会重新走一遍 oidc 的流程。a.com 和 b.com 的登录态各自维护，可以继续用 cookie + session ，也可以用 authorization 这种 header 的方式。

问题 2：都刷新，一块返回。和第一次登录区别不大，只是 grant_type 参数换成了 refresh_token 。
问题 3：不需要考虑的这么复杂，可以假设 a.com 和 b.com 的登录态依然是通过 cookie + session 来维护。a.com 登录之后，b.com 去访问 oidc 登录页面的时候，不会要求你输入用户名和密码，会直接跳转回 b.com 的 oidc 的 callback 。因为这个过程非常快，连续进行了几个 302 ，你会觉得好像登录 a.com 的时候，b.com 已经登录了一样，实际上依然是你访问 b.com 的时候才进行的登录。

Git 用 https 协议问题不大吧，抓包也只能看出你访问了 GitHub ，并不知道你是拉取还是推送。

之前一直依视路，换蔡司戴了快一年了，感觉体验区别不大，性价比不如依视路。