【问题标题】:Twitter Oauth URL encoding inconsistencies?Twitter Oauth URL 编码不一致?
【发布时间】:2010-07-21 01:58:31
【问题描述】:

我正在阅读http://dev.twitter.com/pages/auth 的演练,但在编码回调 URL 时似乎存在不一致。回调被列为:
oauth_callback - http://localhost:3005/the_dance/process_callback?service_provider_id=11

签名基本字符串如下:
POST&...oauth_callback%3Dhttp%253A%252F%252Flocalhost%253A3005%252Fthe_dance%252Fprocess_callback%253Fservice_provider_id%253D11%26oauth_consumer_key%3D...

这里的回调似乎是双重编码的。

已签名的授权标头列为:
OAuth oauth_nonce="QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk", oauth_callback="http%3A%2F%2Flocalhost%3A3005%2Fthe_dance%2Fprocess_callback%3Fservice_provider_id%3D11", ...

在这里,回调似乎是单个 URL 编码的。为什么它们不一致?

【问题讨论】:

    标签: twitter oauth url-encoding


    【解决方案1】:

    编码并没有不一致,URL只是在两种不同的情况下使用,两种不同的要求。

    网址在您的应用中开始时未编码。您发布的第二个示例是将作为标头传递给服务器的值,因此它必须是 URL 编码的(即一次)。

    签名的授权标头是 列为:OAuth oauth_nonce="QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk", oauth_callback="http%3A%2F%2Flocalhost%3A3005%2Fthe_dance%2Fprocess_callback%3Fservice_provider_id%3D11", ...

    然后,所有 OAuth 标头参数的值必须与其他必需的值组合以创建用于签名的基本字符串。基本字符串是根据值在传递到服务器时创建的。因此,您将传递给服务器的值、已经编码的 URL,并将其与其他值组合在一起,每个值都必须经过 URL 编码,以形成一个由& 分隔的新字符串。

    您可以看到为什么必须这样做,因为基本字符串的第三部分包含已具有 URL 编码的值的查询参数(如 oauth_callback)并使用 & 作为分隔符。为了将这个查询参数列表(包含&)安全地组合到基本字符串中(也使用&作为分隔符),它必须在连接之前再次进行URL编码。此时oauth_callback 已被编码两次,一次单独编码,一次作为更大组合值的一部分:

    列出了签名基字符串 作为: POST&...oauth_callback%3Dhttp%253A%252F%252Flocalhost%253A3005%252Fthe_dance%252Fprocess_callback%253Fservice_provider_id%253D11%26oauth_consumer_key%3D...

    【讨论】:

      猜你喜欢
      • 2010-12-26
      • 2015-09-16
      • 2023-04-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-04-12
      • 2016-04-29
      • 1970-01-01
      相关资源
      最近更新 更多