Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
andrewjackman opened this issue Oct 29, 2015 · 6 comments
Labels

Comments

@andrewjackman
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

mvoelkl commented Jul 27, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants