"玩"猫的才不会给你领养, 得花钱.

尤其是那些到处喊着"爱猫"的那些.

XMR 不值钱, 算力又太低了

5900X 满功率才 十几 k

会"变成"盗版

@yazoox #4 llvm/clang 可解

@marcong95 #12 而且即使只接受 required 类型的, 他也是会"过段时间再问一次", 所以可以很确定他设置了对应的 cookie, 但是就是想通过这种方式强迫你 accept all

@marcong95 #9 问题是我只要不接受 analysis cookies, 就一直弹, 即使我接受了包括 functional 和 performance 在内的其他类型

法规规定

但是 Stack Exchange 之类的网站，如果你不 accept all，过段时间就会再问你一次，在手机上很烦

各 registry 的公开定价和代理商拿货价不一样, 然后一级代理商的公开定价和下级拿货价有差异

@dzdh #178 无法访问 和 我前面说的 安全问题 是完全两回事.

当然, 我避免使用反人类和小众的方式(包括对自己和对客户的开发者), 会避免使用自造轮子的方式去实作这些"精妙"的安全逻辑. 包括 mutual tls (前述, 这个对我服务器端 /API 网关端的实现存在不便)和类似支付宝的签名逻辑(这个对客户的开发者造成不便).

@dzdh #171 这个并不是单纯"客户端"的问题, 是客户端到服务端的链路问题. 这条链路上存在的风险, 按理说 API 提供方是要考虑的. 所以我前面说, 涉及资金的对外接口, 我会选择 RFC Draft 的 Http Message Signatures. 至于客户端这边被黑客入侵或者其他什么人登录导致密钥泄露, 才是和 API 提供方无关的东西.

登录凭据是"客户"有义务安全保管的, 但是服务本身的安全(包括从客户端到服务端的链路上的安全)是服务提供者的义务. (法律上一般也是这样认为的)

@dzdh 我说的是客户端, 或者说, 发起请求的一端. 这一端不存在"HTTP Gateway 负责认证"的情况, 如果你提供的 API 是 HTTPS 的, 那么客户端的代码请求必然是 HTTPS 的. 这种情况下, 客户端的"网关设备"(路由 /防火墙 /审计设备 /代理服务器等)存在作恶的可能性("那么这个环境就太恶劣了").

sublime 的项目区(目录树)不能通过插件自定义, 导致我用了一段时间 vscode 之后想换回去结果非常难受.

@dzdh 既然是网关的话, 完全可以解密后重新加密, 和 https cdn 是一样的逻辑.

虽然可以通过要求 Digest 头来验证 body 的 hash, 但是 Header 毕竟也可以一起改.

当然这属于极端情况了. 服务器的网关如果都不能被信任, 那么这个环境就太恶劣了.

鼓包导致屏幕顶起来, 我记得是额外维修计划来着.

S2 的表曾经过保后出现鼓包导致背壳掉下来, 拿去店里咨询直接给换了新的.

因前述"mutual tls 是站级设置, 不够灵活", 我会避免使用 tls client cert 认证.

通常情况下我选择使用 HTTPS + OAuth2. 如果有对外的资金等高安全需求的 API, 我选择增加额外的验证逻辑, 比如 Signing HTTP Messages (RFC Draft HttpBIS message signatures https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00).

@dzdh
确实, 要求 mutual tls 的场景不多

但是你说的第二条, "不必在 webserver 层处理" 并不能实现, 用 nginx 也好, 用语言自带的 http server 也罢, 要想要求客户端发送自己的证书信息, 必须在站级启用 client tls authentication, 这样就会直接影响同站下的所有路径.

当然我是支持"不用或少用 mutual tls authentication"的, 同时我也认为"签名"在现在的环境下不是保护接口安全"不二法门".

签名其实和一个短期有效的 token 没有本质上的区别, 只是可以在客户端自行生成.

当然, 签名的方式, 相对于 oauth2 之类的解决方案, 进一步降低了密钥泄露的可能性, 毕竟 oauth2 在获取 token 之前需要通过网络发送 client secret 给授权服务器.

api 安全, 需要必要的"冗余设计"来实现"失效可靠".

总之, api 安全 的 设计思路 就是

降低风险
失效可靠

比如站里曾经讨论过把 Google 的 oauth 密钥放在 app 端 还是 自己实现个 oauth 然后把相应密钥放在 app. 其实结论就是, 必须要暴露安全相关的敏感信息的话, 应当选择暴露泄露或失效后损失小的. (相比换 Google 的密钥, 换自己的更容易, 同时也能避免第三方系统被恶意用户直接操作)