iOS平台scheme传送方法、装置、服务器及系统与流程

本发明涉及计算机技术领域，特别是涉及一种iOS平台scheme传送方法、装置、服务器及系统。

背景技术：

iOS是苹果公司开发的移动操作系统，可以应用与iPhone、iPod touch、iPad以及Apple TV等产品上。在iOS里，应用程序(app)之间都是相互独立的，为了满足用户对应用程序间通信的需求，iOS提出了URL Scheme方案。

目前URL scheme方案的具体过程是应用程序注册自己的URL scheme，将应用自身绑定到注册的URL scheme上，该URL scheme用于从其他应用程序中启动本应用程序。这样，用户可以在一个应用程序中启动另一个应用程序，实现了不同应用程序间的信息共享，具体的可以使用UI Application类的open URL方法来实现在一个应用程序中启动另一个应用程序。

但现有的URL scheme方案在实施时，容易出现以下问题：黑客会根据本地应用程序注册的“URL scheme”，伪造一个应用程序并为该伪造的应用程序注册与本地应用程序相同的“URL scheme”，这样，当其他应用程序通过URL scheme方案启动本地应用程序时，由于伪造的应用程序与本地应用程序采用相同的“URL scheme”，因此伪造的应用程序会被启动，同时，伪造的应用程序会获得其他应用程序发送的参数信息，因此，现有的URL scheme方案存在导致应用程序间发送的参数信息被泄露的问题。

技术实现要素：

本发明所要解决的技术问题是提供一种iOS平台scheme传送方法，用以解决现有技术通过URL Scheme传送参数信息时，出现的信息泄露的问题。

本发明还提供了一种iOS平台scheme传送装置、服务器及系统，用以保证上述方法在实际中的实现及应用。

根据本发明的一个方面，提供一种iOS平台scheme传送方法，该方法包 括：

第一应用程序通过与服务器预约的第一协议得到令牌；

第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌；

第二应用程序通过与服务器预约的第二协议向服务器发送携带所述令牌的服务参数请求，以请求服务器返回与所述令牌相关的服务参数信息。

优选的，所述第一应用程序通过与服务器预约的第一协议得到令牌，包括：

第一应用程序按照与服务器预约的第一协议中的加密算法或者映射算法生成供第二应用程序从服务器请求服务参数的令牌。

优选的，所述第一应用程序通过与服务器预约的第一协议得到令牌，包括：

第一应用程序按照与服务器预约的第一协议向服务器发送令牌请求；

第一应用程序接收服务器依据所述令牌请求返回的令牌。

根据本发明的另一方面，提供一种iOS平台scheme传送方法，该方法包括：

服务器接收第二应用程序通过与服务器预约的第二协议发送的携带令牌的服务参数请求；

服务器从所述服务参数请求中解析出所述令牌，并向第二应用程序返回与所述令牌相关的服务参数信息。

优选的，所述方法还包括：

服务器接收第一应用程序按照与服务器预约的第一协议发送的令牌请求；

服务器根据所述令牌请求向第一应用程序返回令牌，以供第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌。

优选的，所述服务器从所述服务参数请求中解析出所述令牌，并返回与所述令牌相关的服务参数信息包括：

服务器从所述服务参数请求中解析出所述令牌；

服务器按照与第一应用程序预约的第一协议中的解密算法或者逆映射算 法生成与所述令牌相关的服务参数信息，并向第二应用程序返回所述服务参数信息。

根据本发明的另一方面，提供一种iOS平台scheme传送装置，该装置包括：

第一控制单元，用于控制第一应用程序通过与服务器预约的第一协议得到令牌；

第二控制单元，用于控制第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌；

第三控制单元，用于控制第二应用程序通过与服务器预约的第二协议向服务器发送携带所述令牌的服务参数请求，以请求服务器返回与所述令牌相关的服务参数信息。

优选的，所述第一控制单元，具体用于控制第一应用程序按照与服务器预约的第一协议中的加密算法或者映射算法生成供第二应用程序从服务器请求服务参数的令牌。

优选的，所述第一控制单元，包括：

控制发送子单元，用于控制第一应用程序按照与服务器预约的第一协议向服务器发送令牌请求；

控制接收子单元，用于控制第一应用程序接收服务器依据所述令牌请求返回的令牌。

根据本发明的另一方面，提供一种服务器，该服务器包括：

服务参数请求接收单元，用于接收第二应用程序通过与服务器预约的第二协议发送的携带令牌的服务参数请求；

服务参数信息返回单元，用于从所述服务参数请求中解析出所述令牌，并向第二应用程序返回与所述令牌相关的服务参数信息。

优选的，所述服务器还包括：

