与 twitter api 交互所需的密钥在哪里？答案

【问题标题】：Where are the keys needed to interface with the twitter api?与 twitter api 交互所需的密钥在哪里？
【发布时间】：2014-05-07 06:30:10
【问题描述】：

我想做的只是在我的 Web 应用程序的页脚中显示推文，但是我希望将来更多地将 twitter 与我的应用程序集成，所以我不想仅仅使用他们的小 jquery sn-p在页面顶部。但是，我在获取所需的密钥时遇到了巨大的困难，老实说，我真的很感谢一些行话的帮助。事实上，您必须创建一个 twitter 应用程序才能接收来自的推文该 api 对我来说完全陌生，我希望有人在下面澄清我需要做什么。

这是我认为应该如何做的列表，但请更新此列表，因为它似乎不适合我。假设我正在尝试为属于帐户awesome_kittens 的推文。

访问https://dev.twitter.com/ 并以awesome_kittens 登录
点击my_applications下拉菜单
点击create new app按钮
找到应用程序的consumer_key
找到应用程序的consumer_secret
找到应用程序的oauth_token
找到应用程序的oauth_secret
使用此信息连接到 api

我正在使用 Ruby on Rails，所以对于 第 8 步，我将创建一个初始化程序并执行以下操作：

Twitter.configure do |config|
  config.consumer_key = 'consumer_key'
  config.consumer_secret = 'consumer_secret'
  config.oauth_token = 'your_oauth_token_here'
  config.oauth_token_secret = 'your_oauth_token_secret_here'
end

对第 3 步感到困惑。我创建的应用程序是否神奇地链接到我的awesome_kittens 帐户？为什么我以awesome_kittens 登录时可以创建无限数量的不同应用程序，而我只想为awesome_kittens 创建一个？如何使应用程序链接到awesome_kittens？

完全被第 4、5、6 和 7 步难住了。我看了高低，在任何地方都找不到这些信息。没有在哪里。我能找到的唯一键是API key 和API secret。没有oauth的暗示。

我正在使用Twitter Gem。这是最适合这项工作的宝石吗？也许我希望我的 rails 应用程序能够在 awesome_kittens 帐户上发布推文？这里最好的工作是什么？

【问题讨论】：

API Key 是 Consumer Key，API Secret 是 Consumer Secret。

标签： ruby-on-rails twitter

【解决方案1】：

这是我对它的理解——你的应用程序需要有一组键来与 twitter 交互。

消费者密钥

这些键是在您使用 twitter 创建应用程序时设置的。这些是消费者密钥。

这些密钥将用于您的应用程序与 Twitter 的 API 交互。您的所有请求都将使用您的公钥和私钥进行签名。你永远不会暴露你的私钥——但你的公钥可能会被暴露。您可能不必担心细节，因为您使用的任何宝石都会处理细节。（内部有一个握手过程，如果它们是真正的握手，就会让你的手腕骨折）

OAuth 密钥

那么 oauth 令牌怎么样。 oauth 令牌密钥集使您的应用程序能够对 twitter 帐户执行操作。它可能是您用来设置使用者密钥的帐户。但它也可以很容易地成为另一个帐户。

将消费者密钥视为使您的应用程序能够与 twitter api 交互的密钥，并将 oauth 密钥视为使您的应用程序与您的 twitter 帐户进行交互的密钥。

多个 OAuth 密钥集

我知道这可能有点令人困惑——当您让应用程序的用户允许您的应用程序通过您的应用程序与 twitter 交互时，这可能更有意义。在这种情况下，会有许多 Oauth 密钥集——每一个都对应一个不同的 Twitter 帐户。

这有意义吗？

【讨论】：

【解决方案2】：

应用可以通过 2 种方式向 Twitter 进行身份验证（使用 oauth）：

纯应用验证。您只需要应用程序凭据，即上面的“consumer_key”和“consumer_secret”
应用程序内容中的最终用户身份验证。为此，您需要上述应用凭据以及应用内容中的用户凭据，即上面的 oauth_token 和 oauth_token_secret

如果您只想在应用程序上下文中调用，那么消费者密钥就足够了。您将受到每个应用程序的速率限制，并且无法访问未公开的用户数据。

使用用户令牌上下文，您将受到每个用户令牌的速率限制，如果您有多个用户并且需要进行比应用程序上下文速率限制所允许的更多的调用，这是可取的。这样您就可以访问私人用户数据。这将需要您构建一个工作流以在应用程序的上下文中获取用户令牌。

在您的情况下，目前使用 consumer_key 和 consumer_secret 的仅应用程序身份验证似乎就足够了。

【讨论】：