iOS10 适配 ATS（app支持https通过App Store审核） 韩俊强的博客

每日更新关注:http://weibo.com/hanjunqiang  新浪微博！iOS开发者交流QQ群： 446310206

一. HTTPS

其实HTTPS从最终的数据解析的角度，与HTTP没有任何的区别，HTTPS就是将HTTP协议数据包放到SSL/TSL层加密后，在TCP/IP层组成IP数据报去传输，以此保证传输数据的安全；而对于接收端，在SSL/TSL将接收的数据包解密之后，将数据传给HTTP协议层，就是普通的HTTP数据。HTTP和SSL/TSL都处于OSI模型的应用层。从HTTP切换到HTTPS是一个非常简单的过程，在做具体的切换操作之前，我们需要了解几个概念：

SSL/TLS

为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，今后TLS将会继承SSL优良血统继续为我们进行加密服务。

简单的来说，SSL/TSL通过四次握手。SSL协议的工作流程：

服务器认证阶段：

客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；
服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；
客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；
服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。

用户认证阶段：

在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。
经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。

二. App Transport Security

iOS9中新增App Transport Security（简称ATS）特性, 主要使到原来请求的时候用到的HTTP，都转向TLS1.2协议进行传输。这也意味着所有的HTTP协议都强制使用了HTTPS协议进行传输。在 iOS 9 和 OS X 10.11 中，默认情况下非 HTTPS 的网络访问是被禁止的。当然，因为这样的推进影响面非常广，作为缓冲，我们可以在 Info.plist 中添加 NSAppTransportSecurity 字典并且将 NSAllowsArbitraryLoads 设置为 YES 来禁用 ATS。

不过，WWDC 16 中，Apple 表示将继续在 iOS 10 和 macOS 10.12 里收紧对普通 HTTP 的访问限制。从 2017 年 1 月 1 日起，所有的新提交 app 默认是不允许使用 NSAllowsArbitraryLoads 来绕过 ATS 限制的，也就是说，我们最好保证 app 的所有网络请求都是 HTTPS 加密的，否则可能会在应用审核时遇到麻烦。

三. iOS10 NSAppTransportSecurity

通过在info.plist中配置这个键，开发者可以自定义网络安全策略。例如：

允许针对个别服务器的不安全访问。
允许不安全的 web 或媒体内容访问，但不影响整个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 配置基础知识

对于使用 iOS9.0， OS X v10.11 SDK 及以上的 app 来说，ATS（App Transport Security）默认开启，NSAllowsArbitraryLoads是字典NSAppTransportSecurity的根键，默认值NO。

在启用 ATS 的情况下，所有的 HTTP 请求必须为 HTTPS（RFC 2818） 连接。任何不安全的 HTTP 请求都将失败。ATS 使用 TLS（Transport Layer Security）v1.2（RFC 5246）。

下面是字典NSAppTransportSecurity的总体结构，所有键都是非必填项：

NSAppTransportSecurity : Dictionary {
    NSAllowsArbitraryLoads : Boolean
    NSAllowsArbitraryLoadsInMedia : Boolean
    NSAllowsArbitraryLoadsInWebContent : Boolean
    NSAllowsLocalNetworking : Boolean
    NSExceptionDomains : Dictionary {
        <domain-name-string> : Dictionary {
            NSIncludesSubdomains : Boolean
            NSExceptionAllowsInsecureHTTPLoads : Boolean
            NSExceptionMinimumTLSVersion : String
            NSExceptionRequiresForwardSecrecy : Boolean   // Default value is YES
            NSRequiresCertificateTransparency : Boolean
        }
    }
}

可以看出，所有键可以分为两类：主键，这些键用来定义 app 的总体 ATS 策略；子键，即NSExceptionDomains下面的键，使用这些键针对某个域名单独配置。

