iOS 10 適配 ATS

一. HTTPS

其實HTTPS從最終的數(shù)據(jù)解析的角度，與HTTP沒有任何的區(qū)別，HTTPS就是將HTTP協(xié)議數(shù)據(jù)包放到SSL/TSL層加密后，在TCP/IP層組成IP數(shù)據(jù)報去傳輸，以此保證傳輸數(shù)據(jù)的安全；而對于接收端，在SSL/TSL將接收的數(shù)據(jù)包解密之后，將數(shù)據(jù)傳給HTTP協(xié)議層，就是普通的HTTP數(shù)據(jù)。HTTP和SSL/TSL都處于OSI模型的應(yīng)用層。從HTTP切換到HTTPS是一個非常簡單的過程，在做具體的切換操作之前，我們需要了解幾個概念：

SSL/TLS

為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定義在RFC 6101中，之后IETF對SSL 3.0進(jìn)行了升級，于是出現(xiàn)了TLS（Transport Layer Security） 1.0，定義在RFC 2246。實際上我們現(xiàn)在的HTTPS都是用的TLS協(xié)議，但是由于SSL出現(xiàn)的時間比較早，并且依舊被現(xiàn)在瀏覽器所支持，因此SSL依然是HTTPS的代名詞，但無論是TLS還是SSL都是上個世紀(jì)的事情，SSL最后一個版本是3.0，今后TLS將會繼承SSL優(yōu)良血統(tǒng)繼續(xù)為我們進(jìn)行加密服務(wù)。

SSL/TLS協(xié)議運行機(jī)制的概述

圖解SSL/TLS協(xié)議

簡單的來說，SSL/TSL通過四次握手。SSL協(xié)議的工作流程：

服務(wù)器認(rèn)證階段：

客戶端向服務(wù)器發(fā)送一個開始信息“Hello”以便開始一個新的會話連接；

服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要則服務(wù)器在響應(yīng)客戶的“Hello”信息時將包含生成主密鑰所需的信息；

客戶根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個主密鑰，并用服務(wù)器的公開密鑰加密后傳給服務(wù)器；

服務(wù)器恢復(fù)該主密鑰，并返回給客戶一個用主密鑰認(rèn)證的信息，以此讓客戶認(rèn)證服務(wù)器。

用戶認(rèn)證階段：

在此之前，服務(wù)器已經(jīng)通過了客戶認(rèn)證，這一階段主要完成對客戶的認(rèn)證。

經(jīng)認(rèn)證的服務(wù)器發(fā)送一個提問給客戶，客戶則返回（數(shù)字）簽名后的提問和其公開密鑰，從而向服務(wù)器提供認(rèn)證。

二. App Transport Security

iOS9中新增App Transport Security（簡稱ATS）特性, 主要使到原來請求的時候用到的HTTP，都轉(zhuǎn)向TLS1.2協(xié)議進(jìn)行傳輸。這也意味著所有的HTTP協(xié)議都強(qiáng)制使用了HTTPS協(xié)議進(jìn)行傳輸。在 iOS 9 和 OS X 10.11 中，默認(rèn)情況下非 HTTPS 的網(wǎng)絡(luò)訪問是被禁止的。當(dāng)然，因為這樣的推進(jìn)影響面非常廣，作為緩沖，我們可以在 Info.plist 中添加NSAppTransportSecurity字典并且將NSAllowsArbitraryLoads設(shè)置為YES來禁用 ATS。

不過，WWDC 16 中，Apple 表示將繼續(xù)在 iOS 10 和 macOS 10.12 里收緊對普通 HTTP 的訪問限制。從 2017 年 1 月 1 日起，所有的新提交 app 默認(rèn)是不允許使用NSAllowsArbitraryLoads來繞過 ATS 限制的，也就是說，我們最好保證 app 的所有網(wǎng)絡(luò)請求都是 HTTPS 加密的，否則可能會在應(yīng)用審核時遇到麻煩。

三. iOS10 NSAppTransportSecurity

通過在info.plist中配置這個鍵，開發(fā)者可以自定義網(wǎng)絡(luò)安全策略。例如：

允許針對個別服務(wù)器的不安全訪問。

