iOS app 支持HTTPS iOS开发者相关

2016年12月21日更新开发者中心链接

该链接是苹果昨天刚在官网给的正式回复 如下：

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;

 

双向验证

双向验证的过程我就不说了，因为网上基本全部是双向认证，需要把证书打包到应用的包里，这里贴一个比较详细的链接

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

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