主键包括：

  • NSAllowsArbitraryLoads

    设置为 YES，解除整个 app 的 ATS 限制；但是，通过NSExceptionDomains进 行的配置依然有效。默认值为 NO。
    注意：设置为 YES，会引发 App Stroe 的审查，开发者必须说明原因。

  • NSAllowsArbitraryLoadsInMedia

    设置为 YES，解除通过 AV Foundation 框架访问媒体内容时的 ATS 限制；启用这个 键，务必确保载入的媒体内容已经被加密，例如受FairPlay保护的文件，或者是安全的 HLS流媒，其中不包含敏感的个人信息。默认为 NO。

  • NSAllowsArbitraryLoadsInWebContent

    设置为 YES，解除通过 web view 发出的网络请求的 ATS 限制。启用这个键，可以使 app 访问任意网页内容，但不影响 app 的总体 ATS 策略。此键值默认为 NO。

  • NSAllowsLocalNetworking

    设置为 YES，使得 app 可以载入任意本地资源，但不影响 app 的总体 ATS 策略。默 认为 NO。

  • NSExceptionDomains

    为一个或多个域名单独配置 ATS。
    被单独配置的域名，默认受到完全的 ATS 限制，不管NSAllowsArbitraryLoads的值 如何；需要通过子键，进一步配置

所有的子键都属于NSExceptionDomain。向Info.plist中添加这一主键：

  • 创建字典，针对一个或多个域名，以便进行 ATS 配置。
  • 这意味着之前使用主键所做的设置，对于这个域名来说，已经无效。

例如，及时之前设置NSAllowsArbitraryLoadsInMedia为 YES，然而NSExceptionDomain所代表的域名依然不能访问不安全的媒体内容。

基于这样的设定，可以针对域名进行 ATS 配置，增加或减少安全措施。例如：

  • 将NSExceptionAllowsInsecureHTTPLoads设置为 YES，就 ；这样做会引发 App Store 的审查，详情见App Store Review for ATS。
  • 通过配置NSExceptionRequiresForwardSecrecy为 NO，取消正向保密。
  • 通过配置NSExceptionMinimumTLSVersion，更改 TLS 最低版本。

NSExceptionDomains字典构成：

  • <域名字符串>
    代表想要配置的特定域名。可以添加多个域名（即添加多个这样的键），为它们统一配置 ATS 策略。这个键对应一个字典，包含以下子键：

    • NSIncludesSubdomains

      * 设置为 YES，当前域名的 ATS 策略适用于其所有子域名。默认为 NO。
    • NSExceptionAllowsInsecureHTTPLoads 
      * 设置为 YES，可以同时通过 HTTP 和 HTTPS 访问当前域名。默认为 NO。
注意，配置这个键值，将引发 App Store 的审查，开发者必须说明原因。
    • NSExceptionMinimumTLSVersion 
      * 指定 TLS 的最低版本，因此可以使用版本较低，有安全漏洞的 TLS 协议。
注意，配置这个键值，将引发 App Store 的审查，开发者必须说明原因。
    • NSExceptionRequiresForwardSecrecy 
      * 设置为 NO，允许针对当前域名使用不支持正向保密的 TLS 加密算法。默认为 YES。
    • NSRequiresCertificateTransparency 
      * 设置为 YES，将验证域名服务器证书的Certificate Transparency时间戳 。默认为 NO。

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

在 ATS 完全开启的情况下，系统要求 app 的 HTTPS 连接必须满足以下要求：

X.509 数字证书必须满足下列标准中的一项：

  • 由操作系统内嵌的根证书颁发机构签发

    • 由通过操作系统管理员或用户主动安装的根证书颁发机构签发

      • 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
  • 服务端的叶证书签名密钥必须为下面之一：
    • 至少2048位的 RSA 密钥
    • 至少256位的 ECC 密钥
    • 此外，服务器证书的哈希算法必须为 SHA-2，其摘要长度至少位256位（即 SHA-256 及以上）。
      上面的标准，未来可能会发生变化。但不会影响到 app 二进制包的兼容性。

App Store Review for ATS / App Store 对于 ATS 相关项的审核

某些对 ATS 的配置会引发 App Store 的审核，开发者必须说明原因。这些键有：

  • NSAllowsArbitraryLoads
  • NSExceptionAllowsInsecureHTTPLoads
  • NSExceptionMinimumTLSVersion

