哦对的，https 里引 http 不符合浏览器安全策略

nginx 配置 http 301 到 https 也可以吧，这样也不用改前端代码
server {
listen 80 default_server;
location / {
return 301 https://$host$request_uri;
}
}

也叫 ClientId 和 ClientSecret

比较常用的模式是 Authorization Code Grant，这种模式下，OAuth 服务的供应商会签发一对 AppId 和 AppSecret 给应用端，这两个东西是 OAuth 服务商校验 App 身份的一个手段，主要目的是为了防止冒充

@bayker 你的理解是不对的，你所说的密码模式是 Resource Owner Password Credentials Grant 么？这个模式下没有 AppId 和 AppClient （这意味着 OAuth 服务供应商无需校验应用端的可靠性，一般来说不会这样做，除非 OAuth 服务供应商完全信任应用端），这个模式下用户需要输入自己的登陆凭证（一般是用户名和密码）来交换 Token

你只需要保证 AppId、AppSecret 不被你和用户之外的第三方知道就可以了

这个 ID 和密钥因为你签发的，你当然需要知道，不然怎么校验防止冒充呢？我在想你是不是把用户的 Username Password Credential 和 AppId、AppSecret 弄混了...

Github 的 OAuth 你用过么？和你的场景几乎一样，你可以参考一下 https://github.com/settings/applications/new。AppId 和 AppSecret 是自动生成的，用户自己持有

有趣，挺有意思的

听起来是时间序列算法，顺祝各位中秋愉快

只要理解没有偏差，不存在反例，至少有 N/2 个一样的数

可以学一学刘慈欣

JD 贴错了吧

@dddddd 诚心请教，这种应该怎么写比较好？我理解那个 Throw 就是个 assert

这价格放 5 年前能买河西了

收藏了，比较喜欢把雨声调的比较小

不是很好看，而且 login2 的那个是想体现一个“拉”的动作么？个人觉得非常反直觉

那我也推荐一个 Backend 的路线图，拔高一下视野 https://github.com/kamranahmedse/developer-roadmap

运维这种可以用阿里的 ant-design-pro 之类现成的解决方案，里面的素材换一换，代码改一改不久行了么