AttributeError: 'PreparedRequest' object has no attribute 'data'

[michaelhelmick]

@Lukasa asked me to raise this error in this repo as well:

Hey guys, just wanted to bring this issue forward. With requests 1.0.0
So the error came from when I went to test Twython with the new requests release.

And because it bothered me, I removed self from all variables that used self like self.callback_url
Also, I striped the code out of the actual function get_authentication_tokens (so that's why you'll see ref to that function in the traceback)

import requests
from requests_oauthlib import OAuth1

app_key = u'SUPERDUPERSECRETKEY'
app_secret = u'SUPERDUPERSECRETSECRET'

callback_url = 'https://example.com'
headers = {'User-Agent': 'Twython v2.5.5'}
auth = OAuth1(app_key, app_secret,
                               signature_type='auth_header')

request_args['oauth_callback'] = callback_url
response = requests.get('https://api.twitter.com/oauth/request_token', params=request_args, headers=headers, auth=auth)

if response.status_code != 200:
    raise TwythonAuthError("Seems something couldn't be verified with your OAuth junk. Error: %s, Message: %s" % (response.status_code, response.content))

request_tokens = dict(parse_qsl(response.content))
if not request_tokens:
    raise TwythonError('Unable to decode request tokens.')

oauth_callback_confirmed = request_tokens.get('oauth_callback_confirmed') == 'true'

auth_url_params = {
    'oauth_token': request_tokens['oauth_token'],
}

# Use old-style callback argument if server didn't accept new-style
if callback_url and not oauth_callback_confirmed:
    auth_url_params['oauth_callback'] = callback_url

request_tokens['auth_url'] = 'https://api.twitter.com/oauth/authenticate?' + urllib.urlencode(auth_url_params)

return request_tokens

Anyways, when I try to run this code I get the error:

Traceback (most recent call last):
  File "twython.py", line 585, in <module>
    auth_props = t.get_authentication_tokens()
  File "twython.py", line 271, in get_authentication_tokens
    response = requests.get('https://api.twitter.com/oauth/request_token', params=request_args, headers=headers, auth=self.auth)
  File "/Users/mikehelmick/.virtualenv/twython/lib/python2.7/site-packages/requests/api.py", line 49, in get
    return request('get', url, **kwargs)
  File "/Users/mikehelmick/.virtualenv/twython/lib/python2.7/site-packages/requests/api.py", line 38, in request
    return session.request(method=method, url=url, **kwargs)
  File "/Users/mikehelmick/.virtualenv/twython/lib/python2.7/site-packages/requests/sessions.py", line 253, in request
    prep = req.prepare()
  File "/Users/mikehelmick/.virtualenv/twython/lib/python2.7/site-packages/requests/models.py", line 200, in prepare
    p.prepare_auth(self.auth)
  File "/Users/mikehelmick/.virtualenv/twython/lib/python2.7/site-packages/requests/models.py", line 336, in prepare_auth
    r = auth(self)
  File "/Users/mikehelmick/.virtualenv/twython/lib/python2.7/site-packages/requests_oauthlib/core.py", line 41, in __call__
    decoded_body = extract_params(r.data)
AttributeError: 'PreparedRequest' object has no attribute 'data'

[kracekumar]

Yes, there isn't data, so replace line41 of requests_oauthlib/core.py with decoded_body = extract_params(r.body)
and replace line 50 with if hasattr(r, 'files') and contenttype == CONTENT_TYPE_MULTI_PART: and then code should raise

raise TwythonAuthError("Seems something couldn't be verified with your OAuth junk. Error: %s, Message: %s" % (response.status_code, response.content))

[Lukasa]

Pull Request? =D

[kracekumar]

@Lukasa sure 👍

[ib-lundgren]

I'm so not keeping up with the times. Just noticed randomly that this was split into it's own repo and broken with the requests refactoring while I was debugging some old code. I quick-fixed it in passing locally and was just about to add an issue here to remember to one day clean it up and push it. Lo and behold you guys are already on it. I love open source =)

hasattr(r, 'files') will however cause trouble since r in this case is a PreparedRequest without that attribute. If the prepare_auth was moved to after prepare_body (https://github.com/kennethreitz/requests/blob/master/requests/models.py#L201) then it would probably be fine just omitting the files check as the content type should be set.

I've not tested any multipart data yet tho so might be mistaken, I'll dig deeper later this week if none else beats me to it.

[Lukasa]

Please get back to us with the result of your investigation. In the absence of good tests for this code, we need as much user feedback as possible. =)

[ib-lundgren]

Well the reason the files check was there in the first place was because of the internal order of things in pre-1.0 requests where the content type was not always set, especially not before the auth call. The only thing this extension needs to do is to sort out some unicode issues (or else stuff will break deep down in other libraries, or so it used to) and help figure out content-type if not set.

I'll try and crave an hour or two out of tomorrow and add some tests for this. Anyone know if there is a particular reason for prepare_body coming after prepare_auth? If not that's a good place to start making life easier for content-type guessing.

Oh btw, and there is no full_url anymore, just url.

[Lukasa]

This library has had only one change to bring it up to date with v1 of Requests, and that was #3. I'm spread way too thin to get around to this any time soon, so any help you can provide would be awesome. =)

[ib-lundgren]

decoded_body and r.body being None under certain circumstances might also cause grief. I'll need to update myself a bit on how things are meant to be done with the new requests structure then patch it. That might take a day or two so don't hesitate to beat me to it...

[ib-lundgren]

Know the feeling =) I'll try and sort it out either here or on oauthlibs side this week.

[ib-lundgren]

Threw together some quick fixes in #4.

[mikofski]

I am so stupid! I have been beating my head against the wall because of this for at least an hour and a half!

Please push a new tag and update pypi. Thanks.

Until then, does anyone think the current master is ready for prime time?

[michaelhelmick]

@mikofski requests-oauthlib master is update-to-date with this change. requests, I believe, is awaiting the changes to make this all working. See #4 (comment)

[ib-lundgren]

Master works fine and you can see an example flask-twitter use here https://gist.github.com/4487236

Requests has pushed the change and it is included in at least 1.0.4. requests-oauthlib however needs to push master.

Note that you still need to provide all input in unicode. After oauthlib pushes 0.4 this will no longer be necessary if your input is utf-8 encoded. However, before I push I need to do some further testing. I'll ping this issue when done.

[mikofski]

Thanks @ib-lundgren & @michaelhelmick! I did ...

pip install -U git+git:https://github.com/requests/requests-oauthlib.git

which updated me to master and now all is well!

[estebistec]

was this included in a release? I'm seeing this issue now with req 1.2.0 and req-oauthlib 0.3.0

[ib-lundgren]

It was included and is for certain in 0.3. Make sure that is really the version you are using as I'm unable to replicate this. If it persists please provide a stack trace / code sample.

[estebistec]

16:42:42 # pip freeze -l | grep requests
requests==1.2.0
requests-oauthlib==0.3.0

[estebistec]

sorry, I'll come back with a good sample replicating it soon but time doesn't allow at the moment. :/ I'll try to distill it down tomorrow.

[ib-lundgren]

No worries. One thing that might help you is if you try and setup a new virtualenv and see if you still have the same error.

virtualenv test
source test/bin/activate
pip install requests-oauthlib
# try your code

[estebistec]

Okay, I see what's going on. It's intentional that data was going away and the preferred attribute is truly body. This pull request doesn't put the data attribute back, it updates requests-oauthlib to not rely on it. We were introspecting response.requests trying to build better error logs. Looks like we'll need to update our code accordingly. Thanks.