令牌请求接收单元，用于接收第一应用程序按照与服务器预约的第一协议发送的令牌请求；

令牌返回单元，用于根据所述令牌请求向第一应用程序返回令牌，以供第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所 述令牌。

优选的，所述服务参数信息返回单元包括：

令牌解析子单元，用于从所述服务参数请求中解析出所述令牌；

参数返回子单元，用于按照与第一应用程序预约的第一协议中的解密算法或者逆映射算法生成与所述令牌相关的服务参数信息，并向第二应用程序返回所述服务参数信息。

根据本发明的另一方面，提供一种iOS平台scheme传送系统，包括：上述服务器和智能终端，其中，

所述智能终端包括上述iOS平台scheme传送装置；所述智能终端的操作系统为iOS系统且至少安装两个应用程序，其中一个应用程序作为第一应用程序，与其通信的另一个应用程序作为第二应用程序，所述智能终端通过iOS平台scheme传送装置控制第一应用程序和第二应用程序通过所述服务器实现程序间通信。

由上述实施例可以看出，与现有技术相比本发明的优点在于：

本发明在两个应用程序间通过URL scheme来传送参数信息时，首先由发起方第一应用程序通过与服务器预约的第一协议得到令牌，然后，第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌；最后，由第二应用程序通过与服务器预约的第二协议向服务器发送携带所述令牌的服务参数请求，以请求服务器返回与所述令牌相关的服务参数信息。本发明引入了服务器，通过应用程序与服务器间预约协议的方式以及通过传输令牌的方式，使得应用程序间不直接传输参数信息的明文信息，而是通过传送令牌来触发服务器进行相应处理，由于令牌不是实际的参数信息，因此，黑客拦截到令牌也无法获得要传递的参数信息，更为重要的是，黑客不知道第二应用程序与服务器之间的通信协议，即便黑客拦截到令牌，其也无法从服务器获得实际的参数信息，因此，本发明通过令牌及引入服务器确保在实现URL scheme传送信息时，不会出现信息泄露的问题，保证传送信息的安全性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明终端侧的iOS平台scheme传送方法的第一流程图；

图2为本发明服务器侧的iOS平台scheme传送方法的第一流程图；

图3为本发明的iOS平台scheme传送装置的结构图；

图4为本发明的服务器的第一结构图；

图5为本发明的服务器的第二结构图；

图6为本发明iOS平台scheme传送系统的示意图。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面通过实施例进行描述。

参阅图1，图1示出了本发明实施例一种iOS平台scheme传送方法的流程图，如图1所示，本实施例的方法可以包括：

S101,第一应用程序通过与服务器预约的第一协议得到令牌。

本实施例的方法具体应用在iOS平台的终端中，如iPhone、iPod touch、iPad以及Apple TV等终端，在这些终端上至少已安装有两个应用程序，以支持iOS平台scheme传送功能，实现两个应用程序的通信。

在本实施例中提到的第一应用程序和第二应用程序是指安装在同一终端上的两个不同的应用程序。本实施例的方法是从终端侧的角度描述的，以第一应用程序作为发起方，第二应用程序作为接收方，而第一应用程序和第二 应用程序可以是终端上安装的任意两个应用程序。

本实施例的方法为了防止iOS平台scheme传送的出现信息泄露的问题，在实现过程中引入了服务器。第一应用程序(发起方)和服务器需要预先约定一个协议，该协议作为第一协议，在实现应用程序间通信时，第一应用程序必须遵循第一协议实现发送功能。

上文中的令牌是一种能够控制站点占有媒体的特殊帧，以区别数据帧及其他控制帧。令牌(token)通俗点可以称为暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据操作。

关于第一应用程序如何得到令牌，本发明还提供了以下两种实现方式，下面依次进行解释说明。

第一种实现方式：第一应用程序按照与服务器预约的第一协议中的加密算法或者映射算法生成供第二应用程序从服务器请求服务参数的令牌。

在第一种实现方式中，第一应用程序独立按照与服务器预约的第一协议完成加密或者映射处理得到令牌；服务器中则预先保存着与第一应用程序预约的解密算法或者逆映射算法以便后续为第二应用程序提供解析信息的服务；而在第一应用程序得到令牌的过程中，不再需要服务器对信息处理，节省服务器的访问压力。

第二种实现方式：第一应用程序按照与服务器预约的第一协议向服务器发送令牌请求；以及第一应用程序接收服务器依据所述令牌请求返回的令牌。

在第二种实现方式中，第一应用程序需要先向服务器发送令牌请求，由服务器生成令牌返回给第一应用程序，服务器储存有与令牌对应的相关参数信息，以支持后续的第二应用程序的服务参数请求。

S102，第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌。

