Twitter的流式API能否安全地部署到客户端？

我正在尝试开发一个开源解决方案，它将部署在Raspberry Pi或类似的SBC上。RPi部分仅在意味着所有代码和应用程序资源都需要公开时才相关

解决方案需要尽可能接近实时地读取Twitter状态，并且尽可能少地受到第三方的干扰。我发现Twitter的流式API非常快，非常适合我的应用程序——除非它需要OAuth。据我所知，OAuth机制并不适合部署在用户的机器上，因为它依赖于属于应用程序所有者的密钥——消费者密钥

我找不到任何简单的方法来解决这个问题——我能想到的唯一解决方案是在中央服务器上处理请求签名，或者要求每个用户创建自己的Twitter应用程序帐户。我觉得这两种解决方案都非常令人讨厌

---

你觉得有什么好办法吗？

你的应用程序可以打开一个web浏览器，并加载Twitter的应用程序验证网页。当用户输入他们的凭据时，Twitter将返回一个代码，他们可以将该代码复制/粘贴到您的应用程序中。它不是特别优雅。这里是一个Python工作流示例：

事实证明，这在Twitter的任何公共API中都是不可行的；现在不行，在可预见的将来也不行。令人耳目一新的是，这一次我们确实有了否定的证据：我也在Twitter自己的论坛上问了这个问题，我很幸运地得到了Twitter全球首席开发人员倡导者Andy Piper的友好回答

正如我在OP中所说的，OAuth依赖于一个属于应用程序所有者的密钥，即使用者密钥。您引用的示例需要我在上分享，因为代码最终会出现在人们的计算机上。这是一个很大的禁忌，请参阅获取签名密钥一节。编译密钥并将其硬编码到应用程序中。如果你没有使用编译语言，我想你是运气不好。我没有使用编译语言。我可以编译一个客户端微应用程序，只用于签名请求，我不希望有任何性能损失，但不管你怎么看，在客户端部署密钥都是不好的做法。你回答了自己的问题。您可以以尽可能安全的方式部署机密，也可以在服务器上保留机密并从那里执行所有流式处理。我自己根据场景使用这两种方法。对于前者，我认为编译使用者密钥/密码并要求用户使用其凭据进行身份验证没有任何错误。我一点也不反对。这就是为什么通常的解决方案是在后端服务器上处理这个问题。但你说这很恶心。这当然不是小事。祝你好运