苹果手机连接Wifi认证机制
Posted kekeoutlook
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了苹果手机连接Wifi认证机制相关的知识，希望对你有一定的参考价值。
Wifi状态保持方法和nas设备
https://patents.google.com/patent/CN106793171A/zh
基于ios终端的离线wifi热点认证方法和认证系统
https://patents.google.com/patent/CN105245540A/zh
一种简单的基于HTTP重定向的Captive Portal实现
当网关收到来自客户端的HTTP请求，例如：
GET http://www.example.com/
网关可以返回如下内容给客户端：
<meta HTTP-EQUIV=‘REFRESH‘ content=‘0; url=http://<your auth server ip>/login‘>
关于Apple的Captive Network Assistant
在WIFI的应用场景中，有个很典型的应用，叫做Captive Portal，也叫Captive Web Portal（CWP）。
大致流程是：
用户的移动设备（例如手机）接入WIFI。
打开任意网页。
得到一个类似Login的页面，需要用户填写一些信息，然后提交。
认证通过后，允许自由访问网络，否则无法上网。
电信、移动等运营商经常会推出一些市区里的WIFI，很多用的就是这种方式。还有像机场等地。有个典型的应用，就是杭州的ihangzhou。
iOS，还有Mac OS，都有个功能，当接入无线网络后，会自动检测网络是否通。如果不通，则会自动弹出一个页面，让用户去登录。
Apple把这种功能叫做Captive Network Assistant（CNA）。
其原理如下：
发送一个HTTP/1.0的请求到 http://www.apple.com/library/test/success.html
接收一个回应，如果回应跟它预计的结果一致，那么认为网络是通的，就不会自动弹出页面。同时，状态栏的WIFI图标出现。流程结束。否则，进入下一步。
如果收到的回应不是它想要的那个，它就认为有CWP存在。
如果有CWP存在，iOS就会自动打开一个页面，在这个页面中再请求一次http://www.apple.com/library/test/success.html，这一次，使用的是HTTP/1.1。
然后就可以打开Login页面了。
在第2步中，如果有CWP存在，收到的回应通常是一个Login页面，这个和第5步收到的结果应该是一样的。
如果网络能，则可以收到下面的回应。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
只是第2步中，iOS是如何判断的，不得而知。不过只要保证收到上面的响应，则一定能通。
那么，第2步中如果没有收到响应，或是收到了非HTTP 200的响应又会如何呢？
根据我的测试，如果没收到响应，依然会弹出一个窗口。不过，这不是一种正常的CWP状态。
非HTTP 200的情况，我只试了HTTP 302重定向。在这种情况下，iOS不会自动弹出Login页面。
在上面的5步中，得到了一个Login页面，然后又会发生什么呢？
用户拿到Login页面后，应该填写一些信息，并且提交。iOS会在用户提交后，立即发一边第1步中的请求，再次检测网络。如果此时网络还是不通，iOS会自动断开当前的SSID。不过这个行为好像有点不稳定，具体就不细说了。
网络通了后，在iOS上基本有2个现象。一是右上角的“取消”按钮变成”完成“，或是自动关闭这个窗口，行为似乎不太一致。最关键的是顶端状态栏WIFI图标的出现。
从现象上看，只要WIFI图标不出来，iOS就不允许有流外出（部分特殊的除外）。
********** 副作用 **********
iOS的这种行为，其实没给用户多少方便，却会带来不少麻烦。我记得在iOS 4时，还可以选择是否启用auto-login。不过iOS 6已经没有这个选项了。
理论上讲，这个功能最麻烦的就是要保证你所在的网络可以访问http://www.apple.com/library/test/success.html。如果仅仅是在公司内部网络，不允许访问外网，那么iOS就无法连接了。
【题外话】在iOS 5以前，只有open的SSID才会发test请求。（open的SSID指的是没有802.1X或PSK认证的）。而从iOS 6开始，连上非open的网络也会发这个test了。
所以，在这种内网的情况下，需要防火墙开放www.apple.com的访问，或是WIFI AP可以支持避开CNA的检测。
我一直没在网上找到关于CNA的判断标准，不知道Apple搞这么个东西干吗。
********** 测试结果 **********
写完此文，心里一直痒痒的，想知道第2步究竟是怎么判断的。于是立即动手测试。
我发现，只要响应页面中，<TITLE>的值是Success，大小写敏感，就可以欺骗iOS了。
测了iOS 6.0和Mac OS 10.7，结果都一样。这下我心里释怀了。不知道新版本会不会有变化。该死的苹果。
---------------------
作者：permike
来源：CSDN
原文：https://blog.csdn.net/permike/article/details/47417317
版权声明：本文为博主原创文章，转载请附上博文链接！
[0035] 实施例1、
[0036] 本发明实施例提供了一种WIFI状态保持方法，参照图3中所示，包括：
[0037] S20UNAS设备接收I0S终端发送的探测报文，探测报文用于探测苹果服务器是否 可达。
[0038] S202、当判断接收到探测报文为I0S终端显示Portal认证界面之后的探测报文时， NAS设备构造并响应第一响应报文，其中，第一响应报文的主体部分指示苹果服务器响应成 功。
[0039] 当I0S终端显示Portal认证界面之后，如果探测报文探测苹果服务器可达，则会保 持WIFI连接，并点亮WIFI图标，不会因为用户离开Portal认证界面导致认证过程中断。本发 明实施例即利用NAS设备来构造并响应一个响应报文，提前指示苹果服务器可达，以提前实 现上述目的。
[0040] 本发明实施例提供的WIFI状态保持方法，由NAS设备针对I0S终端在显示Portal认 证界面之后的探测报文来构造一个响应报文，使得I0S终端认为探测成功，从而使WIFI图标 提前被点亮，并且不会因为用户离开Portal认证界面而中断WIFI连接，解决了 I0S终端由于 自身CNA机制，在认证通过前离开Portal页面时会导致该I0S终端自动断开WIFI的问题。 [0041] 实施例2、
[0042] 本发明实施例提供了另一种WIFI状态保持方法，参照图4中所示，包括：
[0043] S301、I0S 终端连接 WIFI 后，主动向 NAS 设备发起 DHCP (dynamic host conf iguration protocol，动态主机配置协议）Discover (发现）报文，请求获取ip (internet protocol，网络协议）地址。
[0044] S3〇2、NAS设备收到IOS终端发起的DHCP Discover报文后，为该IOS终端分配IP地 址，同时记录I0S终端的MAC地址并初始化接收到来自该l〇s终端的HTTP 1 .OGet hotspot-detect.html探测报文的状态标识。
[0045] 具体的，可以预先创建一张I0S终端CNA探测状态表，每条记录包括MAC地址字段和 状态标识（Status)字段。在NAS设备收到I0S终端发起的DHCP Discover报文后，在上述I0S 终端CNA探测状态表中写入一条数据:MAC地址字段中记录I0S终端MAC，状态标识字段设置 为0,其中，Status字段指不NAS设备首次接收到该I0S终端所发送的HTTP 1 .OGet hotspot-detect .html探测报文的状态。
[0046] 3303、103终端获取到财3设备分配的1?地址后，发起111^?1.(^以11的邛〇七- detect. html探测报文。
[0047] 通常I 0 S终端的探测地址为：c a p t i ve.apple.com、www.airport.us、 www.ibook.infonwww.thinkdifferent.us>www.appleiphonecel1.com>www.itooIs. info 六个地址中的任意一个。
[0048] S304、NAS设备判断该I0S终端发起的HTTP 1 .OGet hotspot-detect.html探测报 文是否为首次HTTP 1 • OGet hotspot-detect • html探测报文，如果为首次，则NAS设备则构 造并响应HTTP 2000K报文，报文内容的主体部分为失败(Failed)，指示苹果服务器响应失 败，此时I0S终端的WIFI图标未点亮。
[0049] 本步骤中，NAS设备拦截该HTTP 1 .OGet hotspot-detect.html探测报文，根据维 护的I0S终端CNA探测状态表中的状态标识(Status)字段判断I0S终端发送的探测报文是否 为I0S终端显示Portal认证界面之后的首次HTTP1.0探测报文，若Status字段为0，返回HTTP 2〇0〇K，报文内容的Body部分为Failed，同时将终端CNA探测状态表中该MAC地址对应的 Status更新为1，此时I0S终端的Wi-Fi图标未点亮。
[0050] 需要说明的是，本发明实施例中，状态标识字段设置为0标识NAS设备首次接收到 该I0S终端所发送的HTTP 1.OGet hotspot-detect.html探测报文的状态，状态标识字段设 置为1标识NAS设备非首次接收到该I0S终端所发送的HTTP 1 .OGet hotspot-detect.html 探测报文的状态；当然也可以采用其它标识方式，例如状态标识字段设置为1标识NAS设备 首次接收到该I0S终端所发送的HTTP 1_OGet hotspot-detect.html探测报文的状态，状态 标识字段设置为〇标识NAS设备非首次接收到该I0S终端所发送的HTTP l.OGet hotspot-detect.html探测报文的状态；当然也可以采用其它标识方式，只要事前进行定义NAS设备 识别到状态变化即可，在此不再赘述。
[0051] 此时的HTTP l.OGet hotspot-detect.html探测报文为第二响应报文。
[0052] S305、I0S终端接收到NAS设备响应的HTTP 2000K报文之后，发起HTTP l.lGet hotspot-detect. html 请求报文。
[0053] S3〇6、NAS设备判断该I0S终端发起的HTTP l.lGet hotspot-detect.html请求地 址是否在NAS设备的白名单列表中或者当前10S终端是否己认证通过，如果请求地址不在 NAS设备的白名单列表中并且当前I0S终端未认证通过，则NAS设备响应HTTP 302报文，将 Portal认证页面地址通过HTTP 302报文返回给I0S终端，此时I0S终端的WIFI图标未点亮。 [0054] S307、I0S终端收到NAS设备根据HTTP l.lGet hotspot-detect.html请求所返回 的HTTP 302请求报文后，请求HTTP 302报文中携带的Portal认证页面地址，此时I0S终端显 示Portal认证页面。
[0055] S3〇8、IOS终端再次向NAS设备发起HTTP l.OGet hotspot-detect.html探测报文。
[0056] S309、NAS设备通过判断该HTTP 1 .OGet hotspot_detect.html探测报文是否为首 次HTTP 1 • OGet hotspot-detect • html探测报文，如果不为首次（即为I0S终端显示Portal 认证页面之后的HTTP l.OGet hotspot-detect.html探测报文），则构造并响应HTTP 2000K 报文，报文内容的主体(Body)部分为成功(Success)，指示苹果服务器响应成功，此时WIFI 图标点壳。
[0057] 具体的，NAS设备可以通过I0S终端CNA探测状态表中的Status字段来判断是否为 首次HTTP 1 .OGet hotspot-detect.html探测报文。WIFI图标点亮原因参照步骤S202,在此 不再赘述。
[0058] 此时的HTTP l.OGet hotspot-detect.html探测报文为第一响应报文。
[0059] S310、I0S 终端持续发起 HTTP l.OGet hotspot-detect .html 探测报文。
[0060] S311、NAS设备通过判断该HTTP l.OGet hotspot-detect.html探测报文是否为首 次HTTP l.OGet hotspot-detect.html探测报文，如果不为首次，则响应HTTP 2000K报文， 报文内容的主体(Body)部分为成功(Success)，此时WIFI图标保持亮起状态。
[0061] 具体的，NAS设备可以通过终端CNA探测状态表中的Status字段来判断是否为首次 HTTP 1 .OGet hotspot-detect.html探测报文。WIFI图标点亮原因参照步骤S202,在此不再 赘述。
[0062] 本发明实施例提供的WIFI状态保持方法，通过NAS设备在检测到I0S终端显示 Portal认证页面之后发送的HTTP l.OGet hotspot-detect .html探测报文时，响应HTTP 2000K报文，并且在报文中包含指示成功的内容，使得I0S终端认为探测成功，从而使WIFI图 标提前被点亮，并且不会中断WIFI连接，解决了I0S终端由于自身CNA机制，在认证通过前离 开Portal页面时会导致该I0S终端自动断开WIFI的问题。
[0063] 实施例3、
[0064] 本发明实施例提供了一种NAS设备，应用于上述WIFI状态保持方法，参照图5中所 示，包括：
[0065] 接收单元1401，用于接收I0S终端发送的探测报文，探测报文用于探测苹果服务器 是否可达；
[0066] 发送单元1402,用于判断当接收到的探测报文为I0S终端显示Portal认证界面之 后的探测报文时，NAS设备构造并响应第一响应报文，其中，第一响应报文的主体部分指示 苹果服务器响应成功。
[0067] 在一种可能的设计中，探测报文为HTTP 1 .OGet hotspot-detect.html探测报文。
[0068] 在一种可能的设计中，响应报文为HTTP 2000K报文，HTTP 2000K报文的主体部分 为成功Success。
[0069] 在一种可能的设计中，发送单元1402还用于：当接收到的探测报文不为I〇S终端显 示Portal认证界面之后的探测报文时，构造并响应第二响应报文，其中，第二响应报文的主 体部分指示苹果服务器响应失败。
[0070] 在一种可能的设计中，发送单元14〇2还用于：在接收到I0S终端发起的DHCP Discover报文后，在预先创建的I0S终端CNA探测状态表中记录I〇S终端的MAC地址及对应的 接收探测报文的状态标识;并在首次接收到I〇S终端发起HTTP1.0探测报文后更新状态标 识，根据状态标识判断接收到的探测报文是否为I〇S终端显示Portal认证界面之后的探测 报文。
[0071] 由于本发明实施例中的NAS设备可以应用于上述WIFI状态保持方法，因此，其所能 获得的技术效果也可参考上述方法实施例，本发明实施例在此不再赘述。
[0072] 应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺 序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施 过程构成任何限定。
[0073] 本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单 元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能宄竟 以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员 可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出 本发明的范围。
[0074] 所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、 装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0075] 在本申请所提供的几个实施例中，应该理解到，所揭露的系统、设备和方法，可以 通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元的 划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件 可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或 讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，设备或单元的间接耦 合或通信连接，可以是电性，机械或其它的形式。
[0076] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显 示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个 网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目 的。
[0077]另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以 是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0078] 所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以 存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说 对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计 算机软件产品存储在一个存储介质中，包括若千指令用以使得一台计算机设备(可以是个 人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。 而_述的存储介质包括:U盘、移动硬盘、只读存储器(英文全称:read-only memory，英文简 称:ROM)、随机存取存储器(英文全称:random access memory，英文简称:RAM)、磁碟或者光 盘等各种可以存储程序代码的介质。
[0079]以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何 熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵 盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。
以上是关于苹果手机连接Wifi认证机制的主要内容，如果未能解决你的问题，请参考以下文章