In a background session, for an app<>server communication using https, what is the difference between a fairly relaxed implementation of the following method, or none at all?
func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
completionHandler(.useCredential, challenge.proposedCredential)
}
In both cases the app works, but I've read about each invocation of this method incrementing the Resume Rate Limit of the app (which is supposedly bad)
So yeah, after I realized that the app just works without any implementation of this method, I started asking myself what is the reason for possibly implementing it? Authorization is done via 401 and a subsequent login.
I think some useful information could be found from documentation Performing Manual Server Trust Authentication:
To perform manual server trust authentication, implement the URLSessionDelegate method urlSession(_:didReceive:completionHandler:).
Following with:
In most cases, you should let the URL Loading System’s default handling evaluate the server trust. You get this behavior when you either don’t have a delegate or don’t handle authentication challenges.
And to explain why you might need to do a manual server trust authentication, thus by implementing the URLSessionDelegate method urlSession(_:didReceive:completionHandler:):
However, performing your own evaluation may be useful for scenarios like the following:
You want to accept server credentials that would otherwise be rejected by the system. For example, your app makes a secure connection to a development server that uses a self-signed certificate, which would ordinarily not match anything in the system’s trust store.
You want to reject credentials that would otherwise be accepted by the system. For example, you want to “pin” your app to a set of specific keys or certificates under your control, rather than accept any valid credential.