oauth post does not work

Since requests can be attached with an auth method, and there is oauth files in the package, so we can pass auth method to requests in order to archive auto auth function.
However, the code of oauth is conflicting with current trunk code.
Let's see
https://github.com/kennethreitz/requests/blob/develop/requests/models.py#L535
So if i pass in a dict object as post data, content-type will be set automatically.
Then see here
https://github.com/kennethreitz/requests/blob/develop/requests/auth.py#L81
If content-type is set, oauth won't work! It expects signing will be executed by manual operation!
Let's summarize all things:
Content-Type is set for the existence of non-plain dict object, oauth rejects to work for the existence of content-type.
WTF!
Either cancel automatically adding content-type or always sign the request without thinking about content-type will finally solve the problem.
Plz fix it.


So, I know nothing about OAuth, but it looks like we just shouldn't be checking the Content Type header. The OAuth code appears to check for the presence of a file anyway, so it doesn't seem like it matters.

Thoughts @kennethreitz?


So nobody cares?
@kennethreitz has so many activities today.


I'm on the go, but very generally:

If you're passing in a dict, requests will render the dict as www-form-urlencoded in the HTTP body, and set the appropriate content type. These parameters are taken as input when building the base signing string (http://tools.ietf.org/html/rfc5849#section-3.4.1.3.1), but only if the content-type header is set to "application/x-www-form-urlencoded", otherwise the request body is ignored for the purpose of signing.

Since the act of passing a body dict payload in requests is a clear signal of your intention to have form-urlencoded body, the content-type is set automatically.

If the body is anything but a dict (or a manually-generated, valid x-www-form-urlencoded body), oauth should be ignoring the body for the purposes of signing and should not be setting a content-type (since you're doing something special).

That's how it should work. If it works any other way, then we need to look into it.  

On Monday, August 20, 2012 at 9:33 AM, 老A wrote:

> So nobody cares?
> @kennethreitz (https://github.com/kennethreitz) has so many activities today.  
> 
> —
> Reply to this email directly or view it on GitHub (https://github.com/kennethreitz/requests/issues/790#issuecomment-7861749).  


@idan I understand the complete workflow, but the design purpose make all things complicated.

You can see how kennethreitz/requests use requests, and i agree what they do.

If i pass the auth to requests, i think requests should do all auth stuffs, but not like current situation, i must manually add oauth signature. If requests needs manual operation, why i pass the auth arguments to it?

Passing dict object as post data parameters is a normal demand, but not doing something special!!! Every developer are doing like this after read your documentation. Passing the auth and thinking auth function will do things automatically is also a normal thought. If i want to do something special, i will do it before pass the whole thing into requests.

The content-type is set by your code not mine, and the conditional which ignore the post data is also part of your logical but not mine. So what a special thing you think may happen is made by your code but not mine.

> but only if the content-type header is set to "application/x-www-form-urlencoded", otherwise the request body is ignored for the purpose of signing.

Why you ignore to sign? What's the reason? So i must sign the request by myself although i told the requests "plz do the auth work"? Does your thought make things simpler or more complicated?


In fact, https://github.com/kennethreitz/requests/blob/develop/requests/models.py#L514 here set content-type to 'application/x-www-form-urlencoded' and if it's not set, it will still be set on https://github.com/kennethreitz/requests/blob/develop/requests/auth.py#L97
So you are doing duplicate work and make the whole thing really complicated.

And if someone set incorrect content-type(anything other than 'multipart/form-encoded') and post a file, you just let the incorrect thing pass by?

So what's your root design purpose @idan ? If you think developers will do things special, you should remove the code which add content-type automatically, or remove the content-type detect conditions in order to make signing work.


Relax, @ayanamist, @idan is agreeing with you. He said that the parameters should be taken as input to the signing function only if the `Content-Type` header is `application/x-www-form-urlencoded`. If you pass in a dict, such a header is set, so we should be signing it, but we aren't. **This is a bug.**

As for "why is the request body ignored for signing in other cases", it's because the specification says to ignore it. This isn't Requests' decision, it's just what the specification says to do.


Fixed!


@kennethreitz Thank you very much :-)