TIC TCP Conn Failed 1:54 Err (54)
Я пытаюсь отправить 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
В 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, чтобы проверить связь с этим сервером, и что я запускаю это в своем симуляторе.
Я надеюсь услышать несколько предложений о том, что может пойти не так и как исправить.
Это HTTPS. Спасибо за предложение. Я использовал запрос curl, чтобы обнаружить, что действительно могу сделать запрос из командной строки, но обнаружил, что проблема заключалась в том, как я обрабатывал (или не обрабатывал) завершение для didReceiveChallenge. Я отправлю ответ.
Ответы 2
Я обнаружил, что проблема заключалась в том, как я обращался с URLSession:didReceiveChallenge. Я звонил только continueWithoutCredentialForAuthenticationChallenge. Чтобы заставить его работать, я позвонил completionHandler с учетными данными:
SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];
ASSERT(nil != serverTrust);
NSURLCredential *credential = [NSURLCredential credentialForTrust:serverTrust];
completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
Рад, что вы обнаружили проблему. Это не похоже на ошибку ATS.
Вы должны понимать, что ваши настройки ATS позволяют вашему приложению делать.
Если для NSAllowsArbitraryLoads установлено значение true, вы можете подключаться к любому серверу через HTTP. Поэтому не стесняйтесь пытаться загрузить данные с любого URL-адреса с помощью схемы http.
Настройка вашего домена исключения (при условии, что ваш «mydomain.net» является заполнителем для фактического значения) позволит вам подключиться к любому поддомену (поскольку NSIncludesSubdomains истинен) «mydomain.net», используя:
- HTTP (потому что для
NSTemporaryExceptionAllowsInsecureHTTPLoadsустановлено значение true)- или же -
- Соединение HTTPS, которое поддерживает все требования ATS, кроме прямой секретности (поскольку вы установили только для
NSThirdPartyExceptionRequiresForwardSecrecyзначение true)
Сначала убедитесь, что вы можете подключиться к URL-адресу, к которому вы пытаетесь подключиться, из Safari на рассматриваемом устройстве (в данном случае в симуляторе). Safari не требует соблюдения требований ATS, поэтому вы можете увидеть, связано ли это с ATS. Если вы не можете получить доступ к URL-адресу, это связано с подключением. Это может быть сервер недоступен, или это может быть проблема с сертификатом для безопасного соединения. Если это проблема, вы, вероятно, можете избавиться от любых добавленных вами исключений ATS, пытаясь решить эту проблему.
Если вы можете подключиться к ресурсу, попробуйте проверить, какие требования ATS не выполняются, чтобы вы могли добавить соответствующие исключения. В Терминале на вашем Mac запустите следующее, чтобы получить отчет о соответствии сервера правилам ATS:
nscurl --ats-diagnostics <url>
Это сообщит вам, не поддерживает ли сервер прямую секретность или версия TLS слишком мала. Затем вы можете добавить определенные исключения ATS для этого домена.
Я все же считаю, что есть еще одна проблема, так как ошибки ATS в журнале обычно очень четкие. Ваша ошибка похожа на общую проблему с подключением. Вы упомянули, что ваш Mac подключен к VPN. Требует ли ваш VPN использования прокси HTTP / HTTPS? Если это так, у меня были проблемы с симулятором, пытающимся использовать прокси-сервер Mac, когда прокси-сервер требует определенных типов аутентификации. Если ваш http-прокси требует аутентификации, вы можете попробовать использовать в качестве посредника что-нибудь вроде Charles Proxy. т.е. настройте Charles Proxy для аутентификации на прокси-сервере вашей компании, затем укажите Mac / симулятору использовать локальный прокси Charles, который должен быть настроен так, чтобы аутентификация не требовалась.
Спасибо за предложения и информацию. Я удалил исключения ATS для своего домена. На самом деле это была проблема с сертификатом, и я смог обойти проверку сертификата, как описано в моем ответе. Это временно, так как я работаю над проверкой концепции, и когда она будет завершена и запущена в производство, у меня будет соответствующий сертификат в приложении, поэтому в этом не будет необходимости.
Каков URL-адрес сервера, к которому вы подключаетесь? HTTP / HTTPS? Ошибка, которую вы видите, не связана с ATS - просто устройство / симулятор не может подключиться к URL-адресу, к которому вы пытаетесь подключиться. Чтобы проверить, зайдите в Safari на симуляторе и попробуйте нажать тот же URL.