S103，第二应用程序通过与服务器预约的第二协议向服务器发送携带所述令牌的服务参数请求，以请求服务器返回与所述令牌相关的服务参数信息。

第一应用程序得到令牌之后，按照URL scheme调用方式，通过第二应用程序注册的URL scheme向第二应用程序发送令牌。这样，对于第一应用程序和第二应用程序而言，两者间传输的是令牌，而不是参数信息。在第二应用 程序接收到令牌之后，通过与服务器预约的第二协议向服务器发送携带令牌的服务参数请求，以请求服务器返回与令牌相关的服务参数信息。

首先，由于令牌token不是实际的参数信息，因此，即便黑客拦截到token，也无法获得要传递的参数信息，其次，黑客不知道第二应用程序与服务器之间有预约的通信协议，所以，黑客拿到token后并不知道要想服务器发送服务参数请求，即便是知道有服务器的存在，也无法破解出第二应用程序与服务器间预约好的协议，因此也无法从服务器获取真正的参数信息。可见，本发明在保证应用程序间正常通信的同时，又能够防止信息泄露。

下面以具体的应用场景为例对上述实施例的方案进行解释说明。

例如，发送方应用程序和接收方应用程序分别属于两家公司，这两家公司合作运营一个活动，该活动内容是凡是在发送方应用程序内到达一个指定界面的用户，就可以去接收方应用程序中领取一个红包。

首先，接收方应用程序先注册一个URL scheme，例如：hongbaoA。

然后，发送方应用程序从服务器请求一个红包的令牌token；

接着，发送方应用程序把token通过URL scheme调用方式发送给接收方应用程序。例如：hongbaoA://hongbaoId＝token将token传递给接收方应用程序。

最后，接收方应用程序接收到token时，按照与服务器预约的协议向服务器发送携带有token的服务参数请求，服务器接收请求之后，找到与token相关的红包信息，比如红包的金额、红包的有效期、红包的使用方式等，服务器将红包信息返回给接收方应用程序。此时，接收方应用程序才能获取到真正的参数信息。

在整个过程中，由于token并不是真正的参数信息，因此即便是黑客拦截到token，也无法直接得到参数信息，进一步地，黑客并不知道整个传输机制中有服务器的参与，即使知道，也很难破解接收方应用程序与服务器之间的协议，因此，其无法从服务器获取真正的参数信息。可见，本发明在保证应用程序间的正常通信时，能够做到防止信息泄露。

上文针对终端侧的应用程序角度描述了本发明iOS平台scheme传送方 法，对应的，本发明还从服务器角度提供了对应的传送方法。

参阅图2，图2示出了本发明服务器侧的iOS平台scheme传送方法的流程图，如图2所示，本实施例的方法可以包括：

S201，服务器接收第二应用程序通过与服务器预约的第二协议发送的携带令牌的服务参数请求。

在本实施例中，第二应用程序是指应用程序间通信过程中的接收方应用程序。这里的令牌是由第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送的；而第一应用程序就是应用程序间通信过程中的发送方应用程序。

S202，服务器从所述服务参数请求中解析出所述令牌，并向第二应用程序返回与所述令牌相关的服务参数信息。

对于接收方应用程序来讲，在于发送方应用程序进行通信时，接收到发送方应用程序发送的令牌之后，直接向服务器发送服务参数请求，由服务器向接收方应用程序返回具体的参数信息。

服务器和第二应用程序预约的第二协议可以约定好通过身份验证信息如ID或者其他标识号(除了“URL scheme”之外的标识号)来进行通信，这样，服务器在接收到第二应用程序发送的服务参数请求时，先对其身份进行验证，在验证通过时，才继续为其提供对应的服务。在这种传送机制下，黑客只知道通过伪造相同的URL scheme去窃取参数信息，并不知道与服务器交互以获得真正的参数信息，更加不知道有预约的协议的渠道，也不知道协议内容是什么，因此，对于黑客而言，伪造了URL scheme也只能得到令牌，无法得到真正的参数信息。

由于服务器参与了应用程序间的通信，使得应用程序间不直接传输参数信息，而是仅传输令牌，以防止黑客直接拦截参数信息；另外，接收方应用程序与服务器间按照预约的协议来进行通信，一方面黑客无法知道需要与服务器来进行通信，另一方面黑客很难破解协议，也无法从服务器获取真正的参数信息。

在具体实现时，服务器还可以为第一应用程序生成令牌，以参与整个通信过程，具体的在上述方法的基础上，所述方法还包括：

服务器接收第一应用程序按照与服务器预约的第一协议发送的令牌请求；以及，

服务器根据所述令牌请求向第一应用程序返回令牌，以供第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌。

