Refactoring AFOAuth1Client

[crino]

Hi Matt,
i've re-written AFOAuth1Client written from the 'scratch'.

There are new 3 methods:
-(NSMutableURLRequest*)multipartFormOAuthRequestWithMethod;
-(void)enqueueOAuthOperationWithMethod;
-(void)getOAuthPath;
-(void)postOAuthPath;
So user can sends OAuth, 'standard' requests with one http client.
In add, also added an 'extras' property for AFOAuthToken where user can find any additional data returned by the server.

In my new code i simply sign the NSURLRequest objects adding the OAuth parameters in Header, Get or Post (only if content-type is application/x-www-form-urlencoded otherwise will be used header).
My code can sign any type of request, also multidata in post! ;)

Hope this help the community

crino

[mattt]

Hi @crino, thanks for sending this. However, I'm not sure I agree with the premise of this refactoring.

AFOAuth1Client was designed to be a standalone instance, with its sole purpose being to get the authorization credentials. Those credentials would then be passed to another AFHTTPClient; often the receiving HTTP client would have the OAuth client as a property.

One reason is that sometimes the OAuth endpoint is slightly different from the main HTTP client endpoint (either because it uses HTTPS, structures things a bit differently, or is on a subdomain). Another reason is that it introduces a lot of coupling between the HTTP client and how it authenticates; there are far too many edge cases to account for, with no particular benefit of having these aspects tightly-coupled. And if for no other reason, maintaining API compatibility, reusing the existing semantics of AFHTTPClient for OAuth makes it a lot easier to understand what exactly is going on, and how to use it.

Again, thanks for creating this pull request, but I don't believe that this design presents sufficient advantage to justify such a significant departure from the current architecture.

[crino]

Hi @mattt,
thanks, probably i misunderstood the scope of AFOAuth1Client.