TYPESDK手游聚合SDK服务端设计思路与架构之四:流程优化之新闻安全与订单校验

有了前文多少个步骤的辨析和筹划,TYPESDK的信息互相流程已经能够健康工作了,可是,那几个流程还并未考虑到支付这么的进度中,至关心注重要的音讯安全难点。

  在从前的几篇文字中,大家分析了从零开首搭建三个水渠聚合SDK服务端所须要应对的多少个最根本的经常流程。根据文中的内容,大家大能够本人最拿手的语言和工具开发出一套已经得以不奇怪办事的服务端,那个服务端能够应付大部分水渠,例如UC,百度,360等等的连接须要,假若你的娱乐只须要衔接这个渠道,那么将来这些服务端已经足以上线工作了。但是,这么些世界还是存在这么局地沟渠,它们的劳作流程和任何的渠道不太雷同。为了维持包容性和扩大性,大家须要为这几个渠道做一些越发的做事。

在全体交互进度中,游戏服务端,SDK服务端,渠道服务端都属于安全区域,那有个别产生的多少交互,基本是足以信任的,只必要作相对不难的处理工科作;而客户端,包含游戏客户端,SDK客户端都属于危险区域,在那部分产生的数目和央求,都有恐怕遭受外部的阻止和歪曲。因而,大家需求在工艺流程上加以免备和操纵。

        
为了方便说明,我们仍然先举个栗子——VIVO是一家影响力较大的机商渠道,而她们的充值流程和上述几家的不太相同。下边大家先看看VIVO官方文书档案关于充值流程的辨证:

图片 1
图1

—————————————-伊始引用VIVO官方文书档案的分隔线—————————————-

从示意图1方可看看。针对三类不一致安全性的数据流,大家的拍卖原则也是例外的。

         图片 2


淡白紫箭头所表示的是高枕无忧可靠的乞请。属于那类请求的是十121十三日游服务端与SDK服务端之间通讯的呼吁。对那类请求传送的音信,原则上得以从来予以信任,并且以之视作基础,达成流程和逻辑的决定。在TYPESDK的设计中,对那部分呼吁,设置的淮北机制是简简单单的通讯key签盛名学校验。

1、商行APP指导商品音信、价格等新闻,请求商户庭服务务器;


深紫红箭头所代表的是半可信赖的伸手。具体来说包括渠道服务端与SDK服务端之间的通讯请求。由于渠道服务端处于开发者能够范围之外,即使多数动静下该地点是易如反掌的,不过在将互动新闻用于逻辑从前,供给做安全校验。平常选择的艺术有:

贰 、商家服务器生成商行订单号,并辅导商户APP传递的货品、价格消息请求索爱的订单推送接口;


数据摘要签名/请求串加密。那部分处理一般在沟渠服务端文书档案内会写明处理逻辑及校验算法。

三 、验证HTC服务器(订单推送接口)再次回到的音讯(验证签名、价格、订单号等),准确科学之后将订单推送接口再次回到的音信再次来到给商家APP;


访问IP白名单控制。在SDK服务器上配备内定渠道IP白名单,只相信来自白名单内IP的伸手。同样,部分渠道也会因此后台配置或技术人士联系的情势设置开发者的服务器IP为白名单。

④ 、卖家APP协会调起酷派SDK的参数(包涵订单推送接口再次来到的transNo和accessKey等),调起支付SDK举行开发;


肉色箭头表示的是不可相信赖的乞求。基本上,与客户端通讯的兼具请求都以不可相信的呼吁。由于各请求隶属的模块差别,处理方式也各有些。基本上有以下三种:

五 、Vivo服务器异步公告商户庭服务务器支付成功,商行服务器验证签名、价格等消息,准确科学后,以HTTP状态码200回来。


渠道客户端库与渠道服务端之间的通信,那有的数码交互由渠道本人机制来担保其可相信性,接纳的技术手段包罗token验证,客户端加密,签名身份鉴定区别等等机制。对于开发者而言,能够省略的认为,从沟渠提供的接口获得的数码是可相信的,提交给渠道的消息也不用作多余的景德镇处理体制,不然可能会时有发生其余题材。

 


游戏客户端与服务端之间的通讯,相信已经有众多专述作品证实。常见的双鸭山检查和测试机制蕴含token,时间戳,签名等校验情势。然则注意于平安的渠道库并非专注游戏性的玩乐客户端可比。现身破解或许请求被阻止的景色可谓不以为奇。由此,在娱乐逻辑架构划设想计的级差即将将安全性供给考虑在内。遵从以下标准:

—————————————-引用VIVO官方文书档案截止的分隔线—————————————-

1.         原则上海重型机器厂点逻辑必须运用服务端计算,客户端只负责显示和效率。例如前一篇文字里关系过的创办订单逻辑,由服务端发生订单。客户端能够收到订单号然后出示给用户,以及传送给渠道客户端。

依据对VIVO官方文书档案的解读,大家很简单发觉,和事先的水道充值流程相比,VIVO扩展了一步获取渠道订单号的步骤。这一步骤在其它渠道的充值流程中,是由渠道的客户端lib库包揽的,游戏客户端只须要动用订单相关音信作为参数,调用渠道客户端libCurry的呼应措施,和沟渠服务端通讯并得到到渠道订单号的做事由渠道lib库封装掉了。VIVO可能是因为安全性的考虑,供给这一步必要由游戏服务端完结。下图描述了貌似流程和VIVO流程的反差,图中石磨蓝箭头即增添流程。(那里省去了SDK客户端和服务端的脚色,仅描述原始流程)

