requests / requests-oauthlib

OAuthlib support for Python-Requests!
https://requests-oauthlib.readthedocs.org/
ISC License
1.72k stars 423 forks source link

Cannot exclude a param from OAuth signature (flickr file upload) #62

Open dargad opened 11 years ago

dargad commented 11 years ago

Flickr API for file uploading (http://www.flickr.com/services/api/upload.api.html) uses a tricky approach: they require a single POST parameter photo and support some optional params.

The tricky part is that this photo parameter needs to be excluded from the OAuth signature, while all the other params (the optional ones) should be included in it (as explained under the link above).

Is it possible to exclude some parameters from including in the signature using requests-oauthlib?

ib-lundgren commented 11 years ago

This is indeed curious behaviour and a great example of the real reason OAuth 1 is a bit of a mess (trying to recreate SSL). Flickr are essentially extending the OAuth RFC, which does not cover protection of body parameters in multi part requests. What they are doing does not add a whole lot of value as it does not protect the binary blob (photo) itself.

There is currently no support for this in requests-oauthlib. It can be worked around but not very cleanly. What you would need to do is use the OAuth1 auth client (requests_oauthlib.OAuth1) and create one prepared request and one real request. Something a long the lines of

import requests
import requests_oauthlib
flickr = 'http://up.flickr.com/services/upload/'
client = requests_oauthlib.OAuth1('your_client_key', ....)
data = { 'title': 'sometitle', 'description': '...'}
raw = requests.Request('POST', flickr, data=data, auth=client)
prepared = raw.prepare()
auth = {'Authorization': prepared.headers.get('Authorization')}
requests.post(flickr, data=data, headers=auth, files=(('photo', '/home/you/photo.jpg'),))

but I've not tested whether this works.

dargad commented 11 years ago

The workaround works as expected, thanks!

ib-lundgren commented 11 years ago

Don't think this is a common enough case to be included in the library but a good candidate for inclusion in the documentation. Labelling docs for now and will close when its featured in the docs somewhere. cc #48