yahoo/tdoauth

A BSD-licensed single-header-single-source OAuth1 implementation.

tdoauth's Issues

YHOO weather make request return nil

I use TDOAuth make nsmutable request, return Nil can tell me how to solve it?
The following method request returns nil .
consumerKey ，consumerSecret，appId All have value。

-(NSMutableURLRequest *)requestWithParameters:(NSDictionary *)parameters
{

NSMutableURLRequest *request = [[TDOAuth URLRequestForPath:@"/forecastrss"
                                             GETParameters:parameters
                                                    scheme:@"https"
                                                      host:@"weather-ydn-yql.media.yahoo.com"
                                               consumerKey:self.consumerKey
                                            consumerSecret:self.consumerSecret
                                               accessToken:nil
                                               tokenSecret:nil] mutableCopy];
[request addValue:self.appId forHTTPHeaderField:@"X-Yahoo-App-Id"];
return request;

}

Serious encoding problem

Hi @mxcl ,
I have an encoding problem. I know TDPCEN is used to encode parameters that we want to put it to the URL, but I think the allowedCharacters is not correct.

https://github.com/tweetdeck-archive/TDOAuth/blob/ae2c28edff37ee844cc5732870a10c75215c9384/TDOAuth.m#L37

#define TDPCEN(s)
([[s description] stringByAddingPercentEncodingWithAllowedCharacters:[[NSCharacterSet characterSetWithCharactersInString:@"^!*'();:@&=+$,/?%#[] "] invertedSet]])

For example,
Input:
{
q = "insert into db ( jsonData ) values ( '{"a":"b","c":"d"}' )";
}
TDPCEN("q")
TDPCEN("insert into db ( jsonData ) values ( '{"a":"b","c":"d"}' )")

Output:
q=insert%20into%20db%20%28%20jsonData%20%29%20values%20%28%20%27{"a"%3A"b"%2C"c"%3A"d"}%27%20%29

We notice that {, } and " are not encoded, and it cause NSURL to be nil.
It may occur in https://github.com/tweetdeck-archive/TDOAuth/blob/ae2c28edff37ee844cc5732870a10c75215c9384/TDOAuth.m#L280

I have an idea to solve the problem.
Just replace [[NSCharacterSet characterSetWithCharactersInString:@"^!*'();:@&=+$,/?%#[] "] invertedSet]] with [NSCharacterSet URLQueryAllowedCharacterSet] to correct it.

What do you think?

OMGUserAgent?

Hello, I've used this lib in the past, it's been very useful, thank you!

I just updated and see an inclusion of OMGUserAgent in TDOAuth.m and use of this object later.

Is this a required dependency?

The version is still set to 1.0.4

I will fix this if you like, but I think it's dangerous to leave it set to the same number with the code changes that are in there. Would you prefer 1.0.5 or 1.1.0?

Use HTTPS as default scheme

Modern iOS does not permit non-SSL protected HTTP by default. This library should not default to an normally unsupported scheme.

'CFURLCreateStringByAddingPercentEscapes' is deprecated in iOS 9.0

'CFURLCreateStringByAddingPercentEscapes' is deprecated: first deprecated in iOS 9.0 - Use [NSString stringByAddingPercentEncodingWithAllowedCharacters:] instead, which always uses the recommended UTF-8 encoding, and which encodes for a specific URL component or subcomponent (since each URL component or subcomponent has different rules for what characters are valid).

Query parameters in Authorization header

It seems like query parameters are added to the Authorization header besides being appended to the resource path. I'm not very familiar with the OAuth protocol. I glanced at the examples in the RFC and it doesn't seem like they should be included in the Authorization header.

Including the query parameters in the Authorization header makes the server and client disagree on the signature.

Maintaining TDOAuth

This pod is a great resource. It's incredibly simple with a minimalistic design. Thank you for providing and maintaining it over the past 8 years.

It has become a critical component of some popular Yahoo iOS apps, such as Yahoo Finance. Yes, we know about OAuth 2.0... however OAuth 1.0a is still very well suited for client (not user) identification purposes and abuse mitigation in many situations.

The repository has not been moved to "archive" mode, indicating that support is becoming less likely. I am proposing two potential paths forward for this project:

1. Transfer ownership to the Yahoo Open Source Github organization, where a team of seasoned iOS engineers will actively look after and love the project for the foreseeable future.
2. Add 2-3 agreeable Yahoo maintainers to the project to ensure ongoing stewardship.

Some thing we'd like to do:

• Full Swift compatibility (nullability, method names, etc)
• Update unit tests to something modern like Quick/Nimble
• Performance optimizations
• Fix some edge cases non-RFC-compliant signatures are generated (i.e. websockets)
• Add a license to the next release (MIT?)

There is an elegance to OAuth 1.0 for client identification. OAuth 2.0 requires an independent token exchange service to provide the same functionality. For this reason, I see a future for this simple OAuth 1.0 request signer.

Freedom

One direct link that no1 can tamper with

Stop hacking n tracking

signature_base doesn't sign properly on an empty (=nil) param set

Using an empty parameter set breaks signature generation [params mutableCopy returns nil if params is nil...].

Proposed fix:

(NSString *)signature_base {
NSMutableDictionary *sigParams = nil;
if ( params != nil)
    sigParams = [params mutableCopy];
else
    sigParams = [[NSMutableDictionary alloc]init];

[sigParams addEntriesFromDictionary:oauthParams];

Can you publish 1.1.4 podspec?

Currently, we have to pin our Podfile to 1.1.2 (due to an encoding issue in 1.1.3) or override TDOAuth.podspec locally. Would be nice to just use the published 1.1.4 version.

Params for DELETE & HEAD requests should be handled like GET

HTTP spec forbids an entity for HEAD requests, so specified parameters should be appended to URL (as with GET).

Older specs also seemed to not want entity in DELETE requests either. Newer RFC do allow these, however the more compatible path forward is to put them in the URL

If nobody has a problem treating HEAD & DELETE parameters like GET, I'll make a pull request to fix this.

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-6.7

Signature Base does not include port when provided / non-default

Testing on a local oauth provider instance, if I run on a non-standard port and provide it in the url, TDOAuth removes the port when generating the base. This is not correct looking at the OAuth 1.0 protocol: http://tools.ietf.org/html/rfc5849#section-3.4.1.2

ie
GET on http://localhost:8080/myService
generates a signature base of: GET&http%3A%2F%2Flocalhost%2FmyService ...
when it should be: GET&http%3A%2F%2Flocalhost%3A8080%2FmyService ...

As a result, the signature is invalid to the provider. Trivial issue, but I found it annoying.