Unable to connect to servers serving HTTPS connections with self-signed certificates about apollo-ios HOT 11 CLOSED

@martijnwalraven I've got Apollo working with self signed certs by making the HTTPNetworkTransport the session delegate and then accepting the URLAuthenticationChallenge that comes through on the didReceive challenge delegate method.

Obviously this isn't very secure so probably only usable during testing (Which is really only when you should be using a self signed cert really).

What do you think about toggling this on when building for DEBUG ? That way without modifying Apollo it won't be possible to publish an app to the store if you're hitting a server without a proper cert (In so far as the app won't work).
The alternatives to the above that I can think of would be:

• Optional property, something along the lines of insecure (To match codegen)
• Separate InsecureHTTPNetworkTransport class

What do you think?

from apollo-ios.

Hmmm, if it's on by default in debug builds, that means you may not be aware of problems until you're ready to release. I think I'd prefer for this to be controlled by a property on HTTPNetworkTransport, so people have to enable it explicitly. Although that has the danger of inadvertently leaving it on in production. Maybe we could print a warning to remind people it is enabled, or automatically disable it in release builds?

from apollo-ios.

Good point, would be a bit of a killer to find out your server doesn't work only when you're ready to release!

Think a mix of it being an optional property but then also being disabled for release builds makes a lot of sense, and we can throw in the printed warning too. Would be ideal if we had an equivalent in Swift of the C# #error; That way we could simply stop the build at compile time if in release and the property has been set to true.

The HTTPNetworkTransport class needs to inherit from NSObject to be an NSURLSession delegate, any problems with that?

from apollo-ios.

I didn't know about #error, but I did some digging and it seems we can get a similar result in Swift:

#if DEBUG
var allowsInvalidSSLCertificate: Bool = false
#else
@available(*, unavailable, message: "Invalid certificates should only be allowed in development")
var allowsInvalidSSLCertificate: Bool = false
#endif

I really like this, thanks for the suggestion! (The allowsInvalidSSLCertificate name comes from AFNetworking, it seems descriptive.)

I don't think we can avoid having to inherit from NSObject, so I'm ok with that.

from apollo-ios.

That would be super nice, best of both worlds!

Only problem I can see at the moment is that the DEBUG preprocessor macros don't appear to be available by default in Swift in the same way that they are in Obj C. To get the above to work I've had to define the DEBUG flag under Other Swift Flags.

Do you run in to the same problem at all or is yours working straight away without need to specify DEBUG manually?

from apollo-ios.

I don't think I defined any flags, DEBUG seems to be listed by default under 'Active Compilation Conditions':

from apollo-ios.

Interesting. I've just made a new project and I've got the same; Though in all of my existing/older projects it's not present.

After a bit of looking around it seems that Active Compilation Conditions is the replacement for Other Swift Flags. It was introduced in Xcode 8 which means that any projects created before that won't, by default, have DEBUG defined. Without at least a warning that the compilation condition needs to be set the error by itself could be a little confusing .

Any new projects going forward will have this enabled but it would be good to support projects created before Xcode 8 that don't have this (I'd imagine it's the majority). Some kind of drop through like this means that both DEBUG and a RELEASE need to be defined before a project can even build with Apollo:

#if DEBUG
    var allowsInvalidSSLCertificate: Bool = false
#elseif RELEASE
    @available(*, unavailable, message: "Invalid certificates should only be allowed in development")                
    var allowsInvalidSSLCertificate: Bool = false
#else
    @available(*, unavailable, message: "Please define both DEBUG and RELEASE in Build Settings -> Active Compilation Conditions")
    var allowsInvalidSSLCertificate: Bool = false
#endif

Whilst it would catch everyone it's a bit of a forceful way of doing it.

What do you think?

from apollo-ios.

Does Xcode ask you to upgrade your project configuration to include the new settings?

I'd rather not force people to define RELEASE. Maybe we could add a notice as part of the unavailable message? Something like: "Invalid certificates should only be allowed in development (make sure DEBUG is defined)"

from apollo-ios.

It doesn't unfortunately.

Definitely agree, adding a flag purely as a workaround does feel a bit 'hacky'

Thinking about it, since the DEBUG check is going to be done within the Apollo itself it should be possible to define the flag in that target. At present Active Compilation Conditions is set up properly (If I clone the repo and take a look at the build settings) but it's getting cleared out installing it as a pod; If we could figure out what's doing that we could remove it/overwrite it and that should solve the problem perfectly.

from apollo-ios.

Looks as if the pod target will inherit the Other Swift Flags from the pods it's using. With that in mind it could be as easy as adding "-D DEBUG" to the set of Debug flags on Apollo itself; Any projects that install it should then (In theory) inherit the DEBUG flag as well.

from apollo-ios.

As of 0.15.0, we now support passing in a URLSession rather than just a URLSessionConfiguration, so you are able to take advantage of the URLSessionDelegate methods in order to facilitate this.

If you are still having problems with this after upgrading, please open a new issue. Thank you!

from apollo-ios.