以下是一些原因说明例子，供参考：

  • 必须连接由其他机构控制的服务器，其还不支持安全连接。
  • 必须支持那些还未升级至可使用安全连接，不得不通过公共域名访问网络的设备。
  • 必须通过 web 展示来源不一的各种网络内容，但又不能完全使用NSAllowsArbitraryLoadsInWebContent所管理的类。

向 App Store 提交审核时，开发者应主动提供足够的信息，以便解释 app 无法使用安全连接的原因。

四. 实现支持安全ATS策略

<font color=red size=5>ATS相关设置对iOS8及以下系统无效</font>

需要解决的问题（iOS 9、iOS10及以上）

1、app内服务器网络请求访问支持https（即一般的请求）

2、webview内支持任意http访问

3、第三方sdk接入与支持http访问

主要是围绕info.pilst配置文件作相关的安全ATS策略

Info.plist文件是向操作系统描述应用程序的XML属性列表,是iPhone应用程序文件夹包含所有重要的Info.plist文件

你可能注意到一些关键字像是使用了一些其他关键字中的词但是在前面加上了"ThirdParty"字样，在功能上，这些关键字与不含有"ThirdParty"的关键字有同样的效果。而且实际运行中所调用的代码将会完全忽略是否使用"ThirdParty"关键字。

简单粗暴的方案：

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

NSExceptionDomains 的设置方法如下, 比如我们要将 weibo.com 这个域名排除在 ATS 验证之外，就可以这样：

key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>weibo.com</key>
        <dict>
            <key> NSIncludesSubdomains </key>
            <true/>
            <key> NSExceptionRequiresForwardSecrecy </key>
            <false/>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
        </dict>
    </dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

注意：每个需添加的域都需要设置此三个属性。如果请求的网络图片是HTTP，也是需要设置的图片的域。

注意??这个方案风险较大，有可能被拒绝。“需要访问的域名是第三方服务器，他们没有进行 HTTPS 对应”会是审核时的一个可选理由，但是这应该只需要针对特定域名，而非全面开放。如果访问的是自己的服务器的话，可能这个理由会无法通过。

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

实现方案

1、app内服务器网络请求访问支持https

解决方案：

搭建https服务器

搭建https服务器需要ssl证书

  1. ssl自制证书：称自签名ssl证书，容易被假冒伪造，浏览器不信任。（审核不通过）
  2. 免费CA证书：部分CA机构提供免费的SSL证书，如wosign，starts等（App Store pass掉不通过）
  3. 付费CA证书：多指企业级及以上的数字证书。

HTTPS服务器满足ATS默认的条件，而且SSL证书是通过权威的CA机构认证过的，那么我们在使用Xcode开发的时候，对网络的适配什么都不用做，我们也能正常与服务器通信。但是，当我们对安全性有更高的要求时或者我们自建证书时，我们需要本地导入证书来进行验证。

使用AFNetworking来支持https

AFNetworking是iOS/OSX开发最流行的第三方开源库之一,现在iOS oc 代码90%以上都是用这个框架网络请求。AFNetworking已经将上面的逻辑代码封装好，甚至更完善，在AFSecurityPolicy文件中，有兴趣可以阅读这个模块的代码；以下就是在AFNetworking 2.6.0以前版本和3.0.0版本基于支持https的验证方式

步骤：

  1. 新建一个manager
  2. 在mainBundle中寻找我们刚才拖进项目中的https.cer, 并且将相关的数据读取出来
  3. 新建一个AFSecurityPolicy，并进行相应的配置
  4. 将这个AFSecurityPolicy 实例赋值给manager

代码实现：

NSURL * url = [NSURL URLWithString:@"https://www.google.com"];
AFHTTPRequestOperationManager * requestOperationManager = [[AFHTTPRequestOperationManager alloc] initWithBaseURL:url];
dispatch_queue_t requestQueue = dispatch_create_serial_queue_for_name("kRequestCompletionQueue");
requestOperationManager.completionQueue = requestQueue;

AFSecurityPolicy * securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];

