search

andysmart / Timberjack

Automatic network activity logger for iOS and OSX
MIT License
159 stars 43 forks source link

Alamofire Manager initialisation with Timberjack configuration and serverTrustPolicyManager not working #3

Open andrewjackman opened 8 years ago

andrewjackman commented 8 years ago

I'm having a problem integrating this with my custom Alamofire Manager. I currently construct the Manager like this:

private let manager = Alamofire.Manager(serverTrustPolicyManager: ServerTrustPolicyManager(policies: [
    "api.example.com": .PerformDefaultEvaluation(validateHost: true),
    "dev.api.example.com": .PerformDefaultEvaluation(validateHost: false),
    "staging.api.example.com": .PerformDefaultEvaluation(validateHost: false)
]))

and my wildcard SSL certificate hostname verification is ignored on the dev.api and staging.api subdomains.

As soon as I add the configuration to support Timberjack logging to the Manager.init like this:

private let manager = Alamofire.Manager(configuration: Timberjack.defaultSessionConfiguration(), serverTrustPolicyManager: ServerTrustPolicyManager(policies: [
    "api.example.com": .PerformDefaultEvaluation(validateHost: true),
    "dev.api.example.com": .PerformDefaultEvaluation(validateHost: false),
    "staging.api.example.com": .PerformDefaultEvaluation(validateHost: false)
]))

the default serverTrustPolicyManager seems to be used, and my SSL handshake with dev.api and staging.api fail, because they don't match the *.example.com SSL certificate hostname. It's like something is overwriting my ServerTrustPolicyManager.

Any ideas?

andrewjackman commented 8 years ago

So I posted this issue on SO (http://stackoverflow.com/questions/33415925/alamofire-manager-initialisation-with-timberjack-configuration-and-servertrustpo) and when I followed cnoon's suggestion to replace the Timberjack configuration with NSURLSessionConfiguration.defaultSessionConfiguration(), my server trust policies worked.

Looking at the Timberjack code I can't see why this would be an issue...

andysmart commented 8 years ago

Hmm - odd one. Since we're proxying the requests - my guess would be that we're not implementing something optional on NSURLProtocol for SSL pinning.

I have to admit, I hadn't tested it for this use case, but leave it with me and I'll have a look - thanks for raising!

andysmart commented 8 years ago

Looks like we need to explicitly support it in Timberjack.

Apple have a reference here https://developer.apple.com/library/ios/samplecode/CustomHTTPProtocol though I'm not sure how up-to-date this reference is.

I'll open a feature note to support this in future, as I can see it being useful - but for now it's not going to work for you I'm afraid.

andrewjackman commented 8 years ago

Ah yes, I see now. Looking at Alamofire Request.swift, they also support the following method, which implements the SSL stuff 

public func URLProtocol(`protocol`: NSURLProtocol, didReceiveAuthenticationChallenge challenge: NSURLAuthenticationChallenge)

See here (https://github.com/Alamofire/Alamofire/blob/master/Source/Request.swift):line 248

So, I'm going to add the following optional NSURLConnectionDelegate method, and implement it:

func connection(connection: NSURLConnection, didReceiveAuthenticationChallenge challenge: NSURLAuthenticationChallenge)

I will submit a pull request when I've got it working...

andrewjackman commented 8 years ago

Actually I don't have a clue how to do this. I had a look around and it's more complicated than I expected.

mvoelkl commented 8 years ago

Can confirm that bug, got some grey hair... Are there any updates?