AttributeError: 'PreparedRequest' object has no attribute 'data' about requests-oauthlib

[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://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.