//allowInvalidCertificates 是否允许无效证书（也就是自建的证书），默认为NO
//如果是需要验证自建证书，需要设置为YES
securityPolicy.allowInvalidCertificates = YES;

//validatesDomainName 是否需要验证域名，默认为YES；
//假如证书的域名与你请求的域名不一致，需把该项设置为NO；如设成NO的话，即服务器使用其他可信任机构颁发的证书，也可以建立连接，这个非常危险，建议打开。
//置为NO，主要用于这种情况：客户端请求的是子域名，而证书上的是另外一个域名。因为SSL证书上的域名是独立的，假如证书上注册的域名是www.google.com，那么mail.google.com是无法验证通过的；当然，有钱可以注册通配符的域名*.google.com，但这个还是比较贵的。
//如置为NO，建议自己添加对应域名的校验逻辑。
securityPolicy.validatesDomainName = YES;
//validatesCertificateChain 是否验证整个证书链，默认为YES
//设置为YES，会将服务器返回的Trust Object上的证书链与本地导入的证书进行对比，这就意味着，假如你的证书链是这样的：
//GeoTrust Global CA
//    Google Internet Authority G2
//        *.google.com
//那么，除了导入*.google.com之外，还需要导入证书链上所有的CA证书（GeoTrust Global CA, Google Internet Authority G2）；
//如是自建证书的时候，可以设置为YES，增强安全性；假如是信任的CA所签发的证书，则建议关闭该验证，因为整个证书链一一比对是完全没有必要（请查看源代码）；
securityPolicy.validatesCertificateChain = NO;

requestOperationManager.securityPolicy = securityPolicy;

另afnetworking 3.0.0以上版本用的是AFHTTPSessionManager

 AFHTTPSessionManager * manager = [AFHTTPSessionManager manager];
    NSString * cerPath = [[NSBundle mainBundle] pathForResource:@"server" ofType:@"cer"];
    NSData * cerData = [NSData dataWithContentsOfFile:cerPath];
    NSLog(@"%@", cerData);
    manager.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate withPinnedCertificates:[[NSArray alloc] initWithObjects:cerData, nil]];
    manager.securityPolicy.allowInvalidCertificates = YES;
    [manager.securityPolicy setValidatesDomainName: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, id responseObject) {
        NSLog(@"success %@", responseObject);
        }
        failure:^(NSURLSessionDataTask * task, NSError * error) {
            NSLog(@"failure %@", error);
        }]

    <key>NSAppTransportSecurity</key>
    <dict>
        <key>NSAllowsArbitraryLoads</key> //设置为 YES，解除整个app的ATS限制；但是通过NSExceptionDomains进行的配置依然有效
        <false/>
        <key>NSAllowsArbitraryLoadsInMedia</key> //设置为 YES，解除通过AVFoundation框架访问媒体内容时的 ATS 限制
        <true/>
        <key>NSAllowsArbitraryLoadsInWebContent</key> //设置为 YES，解除通过webview发出的网络请求的ATS限制
        <true/>
        <key>NSAllowsLocalNetworking</key> //设置为 YES，使得app可以载入任意本地资源，但不影响app的总体 ATS 策略
        <true/>

2、webview内支持任意http访问

对于网页浏览和视频播放的行为，iOS 10 中新加入了 NSAllowsArbitraryLoadsInWebContent 键。通过将它设置为 YES，可以让 app 中的 WKWebView 和使用 AVFoundation 播放的在线视频不受 ATS 的限制。这也应该是绝大多数使用了相关特性的 app 的选择。但是坏消息是这个键在 iOS 9 中并不会起作用。

如果app只支持 iOS 10，并且有用户可以自由输入网址进行浏览的功能，或者是在线视频音频播放功能的话，简单地加入 NSAllowsArbitraryLoadsInWebContent，并且将组件换成 WKWebKit 或者 AVFoundation 就可以了。如果你还需要支持 iOS 9，并且需要访问网页和视频的话，可能只能去开启 NSAllowsArbitraryLoads 然后提交时进行说明，并且看 Apple 审核员决定让不让通过了。

