0

在实施 OAUTH 时,我遇到了以下问题。在创建签名库时,应该再次编码编码参数还是应该在规范化参数时将编码参数排除在编码之外?

4

2 回答 2

0

当我阅读文档时,您似乎需要应用双重编码:

例如,HTTP 请求:

   POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
   Host: example.com
   Content-Type: application/x-www-form-urlencoded
   Authorization: OAuth realm="Example",
                  oauth_consumer_key="9djdj82h48djs9d2",
                  oauth_token="kkk9d7dh3k39sjv7",
                  oauth_signature_method="HMAC-SHA1",
                  oauth_timestamp="137131201",
                  oauth_nonce="7d8f3e4a",
                  oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

   c2&a3=2+q

包含签名基础字符串中使用的以下(完全解码的)参数:

           +------------------------+------------------+
           |          Name          |       Value      |
           +------------------------+------------------+
           |           b5           |       =%3D       |
           |           a3           |         a        |
           |           c@           |                  |
           |           a2           |        r b       |
           |   oauth_consumer_key   | 9djdj82h48djs9d2 |
           |       oauth_token      | kkk9d7dh3k39sjv7 |
           | oauth_signature_method |     HMAC-SHA1    |
           |     oauth_timestamp    |     137131201    |
           |       oauth_nonce      |     7d8f3e4a     |
           |           c2           |                  |
           |           a3           |        2 q       |
           +------------------------+------------------+

请注意,“b5”的值是“=%3D”而不是“==”。 "c@" 和 "c2" 都有空值。虽然本规范中为构建签名基本字符串而指定的编码规则不包括使用“+”字符(ASCII 代码 43)来表示编码的空格字符(ASCII 代码 32),但这种做法在“ application/x-www-form-urlencoded” 编码值,并且必须正确解码,如“a3”参数实例之一所示(“a3”参数在此请求中使用了两次)。

于 2012-08-28T07:25:17.537 回答
0

根据规范:https ://www.rfc-editor.org/rfc/rfc5849

每个级别的参数都被编码。

因此,每个 OAuth(不是正在创建的签名)和用户参数都被编码。

然后这些(领域除外)被加入到一个排序的参数列表中。

该字符串是 URL 编码的,并与 URL 编码的方法和 URL 编码的基本 URL 连接。

那是基本字符串,这是在散列之前的 2 级编码。

于 2019-01-19T03:05:30.263 回答