ios - 实现 func urlSession(_ session : URLSession, didReceive challenge: URLAuthenticationChallenge) 有什么区别

Question

在后台 session 中，对于使用 https 的应用<>服务器通信，以下方法的相当轻松的实现有什么区别，或根本没有 ?

  func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
    completionHandler(.useCredential, challenge.proposedCredential)
  }

在这两种情况下，应用程序都可以工作，但我已经阅读了有关此方法的每次调用都会增加应用程序的恢复速率限制的信息(据说这很糟糕)

所以是的，在我意识到该应用程序在没有任何实现此方法的情况下可以正常工作后，我开始问自己可能实现它的原因是什么？授权是通过 401 和随后的登录完成的。

Answer 1

我认为可以从文档 Performing Manual Server Trust Authentication 中找到一些有用的信息。 :

To perform manual server trust authentication, implement the URLSessionDelegate method urlSession(_:didReceive:completionHandler:).

跟随:

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.

并通过实现 URLSessionDelegate 方法 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.