20 多岁的大好年华，可以做一些非同寻常、稀奇古怪、大胆冒险、不可理喻、疯狂愚蠢、无利可图、看起来与「成功」不沾边的事。在余生里，这些经历将成为你的灵感缪斯。

—— 凯文 · 凯利《宝贵的人生建议》

🌆 封面图：秋天的午后

咱们 HNU 图书馆真是古色古香！

🔐 切换到 Apple Passwords

iOS、iPadOS、macOS 的最新版本，将之前集成在系统里的密码管理器做成了独立的 App，功能已经比较完善，支持 OTP、Passkey 和完美的自动填充，iCloud 同步。

于是，本周我将主用的密码管理器从 BitWarden 换到了 Apple Passwords。

Apple Native 的 App 果然有最完美的用户体验。之前用的 BitWarden 的自动填充，是通过快捷键调用、脚本实现的，不仅没有输入框的 UI，也会出现填充错的情况。而使用 Apple 原生的 Passwords，在 Safari 里输入框旁边就会出现填充提示，简洁高效。（然而这种体验仅限于 Safari。在 Chrome 或 Firefox 里的 iCloud Passwords 插件体验还不如 BitWarden）

许多网站开启 2FA 后，要填写 OTP。用了 Passwords，Safari 居然支持自动填写（就像自动填写手机短信验证码一样）（当然，阿里云等少数网站不支持）。而之前 BitWarden 极其不优雅的做法是：自动填充密码后，将 OTP 放在剪切板里……

自动填充 OTP 是怎么实现的呢？原来，WHATWG HTML Living Standard 文档的 Autofilling form controls: the autocomplete attribute 这一部分定义了各种 autocomplete 形式，包含 one-time-code，即我们一般使用的六位 OTP。许多国内网站（如阿里云）表单没做这个属性，因此不支持。

还有一个神奇之处：Passwords 会检测你在不同站点使用的相同密码，并提示危险，会显示一个「Change Password」的按钮，点击即可直接进入该网站修改密码的页面。（当然，有的网站不支持，如阿里云 💢）

这是怎么做到的呢？网站如何约定「修改密码页面」呢？其实，Passwords 打开的是 https://example.com/.well-known/change-password 这个 URL。

💡 TWIL：网站的 Well-Known 目录

This Week I've Learnt:

一些应用需要获得某个站点的 metadata，例如用于搜索引擎爬虫的 robots.txt。越来越流行直接通过 HTTP 协议传递这种信息。而这意味着得约定一个路径存放这种信息。

因此，RFC 8615 定义了 Well-Known URI，即一个网站的 /.well-known/ 开头的路径：IETF RFC 8615 Defining Well-Known Uniform Resource Identifiers。

具体约定了哪些 Well-Known URI，则由文档中给出的 IANA Well-Known URIs Registry 登记收录。

常用的 Well-Known URI 有如下几个：

• /.well-known/change-password：修改密码的 URL。由 W3C A Well-Known URL for Changing Passwords 定义。
• /.well-known/security.txt：当研究人员发现网站漏洞时，该文件提供管理人员的联系方式。由 RFC 9116 定义。
• /.well-known/openid-configuration：用于公示 OpenID 相关的信息，一般返回一个 JSON，如 auth.skywt.cn/.well-known/openid-configuration。由 OpenID Connect Discovery 1.0 定义。
• /.well-known/acme-challenge：用于 ACME 质询。Caddy Server 会为我们自动配置这个路径。由 RFC 8555 定义。
• /.well-known/dnt-policy.txt：网站的 Do Not Track 政策。由 EFF's DNT Policy 定义。
• /.well-known/carddav 和 /.well-known/caldav：用于通讯录同步，Nextcloud 自带此功能。由 RFC 6764 定义。

没了解过这些通行的标准，你的网站就会和阿里云一样，不支持自动填充 OTP，不支持改密码！👀

📚 本周在读：《天生不同》，MBTI...