V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  chinvo  ›  全部回复第 9 页 / 共 210 页
回复总数  4190
1 ... 5  6  7  8  9  10  11  12  13  14 ... 210  
2021-04-21 16:45:55 +08:00
回复了 xiaohantx 创建的主题 杭州 有小猫猫可以领养嘛
"玩"猫的才不会给你领养, 得花钱.

尤其是那些到处喊着"爱猫"的那些.
2021-04-21 16:01:06 +08:00
回复了 um1ng 创建的主题 问与答 有大佬玩挖矿的吗? XMR 感觉用 CPU 挖,门槛要低一些啊
XMR 不值钱, 算力又太低了

5900X 满功率才 十几 k
2021-04-20 23:06:42 +08:00
回复了 caliburn1994 创建的主题 问与答 Jetbrains 合租会怎么样呀?
会"变成"盗版
2021-04-20 17:14:20 +08:00
回复了 b00tyhunt3r 创建的主题 程序员 c++ 20 有人正经用起来了吗?谈谈感受啊
@yazoox #4 llvm/clang 可解
@marcong95 #12 而且即使只接受 required 类型的, 他也是会"过段时间再问一次", 所以可以很确定他设置了对应的 cookie, 但是就是想通过这种方式强迫你 accept all
@marcong95 #9 问题是我只要不接受 analysis cookies, 就一直弹, 即使我接受了包括 functional 和 performance 在内的其他类型
法规规定

但是 Stack Exchange 之类的网站,如果你不 accept all,过段时间就会再问你一次,在手机上很烦
各 registry 的公开定价和代理商拿货价不一样, 然后一级代理商的公开定价和下级拿货价有差异
2021-04-14 03:03:51 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh #178 无法访问 和 我前面说的 安全问题 是完全两回事.
2021-04-14 01:02:01 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
当然, 我避免使用反人类和小众的方式(包括对自己和对客户的开发者), 会避免使用自造轮子的方式去实作这些"精妙"的安全逻辑. 包括 mutual tls (前述, 这个对我服务器端 /API 网关端的实现存在不便)和类似支付宝的签名逻辑(这个对客户的开发者造成不便).
2021-04-14 00:58:46 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh #171 这个并不是单纯"客户端"的问题, 是客户端到服务端的链路问题. 这条链路上存在的风险, 按理说 API 提供方是要考虑的. 所以我前面说, 涉及资金的对外接口, 我会选择 RFC Draft 的 Http Message Signatures. 至于客户端这边被黑客入侵或者其他什么人登录导致密钥泄露, 才是和 API 提供方无关的东西.

登录凭据是"客户"有义务安全保管的, 但是服务本身的安全(包括从客户端到服务端的链路上的安全)是服务提供者的义务. (法律上一般也是这样认为的)
2021-04-14 00:51:13 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh 我说的是客户端, 或者说, 发起请求的一端. 这一端不存在"HTTP Gateway 负责认证"的情况, 如果你提供的 API 是 HTTPS 的, 那么客户端的代码请求必然是 HTTPS 的. 这种情况下, 客户端的"网关设备"(路由 /防火墙 /审计设备 /代理服务器等)存在作恶的可能性("那么这个环境就太恶劣了").
2021-04-14 00:48:54 +08:00
回复了 qiutian00 创建的主题 Sublime Text sublime 用的人还多么?
sublime 的项目区(目录树)不能通过插件自定义, 导致我用了一段时间 vscode 之后想换回去结果非常难受.
2021-04-14 00:42:06 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh 既然是网关的话, 完全可以解密后重新加密, 和 https cdn 是一样的逻辑.

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

当然这属于极端情况了. 服务器的网关如果都不能被信任, 那么这个环境就太恶劣了.
2021-04-14 00:37:13 +08:00
回复了 toivo191 创建的主题  WATCH 初代 watch 电池鼓包,有必要 AppleStore 换新吗?
鼓包导致屏幕顶起来, 我记得是额外维修计划来着.

S2 的表曾经过保后出现鼓包导致背壳掉下来, 拿去店里咨询直接给换了新的.
2021-04-14 00:33:10 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
因前述"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).
2021-04-14 00:27:58 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh
确实, 要求 mutual tls 的场景不多

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

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

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

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

api 安全, 需要必要的"冗余设计"来实现"失效可靠".
2021-04-14 00:17:28 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
总之, api 安全 的 设计思路 就是

降低风险
失效可靠

比如站里曾经讨论过把 Google 的 oauth 密钥放在 app 端 还是 自己实现个 oauth 然后把相应密钥放在 app. 其实结论就是, 必须要暴露安全相关的敏感信息的话, 应当选择暴露泄露或失效后损失小的. (相比换 Google 的密钥, 换自己的更容易, 同时也能避免第三方系统被恶意用户直接操作)
2021-04-14 00:13:24 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
另外有一些系统不方便进行 mutual tls authentication, 因为 mutual tls authentication 是站级的, 不能对不同路径单独设置. (确实有相关实现可以区分路径设置 mutual tls, 但是这种行为是不标准的, 对不同的 客户端 /服务器 /代理 实现可能有不同表现)

RFC8446 section-4.6.2 定义了类似行为, 但是目前未被任何 HTTP 协议草案包含在内 (甚至被 HTTP/2 草案禁止: RFC8740 section-3).
1 ... 5  6  7  8  9  10  11  12  13  14 ... 210  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5782 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 51ms · UTC 06:13 · PVG 14:13 · LAX 23:13 · JFK 02:13
Developed with CodeLauncher
♥ Do have faith in what you're doing.