2016年12月21日更新開發者中心鏈接
https://developer.apple.com/news/?id=12212016b
該鏈接是蘋果昨天剛在官網給的正式回覆 如下：

App Transport Security (ATS), introduced in iOS 9 and OS X v10.11, improves user security and privacy by requiring apps to use secure network connections over HTTPS. At WWDC 2016 we announced that apps submitted to the App Store will be required to support ATS at the end of the year. To give you additional time to prepare, this deadline has been extended and we will provide another update when a new deadline is confirmed. Learn more about ATS.

這個東西是為了讓大家放心 17年1月1日 不是蘋果最終的deadline 推遲了，下麵的步驟是iOS前端適配https 的全部步驟 按照步驟配置即可（不要再被網上傳的強制https的文章洗腦了，都是ssl證書頒發機構的軟文）

自從2016年的WWDC大會結束後，就出來個消息說，蘋果方面在2017年1月1日要開始全面支持https了，也就是說原來繞過ATS的方法不行了。沒有取巧的方式那就只能按照正規的流程來一遍了，這幾天把這個坑搞明白了，其實整個過程前端並不需要做太多東西，但是我還是把整個流程熟悉了一遍，這樣也算是蘋果做的一個強制，為整個安全領域推進了一步。

剛開始我也是在網上找了一些教程，但是最後感覺網上的這些流程都或多或少有些問題，而且並不能告訴app前端開發他們到底需要做什麼，畢竟大家都是剛開始走這個坑，對這個都不算太瞭解。所以我把做適配的這段時間走的坑總結一下。

對於HTTPS和HTTP的對比，本篇就不再作講解，因為網上有大量的對比，簡單的來說，HTTPS相對於HTTP更安全，更安全的原因就來自於多出來這個S----SSL證書

大致適配流程

（1）這裡先說整個過程的大體流程，如果你們的公司有運維的同學在，那麼先讓運維的同學去看一下正規大廠用的是什麼類型的SSL證書，額外說一下，現在很多網上有一些免費的證書，還有國內的一些廠商是比較便宜的證書，我不太建議去買這些，因為畢竟這次適配就是為了安全，不如一步到位。這裡就不再介紹自簽名一類的了，自簽名並沒有提升真正的安全度，算是模擬了簽名的過程。
（2）證書申請成功後，需要後臺的同學配置一下證書，將SSL證書綁定到後臺服務上。
（3）前兩步不需要前端的同學完成，前兩步完成後，前端的同學才拿到對應的證書去做前端的適配。如果你們的項目本身就有網路請求管理類，那麼只需要對管理類相關的代碼進行修改就行了，如果沒有，那就需要先封裝一個網路請求管理類，然後替換之前的所有網路請求方法（這個過程是反人類的，真希望你用不到這個辦法）

iOS app前端詳細適配流程

先說一下單向認證和雙向認證的區別：單向認證只要求站點部署了ssl證書就行，任何用戶都可以去訪問（IP被限制除外等），只是服務端提供了身份認證。而雙向認證則是需要是服務端需要客戶端提供身份認證，只能是服務端允許的客戶能去訪問，安全性相對於要高一些。

其實網上之前我查資料的時候已經發現了，大部分網上的認證都是雙向認證，但是他們都錯誤的理解其為單向認證了。下麵說一下app單向認證具體需要做什麼。

單向驗證

//在你封裝的網路工具類請求前初始化時增加以下代碼
AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
//設置證書模式，AFSSLPinningModeNone，代表前端包內不驗證
//在單向認證時，前端不放證書，伺服器去驗證
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
// 如果是需要服務端驗證證書，需要設置為YES
securityPolicy.allowInvalidCertificates = YES;
//validatesDomainName 是否需要驗證功能變數名稱，預設為YES；
securityPolicy.validatesDomainName = NO;
//設置驗證模式
manager.securityPolicy = securityPolicy;

雙向驗證

雙向驗證的過程我就不說了，因為網上基本全部是雙向認證，需要把證書打包到應用的包里，這裡貼一個比較詳細的鏈接http://www.jianshu.com/p/f312a84a944c

這裡只把最關鍵的代碼跟單向認證做一個對比

//在你封裝的網路工具類請求前初始化時增加以下代
AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
//設置驗證證書，該模式下許願把證書打包進項目里，進行驗證
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
//證書的路徑
NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"xxx" ofType:@".cer"];
NSData *dataSou = [NSData dataWithContentsOfFile:cerPath];
NSSet *set = [NSSet setWithObjects:dataSou, nil];
securityPolicy.allowInvalidCertificates = YES;
securityPolicy.validatesDomainName = YES;
[securityPolicy setPinnedCertificates:set];
//將驗證方式賦值給管理者
manager.securityPolicy = securityPolicy;

兩類驗證方式的最大區別其實在於，是否需要把證書打包進入應用內。

跟著這個問題隨之而來的就有另外的幾個問題，對於app前端開發來說，究竟選擇何種驗證方式比較好呢。其實對於app來說，單向驗證是最方便的，也是安全的，雙向驗證比單向來說更安全，但是對於app開發來說有幾個問題需要面對。所以下麵列一下單向和雙向的優點和缺點，你可以選擇最合適的方式來處理。

單向優點

1.更加靈活，客戶端不需要把相應證書打包進入app內，這個SSL證書是有過期時間的，如果過期了，只需要伺服器端修改證書即可，不會出現突然有一天莫名其妙app打不開了的問題。
2.雖然兩種驗證方法對於前端來說並沒有太多工作了，但是相對來說單向對於服務端和前端來說更簡單。

雙向優點

1.更加安全。但是相對來說開發成本更高

對比之後，我們的app最終選擇單向驗證的方式。更多的是為了避免如果修改了證書的廠家這種意外事件的處理，避免不必要的麻煩。

總結

其實對於前端來說，並沒有太多的工作量，重點是對於整個過程的理解和方式的選擇。所以也不要害怕17年的全面https的問題。

下麵是我自己個人的疑問，因為不確定明年的plist裡面的ATS是不是在提交應用的時候Allow Arbitrary Loads是不是必須不要設置或者設置為NO,所以我在前幾天向蘋果開發者中心發了一個郵件，得到的結果真是出人意料

這個回覆真是哭笑不得，一邊提倡https 一邊說現在還沒有對開發者做限制。不過管他呢，https是一個趨勢，先做了，一步到位就行，明年的Allow Arbitrary Loads 照樣上傳應用的時候設置YES了，17年1月1日到底蘋果是不是強制要求不讓這麼繞過，也不能確定。

這個坑過去了，但是ATS是對UIWebView和WKWebView有影響的，如果Allow Arbitrary Loads設置為NO, Allow Arbitrary Loads in Web Content不設置，那麼UIWebView和WKWebView不能正常的顯示，因為載入網頁也是需要基於http和https協議的。所以需要將Allow Arbitrary Loads in Web Content設置為YES。