2.         原则上具有数据新闻都是服务端保留的记录为准,客户端提供的笔录或许数额只当作参照比对。有争辨时遵守服务端。例如,用户破解了客户端并且篡改了客户端传输给渠道客户端的当中订单号。在继续的发货及对账时,游戏服务端只相信服务端自身保持的订单状态,对不合乎的订单直接丢掉或留记录不处理。

图片 3

n  SDK客户端与服务端之间的通讯,那有的数量交互并不多,常常适用于某个token转载,换签之类的尤其渠道逻辑,后文种有详实表达。SDK服务端对这么些不安全体据的处理方式是保存记录以资比对,但不作为任何逻辑的基础和基于。

图1

 

打听了VIVO渠道的充值流程,大家本来能够窥见,由SDK服务端来落到实处这一特种流程手续,大家只需求将充值流程修改如下:

基于以上原则,我们解析了各项数据交互的安全性特点以及处理规范,很简单就会意识,在大家原来的花费-发货逻辑中,缺点和失误了至关心爱抚要的一环,即订单校验步骤。没有这一步骤,SDK服务端在接收渠道的发货回调后,会立时公告游戏服务端处理发货逻辑。不过遵照以上的剖析,渠道支付订单的交付步骤事实上是在不安全区域-客户端内到位的,这一步骤可以被别有用心的用户拦截并修改。举例如下:

图片 4

例1:用户点击游戏中的大礼包购买,生成了一笔金额为648元的订单,然后选择地下工具在沟渠客户端提交订单时,拦截该订单,并修改其金额为0.01元,随即实现支付。渠道异步回调给SDK服务端时,SDK服务端判定其为合法订单并文告游戏服务端发货。结果是用户成功收获了地下利益648元。

图2

例2:用户通过不法工具,获取并保留了温馨一笔平常订单648元的全数订单消息。随后经过技术手段,将该订单的回调音讯重发给了SDK服务端。该订单一切音讯都与前一笔通常开销相同,SDK服务端判定其为合法订单并通告游戏服务端发货。结果是用户又打响获取了不法利益648元。

别的步骤和前面一样,追加的手续就在路上玛瑙红箭头所示的步骤6~步骤9,能够看到,这一步骤完全由SDK的客户端和服务端独立达成,无需改变游戏的过渡逻辑流程。那样,就由我们的SDK服务端接管了这一相当通讯流程逻辑。在无需游戏客户端和服务端做修改的情景下,成功的集结了VIVO的水渠。

哪些幸免例子中的情况发生?比较简单的伎俩是在打闹服务端实行订单比对和新闻校验,可是那样的拍卖不可防止的要和现实渠道的订单字段和处理逻辑关系,例如,渠道A的回调消息中含有订单金额字段,可以用来比对,而渠道B的回调新闻中只有单价和数目字段,如需比对只好本人总结总金额。又比如说,渠道C会定期做降价活动,充值折扣打9折,重回的充值金额也是9折后的数值,和原先游戏订单中的金额不一样。那么些逻辑不容许都让游玩服务端来处理,不然,就错过了聚合SDK的意思。由此,大家必要让游戏服务端提供贰个订单查询verify接口,每当SDK服务端接收到渠道的回调请求时,调用该接口,进行订单比对,唯有比对通过时,才会通报游戏服务端发货,那样就相比较完善的缓解了那种景色。

VIVO的那种特有流程只是如今境内市集各大小渠道各自独立达成的光怪陆离逻辑的中间有代表性的1个范例,为了达到大家的目的,即让游戏开发者“三遍对接,随地可用”的目标,大家还有相当长的路要走。可是基本的拍卖思路,都以将那些特出逻辑尽量利用SDK自个儿的接口封装起来,对游戏开发者透明。可是,就算我们运用了这么一些伎俩,仍旧仍旧有大家不能够简单包装的水渠逻辑,以应用宝为代表。后文中,我们会以四个专题来介绍如何封装应用宝的逻辑。

只是,SDK服务端并不可能缓解全体标题,游戏服务端仍然须要把好最后一道关。例如合法订单的双重发送逻辑,就供给娱乐服务端处理好,接收到再一次的订单号时,不要再度发货。

以此项目已开源,大家有趣味能够协调查商量究可能参照项目编写制定自个儿的聚合SDK

修改后的发货逻辑如下图所示:

花色地址:https://code.csdn.net/typesdk_code

图片 5

类别地址:https://github.com/typesdk

 

图2

流程表达

1.       充值订单到帐后,渠道服务端异步文告TYPESDK服务端

2.       TYPESDK服务端通过订单中的内部订单号,查询充值音讯交到接口提交的订单音信,获取游戏订单查询U大切诺基L,向该UCRUISERL发起呼吁获取游戏服务端保存的订单音讯,用于对比判定该订单是或不是合法。

3.       游戏服务端通过提交的内部订单号查询订单信息,再次来到给TYPESDK服务端

4.       TYPE服务端校验通过,公告游戏服务端发货

5.       游戏服务端收到发货请求后先保存该请求,立即回到TYPESDK服务端,表示已接收发货请求。将该订单的场所置为已给付未发货。


不要处理完发货请求之后再回来,也许引致渠道文告请求超时,导致该通知重复发送


注意渠道为确认保证布告到达,恐怕会再度发送发货请求,TYPESDK会原样转载全数请求。游戏服务端要求做幸免同样订单号再度发货的处理。

6.       TYPESDK再次来到渠道服务端

7.       游戏服务端异步处理发货逻辑,将该订单的图景置为已发货。并文告游戏客户端

本条类型已开源,大家有趣味能够协调查钻探讨或然参照项目编制本身的聚合SDK

花色地址:https://code.csdn.net/typesdk_code

品类地址:https://github.com/typesdk

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注