Python OAuth签名问题

我正在尝试使用python和rauth库来连接intuit合作伙伴平台上的QBO api，并且我基本上已经让它正常工作了。但是，我在发送请求时经常出错：

Exception authenticating OAuth; errorCode=003200; statusCode=401

失败时，此消息也位于响应标头中：

WWW-Authenticate: OAuth oauth_problem="signature_invalid"

错误代码表明请求没有正确签名，但我正在使用标准oauth库对数据进行自动签名，并且大约有一半的时间可以正常工作。我的连接代码如下：

if method is 'post':
    headers = {}
        if action in ['create', 'update', 'delete']:
            headers['Content-Type'] = 'application/xml'
        r = self.session.post(url, data=data, headers=headers, params=params, header_auth=True)
else:
    r = self.session.get(url, params=params, header_auth=True)

其中self.session是rauth.oauth1会话

生成的请求示例如下：

GET /resource/customer/v2/682571780/1 HTTP/1.1
Host: qbo.sbfinance.intuit.com
Accept: */*
Content-Length: 0
Accept-Encoding: gzip, deflate, compress
authorization: OAuth realm="",oauth_nonce="d577f23920c96f8ee79eff6588c83c9ebf65cf20",oauth_timestamp="1366147949",oauth_consumer_key="qyprdCFOHBypPTK8XX0g8N4bZ8ceVA",oauth_signature_method="HMAC-SHA1",oauth_version="1.0",oauth_token="qyprdp9p7diRBIt11In225OOGRzcgl9o4DsQRJduHJFP09gY",oauth_signature="w5V3u2ATnj/rDc9vFD7inr8MO6I%3D"
User-Agent: python-requests/1.1.0 CPython/2.7.3 Linux/3.5.0-17-generic

这是劳思图书馆的问题吗？我是否遗漏了一个使其更稳定的参数？

劳思作者：

“错误代码表示请求未正确签名…”

实际上，这并不一定是真的：它确实表明提供者无法验证请求，并且表明签名不正确。但这也可能意味着签名丢失（顺便说一句，这在技术上是不正确的）。我会尝试将

header\u auth

设置为

False

。这是一个常见的问题，提供者不准备处理基于头的身份验证，然后会令人困惑地返回一个签名无效错误

另外，您提到您正在使用一个库来自动签署请求，这是rauth之外的库吗？如果是这样的话，我强烈建议不要这样做：劳思是独立的，为你做签约。您应该避免将其与其他OAuth库组合

---

最后，如果您仍然有问题，请随时直接联系我或在上打开一个问题。

好的，我的问题的完整解决方案需要两个更改：

在某些情况下，我传递的

params

对象在请求之间被保留，但显然在设置请求时被破坏性地修改。这意味着oauth参数包含在下一个请求中，这会以某种方式干扰rauth的设置

我注意到的唯一区别是参数的顺序不同，但有可能oauth参数被视为签名内容的一部分，然后在生成签名后被覆盖，从而使签名无效。不管是什么原因，这次改变修复了我90%的失败

按照maxcountryman的建议，将

header\u auth

重置回

False

。尽管声明将身份验证放在头中，但显然这并不总是有效的。使用此设置时的错误率仅为10%左右，但如果没有此设置，则不会再出现任何签名错误

---

“…但是我正在使用一个标准的oauth库来自动为数据签名”你不是在和rauth签名吗？请解释你的意思。不，当我提到“库”时，我的意思是使用rauth而不是自定义签名代码。提到的库是rauth；请求的创建与帖子中的创建完全相同。另外，根据，他们更喜欢将oauth信息放在标题中。然而，删除header_auth确实提高了稳定性。听起来，他们可能没有正确地实现header auth。您的参数问题可能与使用可变类型有关。如果没有更具体的代码示例和适当的回溯，很难说得更进一步。是的，我传入了一个可变字典，并在多个请求中重用了同一个字典，这导致了问题。如果传入的params dict没有像那样进行破坏性修改可能会更好，但一旦我发现这是一个问题，修复就很容易了。它没有被破坏性修改，我想你会感到困惑：它的处理方式与请求处理

params

和

数据的处理方式相同；这些各自的dict都是以非破坏性的方式更新的，当然可选的OAuth参数除外。我说破坏性修改是因为相同的dict作为副作用被更新了。在我看来，一个非破坏性的操作会创建一个带有更新的新对象，而不是更改旧对象。然而，关于术语的争论没有多大意义。每次传入一个新的dict都会修复问题，看起来您在几天前添加了一个自动修复程序。