gpt4 book ai didi

Twitter Oauth URL 编码不一致?

转载 作者:行者123 更新时间:2023-12-02 16:07:29 26 4
gpt4 key购买 nike

我正在 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...

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

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

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

最佳答案

编码并非不一致,URL 只是用于两种不同的情况和两种不同的要求。

URL 在您的应用中一开始是未编码的。您发布的第二个示例是将作为 header 传递到服务器的值,因此它必须进行 URL 编码(一次)。

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", ...

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

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

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 编码不一致?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3283964/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com