允許不安全的 web 或媒體內(nèi)容訪問，但不影響整個app的ATS策略。

啟用新的安全特性，例如Certificate Transparency。

對NSAppTransportSecurity的支持自 iOS9.0，OS X v10.11 開始，適用于 app 和 app extension。

自 iOS10.0，macOS 10.12 開始，增加了對下列子鍵的支持：

NSAllowsArbitraryLoadsInMedia

NSAllowsArbitraryLoadsInWebContent

NSRequiresCertificateTransparency

NSAllowsLocalNetworking

ATS Configuration Basics / ATS 配置基礎(chǔ)知識

對于使用 iOS9.0， OS X v10.11 SDK 及以上的 app 來說，ATS（App Transport Security）默認(rèn)開啟，NSAllowsArbitraryLoads是字典NSAppTransportSecurity的根鍵，默認(rèn)值NO。

在啟用 ATS 的情況下，所有的 HTTP 請求必須為 HTTPS（RFC 2818） 連接。任何不安全的 HTTP 請求都將失敗。ATS 使用 TLS（Transport Layer Security）v1.2（RFC 5246）。

下面是字典NSAppTransportSecurity的總體結(jié)構(gòu)，所有鍵都是非必填項：

NSAppTransportSecurity: Dictionary {NSAllowsArbitraryLoads: BooleanNSAllowsArbitraryLoadsInMedia: BooleanNSAllowsArbitraryLoadsInWebContent: BooleanNSAllowsLocalNetworking: BooleanNSExceptionDomains: Dictionary {? ? ? ?: Dictionary {NSIncludesSubdomains: BooleanNSExceptionAllowsInsecureHTTPLoads: BooleanNSExceptionMinimumTLSVersion: StringNSExceptionRequiresForwardSecrecy: Boolean// Default value is YESNSRequiresCertificateTransparency: Boolean? ? ? ? }? ? }}

可以看出，所有鍵可以分為兩類：主鍵，這些鍵用來定義 app 的總體 ATS 策略；子鍵，即NSExceptionDomains下面的鍵，使用這些鍵針對某個域名單獨配置。

主鍵包括：

NSAllowsArbitraryLoads

設(shè)置為 YES，解除整個 app 的 ATS 限制；但是，通過NSExceptionDomains進(jìn)? ? 行的配置依然有效。默認(rèn)值為 NO。

注意：設(shè)置為 YES，會引發(fā) App Stroe 的審查，開發(fā)者必須說明原因。

NSAllowsArbitraryLoadsInMedia

設(shè)置為 YES，解除通過 AV Foundation 框架訪問媒體內(nèi)容時的 ATS 限制；啟用這個? ? 鍵，務(wù)必確保載入的媒體內(nèi)容已經(jīng)被加密，例如受FairPlay保護(hù)的文件，或者是安全的? ? HLS流媒，其中不包含敏感的個人信息。默認(rèn)為 NO。

NSAllowsArbitraryLoadsInWebContent

設(shè)置為 YES，解除通過 web view 發(fā)出的網(wǎng)絡(luò)請求的 ATS 限制。啟用這個鍵，可以使? ?app 訪問任意網(wǎng)頁內(nèi)容，但不影響 app 的總體 ATS 策略。此鍵值默認(rèn)為 NO。

NSAllowsLocalNetworking

設(shè)置為 YES，使得 app 可以載入任意本地資源，但不影響 app 的總體 ATS 策略。默? ? 認(rèn)為 NO。

NSExceptionDomains

為一個或多個域名單獨配置 ATS。

被單獨配置的域名，默認(rèn)受到完全的 ATS 限制，不管NSAllowsArbitraryLoads的值? ? 如何；需要通過子鍵，進(jìn)一步配置

所有的子鍵都屬于NSExceptionDomain。向Info.plist中添加這一主鍵：

創(chuàng)建字典，針對一個或多個域名，以便進(jìn)行 ATS 配置。

這意味著之前使用主鍵所做的設(shè)置，對于這個域名來說，已經(jīng)無效。

例如，及時之前設(shè)置NSAllowsArbitraryLoadsInMedia為 YES，然而NSExceptionDomain所代表的域名依然不能訪問不安全的媒體內(nèi)容。

基于這樣的設(shè)定，可以針對域名進(jìn)行 ATS 配置，增加或減少安全措施。例如：

將NSExceptionAllowsInsecureHTTPLoads設(shè)置為 YES，就 ；這樣做會引發(fā) App Store 的審查，詳情見App Store Review for ATS。

通過配置NSExceptionRequiresForwardSecrecy為 NO，取消正向保密。

通過配置NSExceptionMinimumTLSVersion，更改 TLS 最低版本。

NSExceptionDomains字典構(gòu)成：

<域名字符串>

代表想要配置的特定域名。可以添加多個域名（即添加多個這樣的鍵），為它們統(tǒng)一配置 ATS 策略。這個鍵對應(yīng)一個字典，包含以下子鍵：

NSIncludesSubdomains

* 設(shè)置為YES，當(dāng)前域名的 ATS 策略適用于其所有子域名。默認(rèn)為NO。

NSExceptionAllowsInsecureHTTPLoads

* 設(shè)置為YES，可以同時通過 HTTP 和 HTTPS 訪問當(dāng)前域名。默認(rèn)為NO。注意，配置這個鍵值，將引發(fā) App Store 的審查，開發(fā)者必須說明原因。

NSExceptionMinimumTLSVersion

*指定 TLS 的最低版本，因此可以使用版本較低，有安全漏洞的 TLS 協(xié)議。注意，配置這個鍵值，將引發(fā) App Store 的審查，開發(fā)者必須說明原因。

NSExceptionRequiresForwardSecrecy

* 設(shè)置為NO，允許針對當(dāng)前域名使用不支持正向保密的 TLS 加密算法。默認(rèn)為YES。

NSRequiresCertificateTransparency

* 設(shè)置為YES，將驗證域名服務(wù)器證書的Certificate Transparency時間戳 。默認(rèn)為NO。

Requirements for Connecting Using ATS ／ 使用 ATS 的前提條件

在 ATS 完全開啟的情況下，系統(tǒng)要求 app 的 HTTPS 連接必須滿足以下要求：

X.509 數(shù)字證書必須滿足下列標(biāo)準(zhǔn)中的一項：

由操作系統(tǒng)內(nèi)嵌的根證書頒發(fā)機(jī)構(gòu)簽發(fā)

由通過操作系統(tǒng)管理員或用戶主動安裝的根證書頒發(fā)機(jī)構(gòu)簽發(fā)

TLS 版本必須為1.2，任何不使用或使用較低版本 TLS / SSL 的連接，都將失敗。

連接必須使用 AES-128 或 AES-256 對稱加密算法。 TLS 算法套裝必須以 ECDSA 密鑰交換的形式支持正向保密，加密算法必須為下面之一：

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

服務(wù)端的葉證書簽名密鑰必須為下面之一：

至少2048位的 RSA 密鑰

至少256位的 ECC 密鑰

此外，服務(wù)器證書的哈希算法必須為 SHA-2，其摘要長度至少位256位（即 SHA-256 及以上）。

上面的標(biāo)準(zhǔn)，未來可能會發(fā)生變化。但不會影響到 app 二進(jìn)制包的兼容性。

App Store Review for ATS / App Store 對于 ATS 相關(guān)項的審核

某些對 ATS 的配置會引發(fā) App Store 的審核，開發(fā)者必須說明原因。這些鍵有：

NSAllowsArbitraryLoads

NSExceptionAllowsInsecureHTTPLoads

NSExceptionMinimumTLSVersion

以下是一些原因說明例子，供參考：

必須連接由其他機(jī)構(gòu)控制的服務(wù)器，其還不支持安全連接。

必須支持那些還未升級至可使用安全連接，不得不通過公共域名訪問網(wǎng)絡(luò)的設(shè)備。

必須通過 web 展示來源不一的各種網(wǎng)絡(luò)內(nèi)容，但又不能完全使用NSAllowsArbitraryLoadsInWebContent所管理的類。

向 App Store 提交審核時，開發(fā)者應(yīng)主動提供足夠的信息，以便解釋 app 無法使用安全連接的原因。

四. 實現(xiàn)支持安全ATS策略

ATS相關(guān)設(shè)置對iOS8及以下系統(tǒng)無效

需要解決的問題（iOS 9、iOS10及以上）

1、app內(nèi)服務(wù)器網(wǎng)絡(luò)請求訪問支持https（即一般的請求）

2、webview內(nèi)支持任意http訪問

3、第三方sdk接入與支持http訪問

主要是圍繞info.pilst配置文件作相關(guān)的安全ATS策略

Info.plist文件是向操作系統(tǒng)描述應(yīng)用程序的XML屬性列表,是iPhone應(yīng)用程序文件夾包含所有重要的Info.plist文件

你可能注意到一些關(guān)鍵字像是使用了一些其他關(guān)鍵字中的詞但是在前面加上了"ThirdParty"字樣，在功能上，這些關(guān)鍵字與不含有"ThirdParty"的關(guān)鍵字有同樣的效果。而且實際運行中所調(diào)用的代碼將會完全忽略是否使用"ThirdParty"關(guān)鍵字。

簡單粗暴的方案：

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

NSExceptionDomains 的設(shè)置方法如下, 比如我們要將 weibo.com 這個域名排除在 ATS 驗證之外，就可以這樣：

key>NSAppTransportSecurityNSExceptionDomainsweibo.comNSIncludesSubdomainsNSExceptionRequiresForwardSecrecyNSExceptionAllowsInsecureHTTPLoadsNSAllowsArbitraryLoads

注意：每個需添加的域都需要設(shè)置此三個屬性。如果請求的網(wǎng)絡(luò)圖片是HTTP，也是需要設(shè)置的圖片的域。

注意??這個方案風(fēng)險較大，有可能被拒絕。“需要訪問的域名是第三方服務(wù)器，他們沒有進(jìn)行 HTTPS 對應(yīng)”會是審核時的一個可選理由，但是這應(yīng)該只需要針對特定域名，而非全面開放。如果訪問的是自己的服務(wù)器的話，可能這個理由會無法通過。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

實現(xiàn)方案

1、app內(nèi)服務(wù)器網(wǎng)絡(luò)請求訪問支持https

解決方案：

搭建https服務(wù)器

搭建https服務(wù)器需要ssl證書

ssl自制證書：稱自簽名ssl證書，容易被假冒偽造，瀏覽器不信任。（審核不通過）

免費CA證書：部分CA機(jī)構(gòu)提供免費的SSL證書，如wosign，starts等（App Store pass掉不通過）

付費CA證書：多指企業(yè)級及以上的數(shù)字證書。

HTTPS服務(wù)器滿足ATS默認(rèn)的條件，而且SSL證書是通過權(quán)威的CA機(jī)構(gòu)認(rèn)證過的，那么我們在使用Xcode開發(fā)的時候，對網(wǎng)絡(luò)的適配什么都不用做，我們也能正常與服務(wù)器通信。但是，當(dāng)我們對安全性有更高的要求時或者我們自建證書時，我們需要本地導(dǎo)入證書來進(jìn)行驗證。

使用AFNetworking來支持https

AFNetworking是iOS/OSX開發(fā)最流行的第三方開源庫之一,現(xiàn)在iOS oc 代碼90%以上都是用這個框架網(wǎng)絡(luò)請求。AFNetworking已經(jīng)將上面的邏輯代碼封裝好，甚至更完善，在AFSecurityPolicy文件中，有興趣可以閱讀這個模塊的代碼；以下就是在AFNetworking 2.6.0以前版本和3.0.0版本基于支持https的驗證方式

步驟：

新建一個manager

在mainBundle中尋找我們剛才拖進(jìn)項目中的https.cer, 并且將相關(guān)的數(shù)據(jù)讀取出來

新建一個AFSecurityPolicy，并進(jìn)行相應(yīng)的配置

將這個AFSecurityPolicy 實例賦值給manager

代碼實現(xiàn)：

NSURL* url = [NSURLURLWithString:@"https://www.google.com"];AFHTTPRequestOperationManager * requestOperationManager = [[AFHTTPRequestOperationManager alloc] initWithBaseURL:url];dispatch_queue_trequestQueue = dispatch_create_serial_queue_for_name("kRequestCompletionQueue");requestOperationManager.completionQueue= requestQueue;AFSecurityPolicy * securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];//allowInvalidCertificates 是否允許無效證書（也就是自建的證書），默認(rèn)為NO//如果是需要驗證自建證書，需要設(shè)置為YESsecurityPolicy.allowInvalidCertificates=YES;//validatesDomainName 是否需要驗證域名，默認(rèn)為YES；//假如證書的域名與你請求的域名不一致，需把該項設(shè)置為NO；如設(shè)成NO的話，即服務(wù)器使用其他可信任機(jī)構(gòu)頒發(fā)的證書，也可以建立連接，這個非常危險，建議打開。//置為NO，主要用于這種情況：客戶端請求的是子域名，而證書上的是另外一個域名。因為SSL證書上的域名是獨立的，假如證書上注冊的域名是www.google.com，那么mail.google.com是無法驗證通過的；當(dāng)然，有錢可以注冊通配符的域名*.google.com，但這個還是比較貴的。//如置為NO，建議自己添加對應(yīng)域名的校驗邏輯。securityPolicy.validatesDomainName=YES;//validatesCertificateChain 是否驗證整個證書鏈，默認(rèn)為YES//設(shè)置為YES，會將服務(wù)器返回的Trust Object上的證書鏈與本地導(dǎo)入的證書進(jìn)行對比，這就意味著，假如你的證書鏈?zhǔn)沁@樣的：//GeoTrust Global CA//? ? Google Internet Authority G2//? ? ? ? *.google.com//那么，除了導(dǎo)入*.google.com之外，還需要導(dǎo)入證書鏈上所有的CA證書（GeoTrust Global CA, Google Internet Authority G2）；//如是自建證書的時候，可以設(shè)置為YES，增強(qiáng)安全性；假如是信任的CA所簽發(fā)的證書，則建議關(guān)閉該驗證，因為整個證書鏈一一比對是完全沒有必要（請查看源代碼）；securityPolicy.validatesCertificateChain=NO;requestOperationManager.securityPolicy= securityPolicy;

另afnetworking 3.0.0以上版本用的是AFHTTPSessionManager

AFHTTPSessionManager * manager = [AFHTTPSessionManager manager];NSString* cerPath = [[NSBundlemainBundle] pathForResource:@"server"ofType:@"cer"];NSData* cerData = [NSDatadataWithContentsOfFile:cerPath];NSLog(@"%@", cerData);? ? manager.securityPolicy= [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate withPinnedCertificates:[[NSArrayalloc] initWithObjects:cerData,nil]];? ? manager.securityPolicy.allowInvalidCertificates=YES;? ? [manager.securityPolicysetValidatesDomainName:NO];? ? manager.requestSerializer= [AFJSONRequestSerializer serializer];? ? manager.responseSerializer= [AFJSONResponseSerializer serializer];NSDictionary* parameter = @{@"username":self.username,@"password":self.password};? ? [manager POST:@"https://192.168.1.4:9777"parameters:parameter success:^(NSURLSessionDataTask* task,idresponseObject) {NSLog(@"success %@", responseObject);? ? ? ? }? ? ? ? failure:^(NSURLSessionDataTask* task,NSError* error) {NSLog(@"failure %@", error);? ? ? ? }]

NSAppTransportSecurityNSAllowsArbitraryLoads//設(shè)置為 YES，解除整個app的ATS限制；但是通過NSExceptionDomains進(jìn)行的配置依然有效NSAllowsArbitraryLoadsInMedia//設(shè)置為 YES，解除通過AVFoundation框架訪問媒體內(nèi)容時的 ATS 限制NSAllowsArbitraryLoadsInWebContent//設(shè)置為 YES，解除通過webview發(fā)出的網(wǎng)絡(luò)請求的ATS限制NSAllowsLocalNetworking//設(shè)置為 YES，使得app可以載入任意本地資源，但不影響app的總體 ATS 策略

2、webview內(nèi)支持任意http訪問

對于網(wǎng)頁瀏覽和視頻播放的行為，iOS 10 中新加入了 NSAllowsArbitraryLoadsInWebContent 鍵。通過將它設(shè)置為 YES，可以讓 app 中的 WKWebView 和使用 AVFoundation 播放的在線視頻不受 ATS 的限制。這也應(yīng)該是絕大多數(shù)使用了相關(guān)特性的 app 的選擇。但是壞消息是這個鍵在 iOS 9 中并不會起作用。

如果app只支持 iOS 10，并且有用戶可以自由輸入網(wǎng)址進(jìn)行瀏覽的功能，或者是在線視頻音頻播放功能的話，簡單地加入 NSAllowsArbitraryLoadsInWebContent，并且將組件換成 WKWebKit 或者 AVFoundation 就可以了。如果你還需要支持 iOS 9，并且需要訪問網(wǎng)頁和視頻的話，可能只能去開啟 NSAllowsArbitraryLoads 然后提交時進(jìn)行說明，并且看 Apple 審核員決定讓不讓通過了。

另外，當(dāng) NSAllowsArbitraryLoads 和 NSAllowsArbitraryLoadsInWebContent 同時存在時，根據(jù)系統(tǒng)不同，表現(xiàn)的行為也會不一樣。簡單說，iOS 9 只看 NSAllowsArbitraryLoads，而 iOS 10 會先看 NSAllowsArbitraryLoadsInWebContent。在 iOS 10 中，要是 NSAllowsArbitraryLoadsInWebContent 存在的話，就忽略掉 NSAllowsArbitraryLoads，如果它不存在，則遵循 NSAllowsArbitraryLoads 的設(shè)定

UIWebView 在 NSAllowsArbitraryLoadsInWebContent 為 YES 時訪問 HTTP，無效。WKWebView 在 NSAllowsArbitraryLoadsInWebContent 為 YES 時在iOS 10 中訪問 HTTP，有效，iOS 9無效。如果用WkWebView替換UIWebView，iOS 7 將無法使用WkWebView，可做適配加載，沒有特殊的什么需求的話，盡早將 UIWebView 全部換為 WkWebView 會比較好。所以為了能讓W(xué)ebView在所有版本都能訪問非https內(nèi)容，只能把NSAllowsArbitraryLoads設(shè)置為YES。

解決方案一：

開啟 NSAllowsArbitraryLoads 為 YES，然后提交時進(jìn)行說明

解決方案二：

設(shè)置 NSExceptionDomains 屬性來訪問指定域名，然后提交時進(jìn)行說明

3、第三方sdk接入與支持http訪問

但是按照國內(nèi)的現(xiàn)狀，關(guān)閉這個限制也許是更實際的做法。至于原因就太多了，第三方SDK（幾乎都是訪問http），合作伙伴接入（不能要求它們一定要支持https）

第三方sdk，同樣需要遵守ATS規(guī)則，即第三方sdk也有被ATS過濾的風(fēng)險，微信，qq，分享，登陸功能都能正常，微博登陸不能正常通過。另在網(wǎng)上找到了一些可能存在有問題的sdk，目前已知的有：

友盟 （已經(jīng)有最新的v1.4.0版本sdk，支持https，待驗證）

百度地圖

解決方案一：

更新最新sdk，接入并測試

解決方案二：

可以設(shè)置 NSExceptionDomains屬性來將需要排除強(qiáng)制驗證的域名寫進(jìn)來：

五. 總結(jié)

開啟 NSAllowsArbitraryLoads 為 YES

對第三方訪問的服務(wù)器設(shè)置NSExceptionDomains方式添加白名單

提交審核說明：

必須連接由其他機(jī)構(gòu)控制的服務(wù)器，其還不支持安全連接。

必須通過 web 展示來源不一的各種網(wǎng)絡(luò)內(nèi)容，但又不能完全使用NSAllowsArbitraryLoadsInWebContent所管理的類。

轉(zhuǎn)載：http://www.jianshu.com/p/36ddc5b009a7 ?文／SN_Simon（ 作者） ?

原文鏈接：http://www.jianshu.com/p/36ddc5b009a7

著作權(quán)歸作者所有，轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，并標(biāo)注“ 作者”。

本頁內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁中由涉嫌抄襲的內(nèi)容，請及時與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會在5工作日內(nèi)聯(lián)系您，一經(jīng)查實，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://jstctz.cn/20445.html