这里有一个与@david 的部分范围界定工作相关的想法：我们可以创建一个严格限定于单个 RSS 订阅源的用户 API 密钥。这样一来，暴露面就会很小。在这种情况下，对于这种超范围限定的用户 API 密钥，我们可以允许其在不使用请求头的情况下进行认证（即在 user_api_key 表中增加一列，标记该密钥可用于通过 GET 请求进行认证）。
目前的挑战在于：
-
我们还没有让用户生成用户 API 密钥的机制。我们需要为 RSS 用例构建一些功能，这将涉及新的用户体验设计。我不确定应该将其添加在哪里，也许是在用户个人资料中，目前还不确定。
-
我们还没有将权限范围缩小到单个特定 RSS 订阅源的机制，这需要添加。
-
我们还没有用于“允许用户 API 密钥”的 URL GET 参数标志，而这是实现此功能所必需的。
总体而言，我认为这是我们可以解决的问题，但可能需要一到两周的时间才能将其完善。
有利的一面是，其中一些工作是我们无论如何都想做的，与 RSS 无关；但不利的一面是，部分工作与 RSS 紧密耦合，而如今使用此功能的人非常少。
具体如何优先处理，我想由@codinghorror 来决定。