涉及用户隐私、金钱等产品在用户账户安全上更应该下功夫。比如账号密码强度验证,账号多地同时登陆处理以及账号在新设备上登录验证等。前段时间公司做了新设备短信验证,产品逻辑上很简单,但是其中却有很多坑,今天来复盘一下。
1.产品逻辑
在登录页面输入账号密码点击登录后,先检测登录密码是否正确,密码正确的情况下,该账号在此设备上是否是第一次登陆,如果是则跳转至新设备登录验证页面,不是则登陆成功。在换设备验证页面输入短信验证码,正确即代表验证成功,然后采用一定的技术手段标识此设备为非新设备,下次再登陆此账号时,就不会再验证设备。
2.页面设计
新设备短信验证3.踩坑过程
看看,很简单是吧。于是乎花了个把小时就把需求文档和UI做好了,简单和开发说了下,就进入开发环节。
坑一:等到要上线时,测试妹妹发现,正常的流程没有问题,但是将APP卸载重装后,登录过的设备依然会要求验证设备。
问题就出在“采用一定的技术手段”上,开发在做的时候并未考虑全面,只是简单实现功能。接下来分析一下技术层面的问题,android系统和ios系统在技术处理方法上自然是不同,但是原理上基本相同。新设备需要短信验证,非新设备不需要短信验证,那么就需要得到这个设备的唯一标识。
android获取设备唯一标识的方法:
1)获取IMEI
缺点:需要用户给与获取手机信息的权限。
2)获取Mac地址
缺点:谷歌为保障用户隐私安全,android 6.0版本后,任何手机都是"02:00:00:00:00:00"这个默认的mac地址。
3)获取ANDROID_ID
缺点:1.手机恢复出厂设置以后该值会发生变化。2.某些设备是不会返回ANDROID_ID。
4)获取UniquePsuedoID
缺点:同一批次生产的设备UniquePsuedoID可能相同。
5)通过友盟等第三方接口获取
缺点:因为是第三方接口,所以有很多不可控因素。
ios获取设备唯一标识的方法:
1)获取UDID
缺点:为保障用户隐私安全,从IOS5.0开始,苹果宣布将不再支持用uniqueIdentifier方法获取设备的UDID。
2)获取UUID
缺点:这个值系统不会存储,每次调用的时候都会获得一个新的唯一标示符。
3)获取Open UDID
缺点:删除后再获取,值会不一样。
4)获取MAC Address
缺点:为保障用户隐私安全,iOS7后请求Mac地址都会返回一个固定值。
5)获取广告标示符(IDFA-identifierForIdentifier)
缺点:a.如果用户完全重置系统,这个值会重新生成。b.另外如果用户还原广告,这个值也会重新生成。
6)获取Vendor标示符 (IDFV-identifierForVendor)
缺点:卸载后,这个值会改变。
7)通过友盟等第三方接口获取
缺点:因为是第三方接口,所以有很多不可控因素。
可以看出,不管是ios还是android,大部分获取标识的方法都会存在卸载应用、更新系统后标识符会改变,或不可使用的问题。最终我们的android开发小哥哥用得是第5种方法,接的是友盟的接口,可以实现卸载APP重装后,登录不会再验证短信。ios采用了第二点获取UUID的方法,只是将这个方法加以优化:应用第一次启动时,会将获取的UUID存储在KeyChain中, 以后每次要使用UUID时,先看KeyChain是否为空, 如果为空则将UUID存储进去,如果不为空,则直接使用KeyChain里面的值。这种方法在用户卸载APP或重启设备, KeyChain都不会清空,登录自然也不会再验证短信。
这样,我们就开心的上线啦。
坑二:上线后android报“设备不一致”的错误,强制用户重新登录,并需要验证短信。
经过开发排查,发现是友盟的问题,同一个设备在一定时间段内会提供两个不一样的设备标识。所以android最后也只有自己写代码去解决这个问题。最后采用的方法:获取IMEI的方式,这种方式必须用户允许给与权限,如果不给权限,还是会要求验证短信。所以在一定程度上还是未能完全满足需求。(现在市面上很多android系统的APP在安装过程中必须用户允许开启获取手机信息的权限,否则将不能使用此APP)
4.总结
虽然说需求上很简单,但是产品也需要了解基本的技术知识,防止上线后才发现各种问题。
网友评论