统一连接到 Gmail

这种可通过商业策略限制，比如改成订阅制

主要是没有动力去做，加上用户需求不大吧。
面向企业的，比如阿里云、腾讯云、百度云，都是支持的。
现在阿里云和腾讯云也支持 passkey 了，需要子用户（根用户不支持）。

Apple Care+
$79 一年，给我免费换了 $500+ 的屏

1. crypto.subtle 这个 API 其实出现很久了，但是主流的厂商并没有使用。我也不知道为啥，反正我是用了。具体的兼容性可以看 https://caniuse.com/cryptography

2. 这个 API 既有哈希算法，又有非对称/对称加密算法。个人其实还是推荐前端做 RSA 加密而不是直接把哈希给后端。这么做有两个原因：一是盐始终应该在服务器端随机生成且客户端不可知（这就排除了客户端生成或者使用用户名做盐的做法）；二是处于业务的需要，服务器是有必要知道用户的明文密码的，场景包括：
a. 在后端也应该过一遍密码强度检查，不可以直接信任用户的输入
b. 对常见易猜或已知泄露的密码进行检测并提示用户
c. 对密码进行敏感检查（我也不知道为啥有这个需求，但是新浪一直有这个机制）
d. 过滤密码中的不可显示字符和非 ASCII 字符（我是认为应该禁止用户使用非 ASCII 字符作为密码的——虽然会牺牲一定安全性，但是从业务的角度考虑，如果用户在一个设备上不小心输入了什么奇怪的字符、在另一个设备上输不进去了，搞不好会怪你——说到底还是业务和安全的 trade-off ）

3. 哈希算法的话，也是 argon2id 优于 PBKDF2 ，只是前者没有 FIPS 认证，对于需要安全认证的业务还是只能用 PBKDF2 。

全球经济都不好，都在降本增笑

推特倒是有，国内平台基本不做

村里曾经有一个大恶霸，垄断了全村的药物，村民都苦不堪言。有一天来了一个商队，向村民兜售被垄断的药物，村民们终于可以绕过大恶霸有了治病的机会，都很高兴。大恶霸却很生气，雇人杀害了这个商队。其他村的人没了商队，也再也买不到救命的药物，于是他们便开始怪罪这个村的人，是他们害死了商队。
但是真正的凶手大恶霸呢？

1. 从你的需求来看，你需要的是 DNS 服务商。域名商是你注册域名的地方，DNS 服务商是给你提供解析的地方。两个服务商可以是同一个，也可以是不同的。如果要用不同的，那么你需要修改 NS 记录（以及 DS 记录，如果支持 DNSSEC ）
2. 国内域名并不需要 BA ，但是都要实名
3. 主流的 DNS 服务商，包括：阿里、腾讯、谷歌（付费）、Azure （付费）、CloudFlare 、ClouDNS 、DigitalOcean ，全部支持 API ，也全部支持 OpenWRT 更新（ GoDaddy 其实也支持），也全部支持 AAAA 记录。

@PluginsWorld
1 、2 、3 、5：这个 ACME / 宝塔 / 1Panel 都能做到
4 、6： 这个 ACME 可以通过 hooks 做到，但是你如果能成功的通过产品简化用户的配置步骤，确实有意义

总之你仅仅做 API 是不够的，本质上是 acme 包一层壳，但是如果能给用户提供诸如可审计性、CT 日志、可观测性、可视化等等服务，对于 to B 来说还是有意义的

@lz4261 @Livid 使用 AI 生成的内容

Windows 下你其实可以用官方的 Python ，会自带一个 py.exe ，本身就是版本管理工具。比如 py -3.11 <script>.py 可以这样执行脚本
macOS 用 Homebrew ，也可以 Homebrew+pynev ，Homebrew 的 pyenv 可以配置切换成使用 Homebrew 预编译的 Python
Linux 上主流的应该还是 Pyenv ，但是你也可以选择在别的机器上（甚至 GitHub Actions 上）预先编译好然后打包，用的时候直接解压，我就写了一个仓库： https://github.com/baobao1270/pyenv-builds 如果你不放心可以自己 fork 仓库自己用 GitHub Action 编译

你这个相比 acme.sh / 宝塔 / 1Panel 有什么优势？

另外你需要注意 SOA 记录的 Serial 跳变问题。不同平台使用不同的 SOA Serial 时，Serial 可能会产生回溯，导致不可预期的故障

@pulelt 如果你没有开 DNSSEC 设置 DS 记录的话不用管
如果设置 DS 记录的话，因为 DNSKEY 在不同 NS Server 的 Private key 不同，所以会有不同的 DNSKEY ，导致 DS 验证哈希不知道找哪家验证，从而验证不通过。

如果使用 DNSSEC 的话，需要所有 DNS 服务商都支持 MulitSinger

买了一份试试，但是感觉这个价格有点贵了

@param 他需要通过 terminal 传输 Card number 和 CVV ，telnet 完全不加密你也不放心吧

用系统的密码管理方案。
Windows 有「凭据管理器」
macOS 有「钥匙串」
Linux……这个碎片化比较严重，不同的 DE 有不同的管理方案

@ysc3839
我自己的配置都是没有 HTTP ，只有 HTTPS 的。类似这样：
server {
listen 80 default_server;
listen [::]:80 default_server;

location / {
return 301 https://$host$request_uri;
}
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
}

这个时候只要管 HTTPS 就行了，不需要管两套配置增加心智负担。而且这样也不影响 ACME 验证，主流的 CA （ LE 、Google 、Zerossl ）都支持重定向的时候切换到 TLS-01 验证，而且不会管证书错误（只要域名对就行）