TYPESDK手游聚合SDK服务端设计思路和架构的五:流程优化的异流程处理

色地址:https://github.com/typesdk

—————————————-引用VIVO官方文档结束之分隔线—————————————-


不要处理终结发货请求后又回,可能致渠道通知请求过,导致拖欠通告还发送

1、商户APP携带商品信息、价格抵信息,请求商户服务器;

图2

图1

3.       游戏服务端通过付出的中订单号查询订单信息,返回给TYPESDK服务端

图片 1

7.       游戏服务端异步处理发货逻辑,将该订单的状态置为已发货。并通报游戏客户端

  在事先的几首文字被,我们分析了从零开始搭建一个沟渠聚合SDK服务端所急需应的几乎独最要之屡见不鲜流程。按照文中的始末,我们非常可团结无比拿手的言语和工具开发出同样模仿已经足以正常办事的服务端,这个服务端可以应付大多数沟,例如UC,百度,360等等的连片需求,如果你的游乐就待衔接这些渠道,那么现在者服务端已经足以上线工作了。但是,这个世界要有这样有沟,它们的办事流程及其它的渠道不极端一致。为了保障兼容性及扩展性,我们要呢这些渠道做一些特地之办事。


绿色箭头所表示的是半可信的呼吁。具体来说包括渠道服务端与SDK服务端之间的通信请求。由于渠道服务端处于开发者能够范围以外,虽然多数气象下该地方是十拿九稳的,但是以以互相信息用于逻辑之前,需要开安全校验。通常用的法有:

刺探了VIVO渠道的充值流程,我们自然好窥见,由SDK服务端来贯彻即同不同寻常流程手续,我们只有待将充值流程修改如下:

什么避免例子中之情有?比较简单的招是当玩服务端进行订单比对同信息校验,但是如此的拍卖不可避免的设同求实渠道的订单字段和拍卖逻辑关系,例如,渠道A的回调信息遭到涵盖订单金额字段,可以用来比对,而渠道B的回调信息遭受只有单价及数目字段,如需于对只能协调计算总金额。又如,渠道C会定期举行优惠活动,充值折扣从9折,返回的充值金额为是9折后底数值,和原先游戏订单被的金额不平等。这些逻辑不可能都叫游玩服务端来拍卖,否则,就夺了聚合SDK的义。因此,我们用被游玩服务端提供一个订单查询verify接口,每当SDK服务端接收及渠道的回调请求时,调用该接口,进行订单比对,只有比对经时,才见面打招呼游戏服务端发货,这样虽于完美的化解了这种情况。

5、Vivo服务器异步通知商户服务器出成功,商户服务器验证签名、价格相当消息,准确是后,以HTTP状态码200回。

图片 2

VIVO的这种新鲜流程只是目前国内市场各大小渠道各自独立实现的好奇逻辑的中有代表性的一个范例,为了上我们的对象,即为游戏开发者“一蹩脚对接,到处可用”的目的,我们还有挺丰富的路程如果活动。但是基本的处理思路,都是拿这些新鲜逻辑尽量使用SDK自己之接口封装起来,对戏开发者透明。但是,即使我们下了这么有手腕,仍然要来我们无法简单包装的水道逻辑,以应用宝为代表。后文中,我们见面为一个专题来介绍如何封装应用宝的逻辑。

来了前文几单步骤的辨析与筹划,TYPESDK的消息相互流程都足以正常干活了,但是,这个流程还没有设想到出这么的经过中,至关重要的音安全问题。

        
为了方便说明,我们或先举个栗子——VIVO是一律家影响力较充分的机商渠道,而她们之充值流程以及上述几贱的非顶相同。下面我们先行瞧VIVO官方文档关于充值流程的验证:

n  SDK客户端与服务端之间的通信,这部分数量交互并无多,通常适用于片token转发,换签之类的特种渠道逻辑,后文会有详细说明。SDK服务端对这些不安全数据的处理方式是保留记录为资比对,但无当作其它逻辑的基础和因。

图2

2.       TYPESDK服务端通过订单被之里订单号,查询充值信息提交接口提交的订单信息,获取游戏订单查询URL,向该URL发起呼吁获取游戏服务端保存的订单信息,用于比判定该订单是否合法。

任何步骤及之前同一,追加的手续就是以路上黑色箭头所显示之步骤6~步骤9,可以见见,这同步骤完全出于SDK的客户端以及劳务端独立完成,无需改变游戏的连接逻辑流程。这样,就由于我们的SDK服务端接管了立即同样异样通信流程逻辑。在无需打客户端和劳动端做修改的景况下,成功之聚众了VIVO的沟。


游戏客户端和服务端之间的通信,相信就来为数不少专述文章证实。常见的安全检测机制包括token,时间穿,签名等校验方式。但是注意让平安的渠道库并非专注游戏性的游乐客户端可比。出现破解或者请求让拦的情可谓屡见不鲜。因此,在嬉戏逻辑架构设计的级差即将拿安全性要求考虑在内。遵循以下原则:

种地址:https://github.com/typesdk

流程说明

