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前端开发他们到底须要作什么,毕竟你们都是刚开始走这个坑,对这个都不算太了解。因此我把作适配的这段时间走的坑总结一下。app

对于HTTPS和HTTP的对比,本篇就再也不做讲解,由于网上有大量的对比,简单的来讲,HTTPS相对于HTTP更安全,更安全的缘由就来自于多出来这个S----SSL证书运维

大体适配流程

(1)这里先说整个过程的大致流程,若是大家的公司有运维的同窗在,那么先让运维的同窗去看一下正规大厂用的是什么类型的SSL证书,额外说一下,如今不少网上有一些免费的证书,还有国内的一些厂商是比较便宜的证书,我不太建议去买这些,由于毕竟此次适配就是为了安全,不如一步到位。这里就再也不介绍自签名一类的了,自签名并无提高真正的安全度,算是模拟了签名的过程。
(2)证书申请成功后,须要后台的同窗配置一下证书,将SSL证书绑定到后台服务上。
(3)前两步不须要前端的同窗完成,前两步完成后,前端的同窗才拿到对应的证书去作前端的适配。若是大家的项目自己就有网络请求管理类,那么只须要对管理类相关的代码进行修改就好了,若是没有,那就须要先封装一个网络请求管理类,而后替换以前的全部网络请求方法(这个过程是反人类的,真但愿你用不到这个办法)ide

iOS app前端详细适配流程

先说一下单向认证和双向认证的区别:单向认证只要求站点部署了ssl证书就行,任何用户均可以去访问(IP被限制除外等),只是服务端提供了身份认证。而双向认证则是须要是服务端须要客户端提供身份认证,只能是服务端容许的客户能去访问,安全性相对于要高一些。工具

其实网上以前我查资料的时候已经发现了,大部分网上的认证都是双向认证,可是他们都错误的理解其为单向认证了。下面说一下app单向认证具体须要作什么。ui

单向验证

//在你封装的网络工具类请求前初始化时增长如下代码
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/f312a84a944cthis

这里只把最关键的代码跟单向认证作一个对比

//在你封装的网络工具类请求前初始化时增长如下代
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。

相关文章
相关标签/搜索