优选的，所述服务器从所述服务参数请求中解析出所述令牌，并返回与所述令牌相关的服务参数信息包括：

服务器从所述服务参数请求中解析出所述令牌；

服务器按照与第一应用程序预约的第一协议中的解密算法或者逆映射算法生成与所述令牌相关的服务参数信息，并向第二应用程序返回所述服务参数信息。

这样，在应用程序间的参数信息的发送过程和接收过程，均需要服务器的参与，且最重要的参数信息只由服务器管理，因此能够解决应用程序间的信息泄露问题。

上文针对iOS平台scheme传送方法进行了描述，对应的，本发明提供了对应的传送装置。

参阅图3，图3示出了本发明的iOS平台scheme传送装置的结构图，如图3所示，本实施例的装置应用于终端侧，该装置可以包括：

第一控制单元301，用于控制第一应用程序通过与服务器预约的第一协议得到令牌；

第二控制单元302，用于控制第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌；

第三控制单元303，用于控制第二应用程序通过与服务器预约的第二协议向服务器发送携带所述令牌的服务参数请求，以请求服务器返回与所述令牌相关的服务参数信息。

优选的，第一控制单元，具体用于控制第一应用程序按照与服务器预约的第一协议中的加密算法或者映射算法生成供第二应用程序从服务器请求服务参数的令牌。

优选的，第一控制单元，包括：

控制发送子单元，用于控制第一应用程序按照与服务器预约的第一协议 向服务器发送令牌请求；

控制接收子单元，用于控制第一应用程序接收服务器依据所述令牌请求返回的令牌。

上文针对服务器侧的iOS平台scheme传送方法进行了描述，对应的，本发明提供了对应的服务器。

参阅图4，图4示出了本发明的服务器的第一结构图，如图4所示，该服务器可以包括：

服务参数请求接收单元401，用于接收第二应用程序通过与服务器预约的第二协议发送的携带令牌的服务参数请求；

服务参数信息返回单元402，用于从所述服务参数请求中解析出所述令牌，并向第二应用程序返回与所述令牌相关的服务参数信息。

参阅图5，图5示出了本发明的服务器的第二结构图，如5所示的服务器是在图4的基础上还包括：

令牌请求接收单元403，用于接收第一应用程序按照与服务器预约的第一协议发送的令牌请求；

令牌返回单元404，用于根据所述令牌请求向第一应用程序返回令牌，以供第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌。

优选的，所述服务参数信息返回单元包括：

令牌解析子单元，用于从所述服务参数请求中解析出所述令牌；

参数返回子单元，用于按照与第一应用程序预约的第一协议中的解密算法或者逆映射算法生成与所述令牌相关的服务参数信息，并向第二应用程序返回所述服务参数信息。

另外，本发明提供了一种iOS平台scheme传送系统。

参阅图6，图6示出了本发明的iOS平台scheme传送系统的示意图，如图6所示，该系统包括：智能终端601和服务器602，其中，

所述智能终端包括上述iOS平台scheme传送装置；所述智能终端的操作系统为iOS系统且至少安装两个应用程序，其中一个应用程序作为第一应用程序，与其通信的另一个应用程序作为第二应用程序，所述智能终端通过iOS 平台scheme传送装置控制第一应用程序和第二应用程序通过所述服务器实现程序间通信。

其中，iOS平台scheme传送装置可以参见图3相关描述，服务器602的结构可以参见图4和图5相关描述。智能终端和服务器可以通过有线方式通信也可以通过无线方式通信。

通过上述实施例可以看出，本发明提供的iOS平台scheme传送系统，利用服务器为应用程序间的信息传送提供安全性保障，使得第一应用程序按照与服务器预约的第一协议生成令牌，然后，第一应用程序通过第二应用程序注册的URL scheme向第二应用程序发送所述令牌；最后，由第二应用程序通过与服务器预约的第二协议向服务器发送携带所述令牌的服务参数请求，以请求服务器返回与所述令牌相关的服务参数信息。由于引入了服务器，通过应用程序与服务器间预约协议的方式以及通过传输令牌的方式，使得应用程序间不直接传输参数信息的明文信息，而是通过传送令牌来触发相应处理，由于令牌不是实际的参数信息，因此，即便黑客拦截到也无法获得要传递的参数信息，其次，黑客不知道第二应用程序与服务器之间的通信协议，其无法从服务器获得实际的参数信息，因此，本发明提供的系统能够确保在实现URL scheme传送信息时，规避信息泄露。

本领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述到的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或 者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，可以采用软件功能单元的形式实现。

需要说明的是，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上对本发明所提供的iOS平台scheme传送方法、装置、服务器以及系统进行了详细介绍，本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。