基于对VIVO官方文档的解读,我们很轻发现,和事先的水渠充值流程相比,VIVO增加了一致步获取渠道订单号的步子。这同步骤在任何渠道的充值流程中,是出于渠道的客户端lib库包揽的,游戏客户端只需要采用订单相关信息作参数,调用渠道客户端lib库里的呼应措施,和沟渠服务端通信并得到到渠道订单号的行事由渠道lib库封装掉了。VIVO可能由于安全性的考虑,要求立刻无异步要由游戏服务端完成。下图描述了相似流程及VIVO流程的距离,图中黑色箭头即多流程。(这里省去了SDK客户端和劳务端的角色,仅描述原始流程)

 

4、商户APP组织调整起vivoSDK的参数(包括订单推送接口返回的transNo和accessKey等),调起开SDK进行开发;

5.       游戏服务端收到发货请求后先保存该要,立刻回到TYPESDK服务端,表示已经接收发货请求。将欠订单的状态置为已给付不发货。

类地址:https://code.csdn.net/typesdk_code


注意渠道为力保通知到,可能会见还发送发货请求,TYPESDK会原样转发所有请求。游戏服务端需要做防止同样订单号又发货的拍卖。

         图片 3

例1:用户点击游戏受之充分礼包购买,生成了扳平画金额为648首批之订单,然后利用私自工具在渠道客户端提交订单时,拦截该订单,并修改其金额也0.01头,随即就支付。渠道异步回调给SDK服务端时,SDK服务端判定该也官方订单并通知游戏服务端发货。结果是用户成功博得了私利益648冠。

3、验证vivo服务器(订单推送接口)返回的音讯(验证签名、价格、订单号当),准确是后以订单推送接口返回的信息返回给商户APP;

以全方位交互过程遭到,游戏服务端,SDK服务端,渠道服务端都属安全区域,这片闹的多寡交互,基本是足以信赖的,只需要发相对简单的处理工作;而客户端,包括打客户端,SDK客户端都属于危险区域,在及时有产生的数额与请,都发出或面临外部的阻与歪曲。因此,我们需要在工艺流程及加以防范和决定。

图片 4


看IP白名单控制。在SDK服务器上安排指定渠道IP白名单,只相信来白名单内IP的要。同样,部分渠道也会经后台配置或者技术人员联系的款式设置开发者的服务器IP为白名单。

 

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

以此类别现已开源,大家有趣味可以团结研究或者参照项目编制好的聚合SDK

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

2、商户服务器生成商户订单号,并带走商户APP传递的货品、价格信息请vivo的订单推送接口;

 

—————————————-开始引用VIVO官方文档的分隔线—————————————-

图片 5
图1


蓝色箭头所代表的是平安可信的恳求。属于即类似请求的是一日游服务端与SDK服务端之间通信的伸手。对当下看似请求传送的音讯,原则达成可以直接给予信任,并且因为之视作基础,完成流程与逻辑的操纵。在TYPESDK的计划着,对当下有些求,设置的安全体制是粗略的通信key签名校验。

列地址:https://code.csdn.net/typesdk_code

以此路现已开源,大家发趣味可以协调研究或者参照项目编制好之聚合SDK

根据上述口径,我们解析了位数据交互的安全性特点与处理标准,很爱就会见发现,在咱们原来的开发-发货逻辑中,缺失了重在的一律围,即订单校验步骤。没有及时同一步骤,SDK服务端在接渠道的发货回调后,会应声通知游戏服务端处理发货逻辑。然而因上述之辨析,渠道支付订单的交给步骤事实上是以未安全区域-客户端内形成的,这同一步骤可以于别有用心的用户拦截并修改。举例如下:

1.         原则及要逻辑必须使服务端计算,客户端只当展示暨效益。例如前一模一样首文字里提到了之创导订单逻辑,由服务端产生订单。客户端好接过订单号然后显得受用户,以及传送给渠道客户端。

例2:用户通过非法工具,获取并保留了好同样笔正常订单648老大的保有订单信息。随后通过技术手段,将欠订单的回调信息再发给了SDK服务端。该订单一切信息都与前方一样笔画正常开支相同,SDK服务端判定该也官方订单并通知游戏服务端发货。结果是用户以成功取了私利益648第一。

由示意图1方可看看。针对三类不同安全性的数据流,我们的处理规范呢是不同的。


数据摘要签名/请求串加密。这片处理日常以沟服务端文档内会写明处理逻辑和校验算法。

2.         原则达成拥有数据信息都坐服务端保留的记录为按,客户端提供的记录或数额就作参考比对。有冲突常常听服务端。例如,用户破解了客户端并且篡改了客户端传输给渠道客户端的其中订单号。在继续的发货同对账时,游戏服务端只相信服务端自己保持的订单状态,对无合乎的订单直丢掉或留记录不处理。

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


渠道客户端库与渠道服务端之间的通信,这一部分数额交互由渠道自机制来保管其可靠性,采用的技术手段包括token验证,客户端加密,签名身份鉴别等等机制。对于开发者而言,可以大概的看,从沟渠提供的接口获得的数据是可信之,提交给渠道的音信吗不用作多余的平安处理机制,否则可能会见发生任何问题。

6.       TYPESDK返回渠道服务端

然而,SDK服务端并无能够化解所有问题,游戏服务端还是得将好最后一道关。例如合法订单的再次发送逻辑,就需要娱乐服务端处理好,接收至再次的订单号时,不要再次发货。


红色箭头表示的凡勿可信之请。基本上,与客户端通信的富有请求都是不可信之乞求。由于各国要隶属的模块不同,处理方式也每发生独家。基本上有以下几栽:

 

发表评论

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