另外，当 NSAllowsArbitraryLoads 和 NSAllowsArbitraryLoadsInWebContent 同时存在时，根据系统不同，表现的行为也会不一样。简单说，iOS 9 只看 NSAllowsArbitraryLoads，而 iOS 10 会先看 NSAllowsArbitraryLoadsInWebContent。在 iOS 10 中，要是 NSAllowsArbitraryLoadsInWebContent 存在的话，就忽略掉 NSAllowsArbitraryLoads，如果它不存在，则遵循 NSAllowsArbitraryLoads 的设定

UIWebView 在 NSAllowsArbitraryLoadsInWebContent 为 YES 时访问 HTTP，无效。WKWebView 在 NSAllowsArbitraryLoadsInWebContent 为 YES 时在iOS 10 中访问 HTTP，有效，iOS 9无效。如果用WkWebView替换UIWebView，iOS 7 将无法使用WkWebView，可做适配加载，没有特殊的什么需求的话，尽早将 UIWebView 全部换为 WkWebView 会比较好。所以为了能让WebView在所有版本都能访问非https内容，只能把NSAllowsArbitraryLoads设置为YES。

解决方案一：

开启 NSAllowsArbitraryLoads 为 YES，然后提交时进行说明

解决方案二：

设置 NSExceptionDomains 属性来访问指定域名，然后提交时进行说明

3、第三方sdk接入与支持http访问

但是按照国内的现状，关闭这个限制也许是更实际的做法。至于原因就太多了，第三方SDK（几乎都是访问http），合作伙伴接入（不能要求它们一定要支持https）

第三方sdk，同样需要遵守ATS规则，即第三方sdk也有被ATS过滤的风险，微信，qq，分享，登陆功能都能正常，微博登陆不能正常通过。另在网上找到了一些可能存在有问题的sdk，目前已知的有：

  • 友盟 （已经有最新的v1.4.0版本sdk，支持https，待验证）
  • 百度地图

解决方案一：

更新最新sdk，接入并测试

解决方案二：

可以设置 NSExceptionDomains属性来将需要排除强制验证的域名写进来：

五. 总结

开启 NSAllowsArbitraryLoads 为 YES

对第三方访问的服务器设置NSExceptionDomains方式添加白名单

提交审核说明：

  • 必须连接由其他机构控制的服务器，其还不支持安全连接。
  • 必须通过 web 展示来源不一的各种网络内容，但又不能完全使用NSAllowsArbitraryLoadsInWebContent所管理的类。

每日更新关注:http://weibo.com/hanjunqiang  新浪微博！iOS开发者交流QQ群： 446310206

时间： 2024-10-10 00:10:02

iOS10 适配 ATS（app支持https通过App Store审核） 韩俊强的博客的相关文章

笔记类app之Leanote同步机制 韩俊强的博客

背景 最近在移动开发App时遇到一个问题:在服务端与客户端之间需要进行修改,删除,更新,添加等操作同步,为此研究了一番,其中Leanote参考了印象笔记App的同步原理. Leanote同步机制参考Evernote的机制, 关于Evernote的同步机制参考: http://dev.evernote.com/media/pdf/edam-sync.pdf 前言 Leanote主要由Notebook, Note, Tag, File(图片/附件)组成. File依附于Note存在. 当Note删除

iOS中 iOS10 权限崩溃问题 韩俊强的CSDN博客

iOS10 权限崩溃问题 每日更新关注:http://weibo.com/hanjunqiang  新浪微博! 今天 手机升级了 iOS10 Beta,然后用正在开发的项目 装了个ipa包,发现点击有关 权限访问 直接Crash了,并在控制台输出了一些信息: This app has crashed because it attempted to access privacy-sensitive data without a usage description.  The app's Info.

APP如何推广?策划APP推广方案的好方法

说实话,手机APP推广策划是一件很烧脑的事情,特别是像我这样的草 根站长出身,技术基础差财务底子薄,所以一开始就喜欢简单容易上手的方法,就像网站流量就会搞SEO,但是到了移动端,发现玩法和网站很不一样,APP版 本又分为苹果iOS和谷歌Android两种类型,每个版本APP推广渠道都很多,记得几年前在松松博客上看到一篇介绍Android渠道的文章,光国内 的分发渠道就几百个,当时的心情就是两个字:呵呵. 两年前,大家都说移动是未来,我想我还年轻,不能落伍要上进,就像我打英雄联盟的状 态:虽然只有

