TIC TCP Conn Failed 1:54 Ошибка (54) - PullRequest
0 голосов
/ 25 апреля 2018

Я пытаюсь сделать POST-запросы к безопасному серверу в моем приложении без сертификата.Когда я делаю запрос, я получаю следующие ошибки в консоли:

2018-04-24 16:14:22.942030-0400 TIC TCP Conn Failed [8:0x60000017c440]: 1:54 Err(54) 2018-04-24 16:14:22.942779-0400 Task <1E09E1AE-CE51-48C4-9A56-F3738B8FD68F>.<1> HTTP load failed (error code: -1005 [1:54]) 2018-04-24 16:14:22.943219-0400 [93037:8075678] Task <1E09E1AE-CE51-48C4-9A56-F3738B8FD68F>.<1> finished with error - code: -1005

In URLSession:didReceiveChallenge Я не проверяю сертификат;Я просто звоню continueWithoutCredentialForAuthenticationChallenge.

Мой домен установлен как исключение для ATS в Info.plist:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>mydomain.net</key>
        <dict>
            <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSThirdPartyExceptionRequiresForwardSecrecy</key>
            <false/>
        </dict>
    </dict>
</dict>

Я не могу найти какую-либо документацию о том, что Err(54) и error code: -1005 значит, поэтому я сталкиваюсь с препятствиями при поиске неисправностей.Также стоит упомянуть, что мне нужно подключить мой Mac к VPN для проверки связи с этим сервером, и что я запускаю это в моем симуляторе.

Я надеюсь услышать некоторые предложения относительно того, что может бытьидет не так и как исправить.

Ответы [ 2 ]

0 голосов
/ 25 апреля 2018

Вы должны понимать, что ваши настройки ATS позволяют вашему приложению.

NSAllowsArbitraryLoads при значении true позволяет подключаться к любому серверу по HTTP Поэтому не стесняйтесь пытаться загрузить данные с любого URL по схеме http.

Настройка домена исключения (при условии, что ваш "mydomain.net" является заполнителем для фактического значения) позволит вам подключиться к любому поддомену (поскольку NSIncludesSubdomains true) из "mydomain.net", используя:

  1. HTTP (потому что для NSTemporaryExceptionAllowsInsecureHTTPLoads установлено значение true)
    • или -
  2. HTTPS-соединение, которое поддерживает все требования ATS, за исключением прямой секретности (поскольку вы установили NSThirdPartyExceptionRequiresForwardSecrecy только в true)

Сначала убедитесь, что вы можете подключиться к URL-адресу, к которому вы пытаетесь подключиться, из Safari на соответствующем устройстве (в данном случае, на симуляторе). Safari не обеспечивает выполнение требований ОВД, поэтому вы можете увидеть, связано ли это с ОВД. Если вы не можете получить доступ к URL-адресу, он связан с подключением. Это может быть недоступность сервера или проблема с сертификатом для безопасного соединения. Если это проблема, вы, вероятно, можете избавиться от любых исключений ATS, которые вы добавили, пытаясь решить проблему.

Если вы можете подключиться к ресурсу, попробуйте проверить, какие требования ATS не выполняются, чтобы вы могли добавить соответствующие исключения. В терминале на вашем Mac запустите следующую команду, чтобы получить отчет о соответствии сервера правилам ATS:

nscurl --ats-diagnostics <url>   

Это скажет вам, если сервер не поддерживает прямую секретность, или если версия TLS слишком низкая. Затем вы можете добавить определенные исключения ATS для этого домена.

Я все еще считаю, что есть еще одна проблема, поскольку ошибки ATS в журнале обычно очень ясны. Ваша ошибка кажется общей проблемой подключения. Вы упоминаете, что ваш Mac подключен к VPN. Требует ли ваша VPN использование прокси HTTP / HTTPS? Если так, у меня были проблемы с симулятором, пытающимся использовать прокси Mac, когда прокси требует определенных типов аутентификации. Если ваш http-прокси требует аутентификации, вы можете попытаться установить что-то вроде Charles Proxy в качестве посредника. То есть настройте прокси-сервер Charles для аутентификации на прокси-сервере вашей компании, а затем укажите Mac / симулятору использовать локальный прокси-сервер Charles, который должен быть настроен так, чтобы не нуждаться в аутентификации.

0 голосов
/ 25 апреля 2018

Я обнаружил, что проблема была в том, как я справлялся с URLSession:didReceiveChallenge.Я только звонил continueWithoutCredentialForAuthenticationChallenge.Чтобы заставить его работать, я позвонил completionHandler с полномочиями:

SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust]; ASSERT(nil != serverTrust); NSURLCredential *credential = [NSURLCredential credentialForTrust:serverTrust]; completionHandler(NSURLSessionAuthChallengeUseCredential, credential);

...