Twitter Oauth URL编码不一致? [英] Twitter Oauth URL encoding inconsistencies?

问题描述

我正在通过 http://dev.twitter.com/pages/auth <阅读演练/a>，但在对回调URL进行编码时似乎存在不一致.回调列为:
oauth_callback - http://localhost:3005/the_dance/process_callback?service_provider_id = 11

签名基本字符串列为:
POST& ... oauth_callback％3D http％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>"

在这里，回调似乎是单个URL编码的.他们为什么不一致?

解决方案

编码不是不一致的，只是在两种有两种不同要求的两种情况下使用了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 ...

I'm reading the walkthrough at http://dev.twitter.com/pages/auth but there seem to be an inconsistency in encoding the callback URL. The callback is listed as:
oauth_callback - http://localhost:3005/the_dance/process_callback?service_provider_id=11

The signature base string is listed as:
POST&...oauth_callback%3Dhttp%253A%252F%252Flocalhost%253A3005%252Fthe_dance%252Fprocess_callback%253Fservice_provider_id%253D11%26oauth_consumer_key%3D...

The callback appears to be double encoded here.

The signed Authorization header is listed as:
OAuth oauth_nonce="QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk", oauth_callback="http%3A%2F%2Flocalhost%3A3005%2Fthe_dance%2Fprocess_callback%3Fservice_provider_id%3D11", ...

Here, the callback appears to be single URL encoded. Why aren't they consistent?

解决方案

The encoding is not inconsistent, the URL is just being used in two different situations with two different requirements.

The URL starts off un-encoded in your app. The second example you posted is the value that will be passed to the server as a header, so it must be URL-encoded (that's once).

The signed Authorization header is listed as: OAuth oauth_nonce="QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk", oauth_callback="http%3A%2F%2Flocalhost%3A3005%2Fthe_dance%2Fprocess_callback%3Fservice_provider_id%3D11", ...

Then, the values of all of the OAuth header parameters must be combined with the other required values to create the base string for signing. The base string is created from the values as they are passed to the server. So you are taking the value you are passing to the server, your already-encoded URL, and combining it with other values, each of which must be URL encoded, to form a new string separated by &.

You can see why this must be done, as the third section of the base-string contains the query parameters which have values already URL encoded (like the oauth_callback) and uses & as a separator. In order to combine this query parameter list (containing &) into the base string safely (also using & as a separator), it must be URL encoded again before being concatenated. At this point the oauth_callback has been encoded twice, once on its own, and once as a part of a larger combined value:

The signature base string is listed as: POST&...oauth_callback%3Dhttp%253A%252F%252Flocalhost%253A3005%252Fthe_dance%252Fprocess_callback%253Fservice_provider_id%253D11%26oauth_consumer_key%3D...

这篇关于Twitter Oauth URL编码不一致?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！