插件中的 OAuth 使用者密钥
在将与/作为源代码分发的插件（例如访问 Delicious 或 Twitter 的 WordPress 插件）中处理 OAuth 消费者密钥的最佳方法是什么？我知道 OAuth 的设计并未考虑到这一点，并且有 解决该问题的建议，但目前最好的做法是什么？
似乎有两种方法可以实现这一点：
- 将您的消费者秘密放在源代码中（也许稍微混淆一下），并希望没有人会滥用它并禁止您的应用程序。如果有人这样做，请请求新密钥并发布软件更新。这是 Twitter 目前推荐的内容。
- 告诉每个人都获得自己的消费者密钥。这可能会让只知道如何安装插件的非开发人员感到困惑，并阻碍快速试用您的软件
是否有任何提供商可以帮助您自动化第二步？这样您的服务器就可以联系提供商并生成新的消费者秘密，该秘密以某种方式链接到您的应用程序，但仍然是唯一的？或者还有其他可行的方法吗？
What is the best way to handle consumer secret keys for OAuth in plugins that will be distributed with/as source code (e.g. Wordpress plugins that access Delicious or Twitter)? I know OAuth is not designed with this in mind, and there are proposals to solve it, but what is the best practice at this moment?
There seem to be two approaches to this:
- Put your consumer secret in the source code (maybe obfuscate it a little bit), and hope no-one will abuse it and get your app banned. If someone does, request a new key and issue an update to your software. This is what Twitter recommends for the moment.
- Tell everyone to get their own consumer key. This might confuse non-developers who just know how to install a plugin, and hinders a quick try-out of your software
Are there any providers that help you automate the second step? So that your server could contact the provider and generate a new consumer secret, that is somehow linked to your app, but still unique? Or are there other approaches that are feasible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
第三种选择是托管一个 Web 应用程序，充当您正在使用的任何 OAuth 服务的代理。您的所有 API 密钥均在您的服务器上由您控制。缺点是您需要花钱来保持机器运行。作为奖励，您可以收集一些有关插件使用情况的分析数据。
如果您认为您的用户有足够的技术能力来生成自己的 API 密钥，则可以选择第二种。我已经实现了这个方法，但支持起来很痛苦。
我不推荐第一种方法，因为人们可能会窃取您的 OAuth 密钥并冒充您的应用程序。一旦您的 API 密钥泄露，该服务将阻止您的 API 密钥，并且您的插件将停止工作。然后你会争先恐后地尝试升级一堆你无法再控制的代码。
A third option is to host a web application that acts as a proxy to whatever OAuth service you are using. All of your API keys stay under your control on your server. The downside is that you need to spend money to keep a machine running. As a bonus you can collect some analytics on the usage of your plugin.
Option two is possible if you think your users will be technical enough to generate their own API keys. I've implemented this method and it's a pain to support.
I don't recommend the first approach as people could steal your OAuth key and pretend to be your application. Once your API key is in the wild, the service will block your API key and your plugin will stop working. Then you'll scramble to try and upgrade a bunch of code that you don't have control of anymore.