iOS项目总结——梦享一键连接SDK

    xiaoxiao2021-03-25  156

    目录 项目背景项目业绩模块图层实现方案 账号认证Token认证云认证工厂方法优化账号、token、云认证的调用众包认证一键连接通信安全 学习总结
    1、项目背景     梦享网络公司第一代核心产品,用于给第三方App提供WiFi连接能力,给流量消耗量比较大的App提供WiFi连接,从而增加用户在移动场景的使用率与用户粘性。     本SDK在业务方主要实现以下功能: 账号认证类型WiFi,如CMCC-WEB、ChinaNet、ChinaUniom、百米生活、114 free等公共WiFi。Token认证类型WiFi,如i-wifi、0-wifi、修远WiFi、连乐WiFi等公共WiFi。云认证类型WiFi,如花生WiFi、禾连、贝联、金安陆。众包连接,通过梦享密码库实现WiFi连接。
    2、项目业绩 App 所属公司 SDK描述 对接时间 cookTalk 中兴通信 运营商WiFi 2015/8 万能钥匙 上海连尚网络科技 运营商WiFi 2015/9 WiFi浏览器 上海聚玩网络科技 运营商WiFi 2015/9 快牙 邻动网络科技 运营商WiFi 2015/11 花生WiFi 南方银谷集团 运营商、商业、众包WiFi 2016/8 阿里云OS 阿里巴巴 众包WiFi,代码对接方式 2016/10
    3、模块图层 3.1、设计思路 项目遵从模块化开发的原则,严格按照三种类型的模块进行分类组合: 业务强逻辑层:通过调用业务弱逻辑模块、若逻辑模块完成直接的业务逻辑代码,不可重用性最高。业务弱逻辑层:通过调用弱逻辑层的功能模块,针对业务需要封装的模块,完成诸如网络层、持久层这些依据项目不同而规范不同的模块,在项目内可重用。弱逻辑层:一些通用的功能模块,与业务没有直接或者间接的关系,可以直接挪动到别的项目使用,如AFNetworking、FMDB等。 依据以上的分层,项目主负责人可以专心设计业务弱逻辑层以及弱逻辑层,给项目制定统一的规范,而业务工程师只需要完成最核心的代码即可,从而提高整个项目的可维护性,平缓学习曲线。 3.2、各模块具体实现功能 业务强逻辑层 账号认证模块:Token认证模块:云认证模块:众包认证模块一键连接功能模块: 业务弱逻辑层 网络层:持久层:config: 若逻辑层 日志记录:加密模块:helper/tool: PS: 1、模块的定义? 模块是为了完成特定功能而组合起来的相关类。
    4、实现方案 4.1、账号认证     4.1.1、思路&背景                 中国移动、中国联通、中国电信提供的公共WiFi是通过特殊的账号进行登录的,而这些账号上网是通过计时收钱的。还有另外一种同样是通过账号登陆的免费公共WiFi,如                 114free、百米生活,这些WiFi是通过手机号注册上网的,而且上网不会计费,但会弹出广告或者推送周边商户信息。为了实现以上两大类的账号类型WiFi的登陆认证,我                 们需要建立一个账号池,当用户在移动端请求什么类型的WiFi登陆就发放相对应的账号完成登陆。                  客户端需要考虑的问题: 1、账号池的建立 2、响应账号请求的规范 3、通信安全 4、账号回收 5、盗号问题 移动端需要考虑的问题: 1、公共WiFi的识别 2、通信安全 3、自动登陆过程 下面主要讨论公共WiFi的识别与自动登陆的实现,而通信安全在4.6节中讨论。     4.1.2、实现方案                 具体实现的时序图如下所示:                                 Q&A:                 (1)交换秘钥的思路?                          客户端保存着服务器的公钥,并用其加密随机生成的AES加密秘钥,每个AES随机秘钥对应一次的请求,下次的请求需要重新经历前面的过程再生成,具体详见4.6。                 (2)公共WiFi的识别?                          每个App在使用前必须调用negotiate接口,该接口请求成功,会返回一个json数据包,其中有个字段对应白名单,白名单里面保存着该App可用的账号认证、Token认证、云认证的公共WiFi的相关信息。结合白名单结合匹配算法,即可得知该WiFi热点是否能连接。                 (3)自动登陆过程的实现?                          实际上就是通过程序模拟用户使用账号登陆过程来实现自动登陆。而用户登陆手动登陆的过程如下:                          打开浏览器随机访问网页-》弹出protal页面-》输入账号密码-》认证完成。                          所以用程序实现的过程就如下:                          访问浏览器并实现重定向-》用正则匹配解析重定向网页,获取与登陆相关的字段-》用获取回来的url与字段、账号密码发起post请求-》完成登陆认证。具体实现见代码。 4.2、Token认证         4.2.1、思路&背景                       Token认证实际上就是参考了HTTP的基本认证机制与摘要认证机制,而这里的token认证不同的是不是通过http的header字段来传参,而是通过post来传输参数。其中主要还是通过生成摘要的方式来认证身份,所以都是md5、base64之类的摘要算法的混合使用。                      但Token认证的最大优势是不需要联网梦享服务器,只需要在直接按照与第三方协商好的方式生成摘要发送post报文,第三方服务器验证成功则登陆成功,所以是效率比较高的方式。但不好的地方就是每个厂商都自己定制摘要生成的方式,需要管理繁多的摘要生成,这一点在云认证里                     进行了优化。           4.2.2、具体实现                       Token认证的时序图如下:                                                   token认证的具体实现比较简单,这里就不详细讲解,具体可见代码。                         需要考虑的点是如何组织繁多的token认证接口,从而方便调用,这点将要4.4中详细解答。                        4.3、云认证           4.3.1、思路&背景                         因为Token认证会带来以下的诸多麻烦: 需要管理一堆的Token认证类,导致大量文件,增加工程体积需要将所有Token认证文件都打包进SDK,尽管用户可能并不需要若需要增加Token认证文件时,需要重新给客户打包SDK                         正因为以上的不便,让我们想出一种新的方式去完成Token类型的认证任务,那就是云认证。云认证其实就是把认证任务部署在服务器端而不是移动端,只做了这个小小的改动,那么移动端就只需要实现一个通用的云认证功能模块,给服务器提供目前需要连接的WiFi信息与设备信息                         然后由服务器直接与对方服务器通信,完成接下来的摘要生成与发送的任务,最后再间接给移动端反馈状态即可。             4.3.2、具体实现                         云认证的时序图如下:                                                 云认证的具体实现与Token认证十分相似,本质上的差异就是把摘要认证的任务放置到服务器中,所以这里不做详细说明。                    4.4、账号认证、Token认证、云认证接口的调用优化         4.4.1、思路&背景                     寻找运营商认证、Token认证、云认证三者的共同点,我们可以发现都是输入目标的AP的ssid、bssid,然后得到认证的返回状态。所以我们可以寻找一种方式去管理以上的所有的类,一遍开发者能更好的调用,就是随便输入一个AP的ssid与bssid即可完成相关认证过程,而不理是什                     么类型的公共WiFi。                     这里我使用的工厂方法来实现这个目的。         4.4.2、具体实现                     首先,工厂方法的类图如下:                                                                                      根据工厂方法的概念,设计出如上类图,AuthPortalManager等价于ConcreCreator也就是工厂,而AuthAccoutType、AuthTokenType是实际的创建者creator,而它们都实现AuthPortalInterface接口,以确保通过AuthPortalManager的login、logout方法能正确调用目标的对象实现                             上下线。                             通过以上方式来组织以上几个模块,可以实现方便添加新的认证模块与便捷调用的一系列好处。                      4.5、众包认证     4.4.1、思路&背景                 众包WiFi本质就是普通WiFi的认证,这些WiFi的认证通常都是诸如WEP、WPA、WPA2等方式认证,也可以理解为平常的密码认证。要实现这些WiFi的认证就是从服务器里获取WiFi的账号密码,然后根据iOS系统的不同,获取系统WiFi列表的方式有所差异: iOS9.0之前的系统 (1)定位:通过定位获取附近可用的WiFi,并返回WiFi的信息与密码,通过粘贴密码可以实现连接。 (2)图片识别:通过截屏系统WiFi列表,文字识别获取ssid,再通过定位减少搜索范围,去请求服务器,获取到截屏内WiFi的有效密码,通过粘贴实现连接。 iOS9.0以上的系统 通过NEHotspotHelper这个网络扩展框架类,实现密码的预设置,从而实现一点击连接众包WiFi的效果。 但这里讨论的着重点是拿到WiFi列表后的众包WiFi查询的实现过程,而要作用众包WiFi连接要做好以下四点考虑。 过滤信号过弱的WiFi兼容账号认证WiFi请求过滤已经查询过的WiFi缓存已经查询过的WiFi     4.4.2、具体实现                 因为实现众包认证的QAD接口,每次输入的数据是一个WiFi列表,所以若不做优化考虑去请求会造成发送和接收大量的请求、也会造成很多重复数据的请求,给服务端的造成影响也浪费本地的流量和内存。所以从下面四个方面进行优化设计。                 (1)过滤信号过弱的WiFi                          先立即过滤掉信号较弱的WiFi,因为信号较弱的WiFi通常连接不上而且连接上体验也十分糟糕,所以这里设置signal低于6.5的WiFi一律过滤掉。                 (2)兼容账号认证WiFi请求                          若请求列表中包含账号认证类型WiFi,由于在一键连接的过程中,是无法预先知道移动端到底是需要连接哪个WiFi,所以这里设计了一个引导号机制,就是默认请求列表中所有符合白名单的账号认证的账号密码并持久化保存,但这批账号密码的改密周期会延长。                          当列表所需的账号类型WiFi都有与之对应的账号密码并且没过期,则不需要请求,否则则只请求缺少的部分。                 (3)过滤已经查询过的WiFi                          在正式发起请求到服务器查询之前,会过滤掉已经查询过的AP,若被过滤的AP在有效查询列中则直接作为结果返回。                           为了优化查询过程,这里使用NSDictionary来作为缓存的容器,而key是“ssid”+“bssid”的字符串拼接,而value是就是password。                                          (4)缓存有效查询过的WiFi                         缓存从服务器返回的有效查询列表,并给她们贴上生命周期标签,在每次发起QAD请求前,都会将“以查询列表”和“有效查询列表”中已经过期的记录删除掉。                         这里使用NSDictionary来作为缓存的容器,而key是“ssid”+“bssid”的字符串拼接,而value是就是password。                    具体流程图如下:                     4.6、一键连接功能(warning:一键连接功能还没实现以下设计)     4.6.1、思路&背景                 一键连接本质上就是应用了设计模式里面的外观模式,通过将上面的所有功能模块进行一种恰当的封装,从而实现开发者可以调用一行制定即可完成一键连接功能的注册,之后就可以结合NEHotspotHelper实现跳转到系统列表,然后用户点击一下带有“梦享一键连接
    转载请注明原文地址: https://ju.6miu.com/read-23511.html

    最新回复(0)