iOS app 支持HTTPS iOS開發者相關

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,因此我在前幾天向蘋果開發者中心發了一個郵件，獲得的結果然是出人意料

 

開發者中心郵件.png

這個回覆真是啼笑皆非，一邊提倡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。