安卓开发笔记——打造属于自己的博客园APP（二）

在上一篇文章<安卓开发笔记——打造属于自己的博客园APP(一)>中,我们基本上实现了博客园的主体UI框架(后面可能会有些小变化,等遇到了再说).今天来讲讲博客园首页模块的大体实现,国际惯例,先来看下效果图: 整体UI效果: 下拉刷新和上拉加载的动画效果: 在上篇文章中,我们定义的Tabs主题文字分别是(首页,精华,候选,推荐),这边的命名我是根据博客园网站首页的栏目来命名的,那时候我还没仔细看过博客园的开放接口,后来才发现原来博客园没有对应开放这些栏目的接口,博客园只开放了(文章列表,48小时

基于Laravel支持markdown的博客VienBlog

# laravel-blogVien Blog - 一款基于laravel5.8开发的,支持markdown编辑以及图片拖拽上传的博客系统.SEO友好 ## 廉价域名 [Namesilo](https://viencoding.com/article/187) 超级便宜,不到6刀一年,续费也便宜,比国内某些注册商便宜好多呢. ## 廉价服务器 [Bandwagon](https://viencoding.com/bandwagonhost) 优惠码每天更新 [Vultr](https://vie

【CSDN博客之星】成功连任2013年CSDN年度博客之星，非常感谢大家的支持 祝大家新春快乐

分享一下我老师大神的人工智能教程吧.零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!http://www.captainbed.net 各位读者好, 本人博客开通2年半以来发表技术文章152篇(全部原创),访问量152万.博客文章通俗易懂,图文并茂,<秒杀多线程面试题系列>,<白话经典算法系列>,<C++ STL>,<Windows C/C++/C#>等专栏不仅受读者们喜爱,也受多家编辑约稿.    在2013年中,离开校园步入

解决企业In-House安装APP需HTTPS支持的问题

问题背景: 能否通过应用服务器发布企业应用: 解决iOS7.1后,发布地址必须为HTTPS服务器. 写作目的: 在SAE(Sina App Engine)作为第三方服务器,实现APP的发布. 适合阅读对象: 想通过不自己搭建HTTPS服务器(对于个人开发者来说,略显昂贵的费用),实现应用的下载和安装. 不涉及内容: 企业应用的打包问题.关于企业打包,请参照iOS APP企业打包流程. SAE地址: SAE 正文: 首先介绍下苹果开发的三种计划,分为个人,企业和大学计划.如图所示: 主要区别就是:

苹果强制使用HTTPS传输了怎么办？——关于HTTPS，APP开发者必须知道的事(转)

WeTest 导读 2017年1月1日起,苹果公司将强制使用HTTPS协议传输.本文通过对HTTPS基础原理和通信过程内容的讲解,介绍APP开发者在这个背景下的应对办法. 几周前,我们在<https大势已来?看腾讯专家如何在高并发压测中支持https>中介绍了腾讯WeTest在基于epoll的高并发机器人框架中加入openssl的方法支持HTTPS接口测试的方法,不仅介绍了具体的使用办法,并且了解到HTTPS注定会是未来的主流趋势. 而随着2016年行将结束,我们发现,这一天,已经越来越近了.

anyproxy-windows平台安装和抓手机app上https请求

前言 做接口测试肯定离不开抓包,目前比较流行的抓包工具是fiddler和charles,相信并不陌生.这里介绍一个阿里公司研发的一个抓包神器,只需打开web页面,就能抓到手机app上的http和https请求了.这样就有个好处,当一个公司测试团队有多个人的时候,只需搭建一个AnyProxy服务,其它小伙伴浏览器上打开AnyProxy页面,手机上设置个代理就能刷刷刷的抓到请求了.解决了部分人电脑不正经的小伙伴fiddler死活抓不到https请求的问题,也解决了破解charles安装的问题,也不用