CN103095666B - 第三方应用处理方法及装置 - Google Patents

Abstract

本申请提供了一种第三方应用处理方法及装置，其中，第三方应用处理方法包括：第一平台接收请求第三方应用的第一请求信息，第一请求信息中携带有应用权限信息和使用权限信息，应用权限信息用于确定所请求的第三方应用是否具有使用第一平台的权限，使用权限信息用于确定所请求的第三方应用是否具有使用提供该应用的第二平台的权限；第一平台对第一请求信息中的应用权限信息进行验证，并在验证通过后，向第二平台发送第二请求信息，第二请求信息携带有使用权限信息；在第二平台对第二请求信息中的使用权限信息进行验证并通过后，第一平台接收第二平台返回的对第二请求信息的处理结果。通过本申请，提高了第三方应用处理速度和效率和用户使用体验。

Description

第三方应用处理方法及装置

技术领域

本申请涉及网络技术领域，特别是涉及一种第三方应用处理方法及装置。

背景技术

随着网络技术的不断发展，越来越多的工作和生活依赖于网络进行，如网上商品交易等。同时，人们对网上提供的服务的各种个性化需求，诸如要求服务快捷、安全、方便等，也越来越高。针对这些不同的个性化需求，网络服务的提供者开始对网络资源进行整合，为用户提供更加方便、灵活的服务。

一种较为典型的整合方式是，通过向第三方应用提供相应的接口，将第三方应用的部分或全部资源整合到自身平台。以淘宝网提供的开放平台为例，淘宝开放平台是淘宝面向第三方应用开发者，提供API接口和相关开发环境的开放平台。软件开发者可通过淘宝API来获取多种信息，如淘宝用户信息、淘宝商品信息、淘宝商品类目信息、淘宝店铺信息、淘宝交易明细信息(在取得用户授权的情况下)、淘宝商品管理等信息，并建立相应的电子商务应用。但是，目前第三方应用独立于淘宝体系，造成使用第三方应用时，业务或应用获取的不便。

以第三方应用为直通车业务为例，直通车业务通过淘宝的开放平台提供的支持第三方应用的API接口，接入到了淘宝的开放平台。但是，直通车业务不同于淘宝提供的业务，直通车账户体系也不依赖于淘宝的账户体系，而淘宝的开放平台只能验证淘宝账户体系，同时，直通车账户存在关联的子账户，以及非淘宝账户等情况，且各种账户对于直通车业务的操作权限都是不一样的，所以直通车业务的API权限验证体系不同于传统的开放平台权限验证。由此，在对第三方应用进行处理时，既需要在普通的开放平台端进行权限验证，也需要在直通车端进行权限验证，只有双方验证均通过后，才能进行相应的第三方应用处理，获取相应的应用或业务。

这种重复验证方式一方面降低了第三方应用的处理速度和效率，另一方面也降低了用户使用网络服务的使用体验。

发明内容

本申请实施例提供了一种第三方应用处理方法及装置，以解决现有技术中，在软件平台访问第三方应用时，第三方应用处理速度和效率低，用户使用体验不高的问题。

为了解决上述问题，本申请公开了一种第三方应用处理方法，包括：第一平台接收请求第三方应用的第一请求信息，所述第一请求信息中携带有应用权限信息和使用权限信息，所述应用权限信息用于确定所请求的所述第三方应用是否具有使用所述第一平台的权限，所述使用权限信息用于确定所请求的所述第三方应用是否具有使用提供该应用的第二平台的权限；所述第一平台对所述第一请求信息中的应用权限信息进行验证，并在验证通过后，向所述第二平台发送第二请求信息，所述第二请求信息携带有所述使用权限信息；在所述第二平台对所述第二请求信息中的使用权限信息进行验证并通过后，所述第一平台接收所述第二平台返回的对所述第二请求信息的处理结果。

优选地，所述第一请求信息和/或第二请求信息中还携带有权限标识，所述权限标识用于标识所述应用权限信息是否通过验证；在所述第一平台通过对所述应用权限信息的验证之后，向所述第二平台发送第二请求信息之前，所述方法还包括：所述第一平台设置所述权限标识为所述应用权限信息通过验证。

优选地，所述第一平台向所述第二平台发送第二请求信息的步骤包括：所述第一平台确定所述权限标识为应用权限信息通过验证；所述第一平台向提供所述所请求的第三方应用的所述第二平台发送所述第二请求信息。

优选地，所述第二平台为直通车业务平台。

优选地，所述第一请求信息和第二请求信息为会话Session消息。

为了解决上述问题，本申请还公开了一种第三方应用处理装置，所述装置设置于第一平台，所述装置包括：第一接收模块，用于接收请求第三方应用的第一请求信息，所述第一请求信息中携带有应用权限信息和使用权限信息，所述应用权限信息用于确定所请求的所述第三方应用是否具有使用所述第一平台的权限，所述使用权限信息用于确定所请求的所述第三方应用是否具有使用提供该应用的第二平台的权限；应用权限验证模块，用于对所述第一请求信息中的应用权限信息进行验证，并在验证通过后，向所述第二平台发送第二请求信息，所述第二请求信息携带有所述使用权限信息；第二接收模块，用于在所述第二平台对所述第二请求信息中的使用权限信息进行验证并通过后，接收所述第二平台返回的对所述第二请求信息的处理结果。

优选地，所述第一请求信息和/或第二请求信息中还携带有权限标识，所述权限标识用于标识所述应用权限信息是否通过验证；所述装置还包括：设置模块，用于在所述应用权限验证模块通过对所述应用权限信息的验证之后，向所述第二平台发送第二请求信息之前，设置所述权限标识为所述应用权限信息通过验证。

优选地，所述应用权限验证模块，用于对所述第一请求信息中的应用权限信息进行验证，并在验证通过，且确定所述权限标识为应用权限信息通过验证后，向提供所述所请求的第三方应用的所述第二平台发送所述第二请求信息。

优选地，所述第二平台为直通车业务平台。

优选地，所述第一请求信息和第二请求信息为会话Session消息。

与现有技术相比，本申请具有以下优点：

本申请在第一平台(如淘宝开放平台)接收到请求第三方应用的第一请求信息后，仅对其中的应用权限信息进行验证，以确定第一请求信息请求的第三方应用是否具有使用第一平台的权限，而不对其中的使用权限信息进行验证。相反，在确定所请求的第三方应用具有使用第一平台的权限后，向提供所请求的第三方应用的第二平台发送携带有使用权限信息的第二请求信息，由第二平台直接对第二请求信息中的使用权限信息进行验证，而不必再次验证应用权限信息。也即，将应用权限验证与使用权限验证分离开来。通过应用权限验证与使用权限验证的分离，在实现第一平台对第三方应用接入控制的同时，也解决跨平台的第三方应用的使用用户的使用权限控制。负责接入的平台(第一平台)只需要验证应用本身的权限，而使用者的权限由平台后端具体业务模块(第二平台)来负责。这样，无须重复验证，在软件平台访问第三方应用时，大大提高了第三方应用处理速度和效率，也提升了用户使用体验。

附图说明

图1是根据本申请实施例一的一种第三方应用处理方法的步骤流程图；

图2是根据本申请实施例二的一种第三方应用处理方法的步骤流程图；

图3是根据本申请实施例三的一种第三方应用处理方法的步骤流程图；

图4是根据相关技术的一种第三方应用处理方法的整体流程图；

图5是图4所示第三方应用处理方法中的直通车平台的处理流程图；

图6是根据本申请实施例四的一种第三方应用处理装置的结构框图；

图7是根据本申请实施例五的一种第三方应用处理装置的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

实施例一

参照图1，其示出了根据本申请实施例一的一种第三方应用处理方法的步骤流程图。

本实施例的第三方应用处理方法包括以下步骤：

步骤S102：第一平台接收请求第三方应用的第一请求信息。

其中，第一请求信息中携带有应用权限信息和使用权限信息，应用权限信息用于确定所请求的第三方应用是否具有使用第一平台的权限，使用权限信息用于确定所请求的第三方应用是否具有使用提供该第三方应用的第二平台的权限。

其中，第一平台具有支持第三方应用的接口，以便接入第三方应用。

步骤S104：第一平台对第一请求信息中的应用权限信息进行验证，并在验证通过后，向第二平台发送第二请求信息。

其中，第二请求信息携带有使用权限信息。

本步骤中，第一平台仅对第一请求信息中的应用权限信息进行验证，在验证通过，确定第一请求信息所请求的第三方应用具有使用第一平台的权限后，向第二平台发送第二请求信息，将使用权限信息交由第二平台进行验证。其中，第二请求信息中可以仅携带使用权限信息，也可以同时携带使用权限信息和应用权限信息；第一请求信息和第二请求信息可以是不同的信息，也可以是同一个信息。

步骤S106：在第二平台对第二请求信息中的使用权限信息进行验证并通过后，第一平台接收第二平台返回的对第二请求信息的处理结果。

本步骤中，第二平台在接收到第一平台发送来的第二请求信息后，认为第一平台已通过应用权限信息的验证，因此，仅为使用权限信息进行验证，以确定所请求的第三方应用是否具有使用第二平台的权限。在第二平台确定所请求的第三方应用具有使用第二平台的权限后，向第一平台返回对第二请求信息的处理结果。

通过本实施例，第一平台和第二平台分别对应用权限信息和使用权限信息进行验证，实现了应用权限验证和使用权限验证的分离。在第一平台(如淘宝开放平台)接收到请求第三方应用的第一请求信息后，仅对其中的应用权限信息进行验证，以确定第一请求信息请求的第三方应用是否具有使用第一平台的权限，而不对其中的使用权限信息进行验证。相反，在确定所请求的第三方应用具有使用第一平台的权限后，由第一平台将使用权限信息发送至提供所请求的第三方应用的第二平台(如直通车业务平台)，由第二平台对使用权限信息进行验证，而不必再次验证第一请求信息中的应用权限信息。也即，将应用权限验证与使用权限验证分离开来。通过应用权限验证与使用权限验证的分离，在实现第一平台对第三方应用接入控制的同时，也解决跨平台的第三方应用的使用用户的使用权限控制。负责接入的平台(第一平台)只需要验证应用本身的权限，而使用者的权限由平台后端具体业务模块(第二平台)来负责。这样，无须重复验证，这大大提高了第三方应用处理速度和效率，也提升了用户使用体验。

实施例二

参照图2，其示出了根据本申请实施例二的一种第三方应用处理方法的步骤流程图。

本实施例的第三方应用处理方法包括以下步骤：

步骤S202：第一平台接收业务端发送的第一请求信息。

第一请求信息用于请求第三方应用，其中携带有用于确定所请求的第三方应用是否具有使用第一平台的应用权限信息，和用于确定所请求的第三方应用是否具有使用提供该所请求的第三方应用的第二平台的使用权限信息。

优选地，第一请求信息中还可以携带标识信息，以标识应用权限信息是否通过验证。权限标识可以为一个权限标志位，也可以为直通车令牌，还可以由本领域技术人员根据实际需求，设置为任意能够表示应用权限信息通过第一平台验证的标识。通过设置标识信息，可以使第二平台方便快捷地获知第一平台对应用权限信息的验证情况，进一步提高了第三方应用处理速度和效率；并且，有效避免了绕过第一平台的第三方应用请求，进一步保障了合法用户使用第三方应用的安全性。

第一平台具有支持第三方应用的接口，能够提供第三方应用的接入服务，如淘宝的开放平台，但不限于此，任意具有支持第三方应用的接口，能够提供第三方应用的接入服务的平台均可作为本实施例的第一平台。

步骤S204：第一平台从第一请求信息中获取应用权限信息。

本步骤中，第一平台仅需从第一请求信息中获取应用权限信息，以确定所请求的第三方应用是否可以使用第一平台，而不需获取第一请求信息中的使用权限信息。

步骤S206：第一平台对获取的应用权限信息进行验证，判断请求信息所请求的第三方应用是否具有使用第一平台的权限，若具有，则执行步骤S208；若不具有，则向发送第一请求信息的业务端反馈验证结果，返回步骤S202，继续接收其它请求信息。

优选地，若应用权限信息通过验证，即第一请求信息所请求的第三方应用具有使用第一平台的权限，则第一平台将权限标识设置为应用权限信息通过验证，携带在第二请求信息中，以便一同发送给第二平台。

步骤S208：第一平台将第二请求信息发送给第二平台。

本实施例中，第二请求信息中携带有使用权限信息和设置后的权限标识。

优选地，第一平台通过确定权限标识为应用权限信息通过验证，来决定将第二请求信息发送给第二平台。

第二平台为提供第三方应用的平台，如淘宝直通车业务平台，但不限于此，任意其它能够提供第三方应用的平台，如其它直通车平台或提供第三方应用的其它平台，均可作为本实施例的第二平台。

步骤S210：第二平台接收第一平台发送的第二请求信息，从中获取使用权限信息。

本步骤中，第二平台仅需从第二请求信息中获取使用权限信息，以确定第一请求信息所请求的第三方应用是否可以使用第二平台，而不再获取应用权限信息。

优选地，第二平台同时获取第二请求信息中的权限标识，通过权限标识确定所请求的第三方应用已通过第一平台的应用权限验证，而不再向第一平台要求进行应用权限验证。

步骤S212：第二平台对获取的使用权限信息进行验证，判断所请求的第三方应用是否具有使用第二平台的权限，若具有，则执行步骤S214；若不具有，则向第一平台反馈使用权限信息验证结果，进而由第一平台将该结果反馈给请求第三方应用的业务端，然后，可以继续执行步骤S202。

步骤S214：第二平台向第一平台返回对第二请求信息的处理结果。

本实施例中，第一平台只获取应用权限信息的数据，第二平台只获取使用权限信息的数据，并进行相应的处理，从而减少了数据处理量，提高了数据处理效率。另外，权限标识的设置，一方面便于第一平台确定是否向第二平台发送第二请求信息，另一方面也使得第二平台准确获知第一平台对第一请求信息的处理情况，且不必重新从第一平台进行权限验证，大大提高了数据处理速度和效率。通过使用第一平台的应用权限与使用第二平台的使用权限的分离验证，提高了第三方应用的处理速度和效率，提升了用户使用体验。

实施例三

参照图3，其示出了根据本申请实施例三的一种第三方应用处理方法的步骤流程图。

本实施例中，第一平台以淘宝的开放平台为例，第二平台为淘宝直通车业务平台为例。

本实施例的第三方应用处理方法包括以下步骤：

步骤S302：淘宝开放平台接收请求第三方应用的第一请求信息。

本实施例中，第一请求信息中携带有权限标识，该权限标识可以为直通车令牌。

步骤S304：淘宝开放平台判断第一请求信息所请求的第三方应用是否具有使用淘宝开放平台的权限，若是，执行步骤S306；若否，则返回步骤S302。

具体地，淘宝开放平台可以通过判断第一请求信息中携带的、用于确定所请求的第三方应用是否具有使用淘宝开放平台权限的应用权限信息，判断所请求的第三方应用是否具有使用淘宝开放平台的权限。

步骤S306：淘宝开放平台设置直通车令牌，向直通车业务平台发送第二请求信息。

本实施例中，第二请求信息中携带有直通车令牌和是否能够使用直通车业务平台的使用权限信息。

步骤S308：直通车业务平台接收淘宝开放平台发送的第二请求信息。

步骤S310：直通车业务平台判断所请求的第三方应用是否具有使用直通车业务平台的权限，若是，执行步骤S312；若否，则返回步骤S302。

具体地，直通车业务平台通过第二请求信息中携带的、用于确定所请求的第三方应用是否具有使用直通车业务平台权限的使用权限信息，判断所请求的第三方应用是否具有使用直通车业务平台的权限。

并且，直通车业务平台通过第二请求信息中携带的直通车令牌，确定淘宝开放平台对所请求的第三方应用的权限验证情况，不再向淘宝开放平台要求应用权限的再次验证。

步骤S312：直通车业务平台向淘宝开放平台返回处理结果的信息。

本实施例的第三方应用处理方法将第三方应用的使用者权限从原有的开放平台统一验证的过程分离出来，将这个验证过程下置到具体的业务模块中实现。

例如，图4示出了根据相关技术的一种第三方应用处理方法的整体流程图。在该图所示的整体第三方应用处理方法中，首先，由淘宝开放平台接收一个业务端发送的请求第三方应用的请求信息；然后，淘宝开放平台对该请求信息所请求的第三方应用的应用权限与使用权限(即应用有效性和账户有效性)同时进行验证判断，若验证不通过，则淘宝开放平台继续接收其它请求信息，若验证通过，则将该请求信息交由直通车业务平台处理；直通车业务平台接收到淘宝开放平台发送的请求信息后，进一步进行后续处理，如图5所示，包括：先向淘宝开放平台请求应用权限判断，请求权限信息，在接收到开放平台返回的权限信息后，再对所请求的第三方应用的应用权限与使用权限(即应用有效性和账户有效性)同时进行验证判断，若验证不通过，则向淘宝开放平台进行反馈，以便淘宝开放平台继续接收其它请求信息，若验证通过，则向淘宝开放平台返回有效的处理信息。由此可见，该第三方应用处理方式重复地对相关权限进行验证，加大了处理第三方应用的负担，且反复验证也增加了不同平台间的信息交互次数和信息交互量，进而加大了信息处理负担，降低了第三方应用的处理速度和效率，权限的反复验证和交互也增加了处理第三方应用的时间，降低了用户的使用体验。

与图4和图5所示的根据相关技术的一种第三方应用处理方法相比，本实施例中，用户权限验证(即使用权限验证)从淘宝开放平台分离，而直接在直通车后台验证实现。通过本实施例，开放平台不再需要维护与验证基于各个业务方的账户权限体系，只需要专注于应用本身的权限体系。业务接入方(如本实施例中的直通车平台)不再需要每一次应用请求时前置一个访问平台权限的预处理过程，直接在直通车平台内部完成权限验证过程即可。

优选地，内部权限验证(包括应用权限验证和使用权限验证)可直接使用Session会话机制来实现，以减少验证应用本身的验证过程。请求第三方应用的第一和第二请求信息遵循Session会话机制，可以为Session会话消息。

另外，应用的使用者的权限体系(使用权限体系)可以实现与直通车用户的权限体系无缝对接，以实现非淘宝账户的验证、直通车特有的子账户验证等继承于直通车账户体系所特有的权限验证过程。

通过应用权限验证与账户权限验证(即使用权限验证)分离的方法，本实施例实现了对第三方应用接入的控制，同时，解决了跨平台的第三方应用的使用用户的权限控制。负责接入的平台(如淘宝开放平台)只需要验证应用本身的权限，而使用者的权限由平台后端具体业务模块(如直通车业务平台)来负责。从而，在软件平台访问第三方应用时，大大提高了第三方应用处理速度和效率，也提升了用户使用体验。

实施例四

参照图6，其示出了根据本申请实施例四的一种第三方应用处理装置的结构框图。

本实施例的第三方应用处理装置设置于第一平台，该平台能够支持第三方应用接入。本实施例的第三方应用处理装置包括：第一接收模块602，用于接收请求第三方应用的第一请求信息，第一请求信息中携带有应用权限信息和使用权限信息，应用权限信息用于确定所请求的第三方应用是否具有使用第一平台的权限，使用权限信息用于确定所请求的第三方应用是否具有使用提供该应用的第二平台的权限；应用权限验证模块604，用于对第一请求信息中的应用权限信息进行验证，并在验证通过后，向第二平台发送第二请求信息，第二请求信息中携带有使用权限信息；第二接收模块606，用于在第二平台对第二请求信息中的使用权限信息进行验证并通过后，接收第二平台返回的对第二请求信息的处理结果。

通过本实施例，在第一平台(如淘宝开放平台)接收到请求第三方应用的第一请求信息后，仅对其中的应用权限信息进行验证，以确定第一请求信息请求的第三方应用是否具有使用第一平台的权限，而不对其中的使用权限信息进行验证。相反，在确定所请求的第三方应用具有使用第一平台的权限后，将该请求信息中的使用权限信息发送至提供所请求的第三方应用的第二平台(如直通车业务平台)，由第二平台直接对使用权限信息进行验证，而不必再次验证请求信息中的应用权限信息。也即，将应用权限验证与使用权限验证分离开来。通过应用权限验证与使用权限验证的分离，在实现第一平台对第三方应用接入的控制的同时，也解决跨平台的第三方应用的使用用户的使用权限控制。负责接入的平台(第一平台)只需要验证应用本身的权限，而使用者的权限由平台后端具体业务模块(第二平台)来负责。这样，无须重复验证，在软件平台访问第三方应用时，大大提高了第三方应用处理速度和效率，也提升了用户使用体验。

实施例五

参照图7，其示出了根据本申请实施例五的一种第三方应用处理装置的结构框图。

本实施例的第三方应用处理装置为图6所示装置的优选结构装置，在包括图6所示第三方应用处理装置的结构的基础上，还包括优选结构。

具体地，本实施例中，设置于第一平台的第三方应用处理装置包括：

第一接收模块702，用于接收请求第三方应用的第一请求信息，第一请求信息中携带有应用权限信息和使用权限信息，应用权限信息用于确定所请求的第三方应用是否具有使用第一平台的权限，使用权限信息用于确定所请求的第三方应用是否具有使用提供该应用的第二平台的权限；应用权限验证模块704，用于对第一请求信息中的应用权限信息进行验证，并在验证通过后，向第二平台发送携带有使用权限信息的第二请求信息；第二接收模块706，用于在第二平台对第二请求信息中的使用权限信息进行验证并通过后，接收第二平台返回的对第二请求信息的处理结果。

优选地，本实施例中的第一和/或第二请求信息中还携带有权限标识，该权限标识用于标识所述应用权限信息是否通过验证；本实施例的第三方应用处理装置还包括：设置模块708，用于在应用权限验证模块704通过对应用权限信息的验证之后，将第二请求信息发送到第二平台之前，设置权限标识为应用权限信息通过验证。

优选地，应用权限验证模块704，用于对第一请求信息中的应用权限信息进行验证，并在验证通过，且确定权限标识为应用权限信息通过验证后，将第二请求信息发送到提供所请求的第三方应用的第二平台。

优选地，第二平台为直通车业务平台。

优选地，请求信息为会话Session消息。

需要说明的是，本申请中的上述装置实施例中的第三方应用处理装置用于实现前述方法实施例中相应的第三方应用处理方法，并具有前述方法实施例的有益效果，在此不再赘述。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

Claims (10)

1.一种第三方应用处理方法，其特征在于，包括：

第一平台接收请求第三方应用的第一请求信息，所述第一请求信息中携带有应用权限信息和使用权限信息，所述应用权限信息用于确定所请求的所述第三方应用是否具有使用所述第一平台的权限，所述使用权限信息用于确定所请求的所述第三方应用是否具有使用提供该应用的第二平台的权限；

所述第一平台对所述第一请求信息中的应用权限信息进行验证，并在验证通过后，向所述第二平台发送第二请求信息，所述第二请求信息携带有所述使用权限信息；

在所述第二平台对所述第二请求信息中的使用权限信息进行验证并通过后，所述第一平台接收所述第二平台返回的对所述第二请求信息的处理结果。

2.根据权利要求1所述的方法，其特征在于，所述第一请求信息和/或第二请求信息中还携带有权限标识，所述权限标识用于标识所述应用权限信息是否通过验证；

在所述第一平台通过对所述应用权限信息的验证之后，向所述第二平台发送第二请求信息之前，所述方法还包括：所述第一平台设置所述权限标识为所述应用权限信息通过验证。

3.根据权利要求2所述的方法，其特征在于，所述第一平台向所述第二平台发送第二请求信息的步骤包括：

所述第一平台确定所述权限标识为应用权限信息通过验证；

所述第一平台向提供所述所请求的第三方应用的所述第二平台发送所述第二请求信息。

4.根据权利要求1、2或3所述的方法，其特征在于，所述第二平台为直通车业务平台。

5.根据权利要求1、2或3所述的方法，其特征在于，所述第一请求信息和第二请求信息为会话Session消息。

6.第三方应用处理装置，其特征在于，所述装置设置于第一平台，所述装置包括：

第一接收模块，用于接收请求第三方应用的第一请求信息，所述第一请求信息中携带有应用权限信息和使用权限信息，所述应用权限信息用于确定所请求的所述第三方应用是否具有使用所述第一平台的权限，所述使用权限信息用于确定所请求的所述第三方应用是否具有使用提供该应用的第二平台的权限；

应用权限验证模块，用于对所述第一请求信息中的应用权限信息进行验证，并在验证通过后，向所述第二平台发送第二请求信息，所述第二请求信息携带有所述使用权限信息；

第二接收模块，用于在所述第二平台对所述第二请求信息中的使用权限信息进行验证并通过后，接收所述第二平台返回的对所述第二请求信息的处理结果。

7.根据权利要求6所述的装置，其特征在于，所述第一请求信息和/或第二请求信息中还携带有权限标识，所述权限标识用于标识所述应用权限信息是否通过验证；

所述装置还包括：

设置模块，用于在所述应用权限验证模块通过对所述应用权限信息的验证之后，向所述第二平台发送第二请求信息之前，设置所述权限标识为所述应用权限信息通过验证。

8.根据权利要求7所述的装置，其特征在于，所述应用权限验证模块，用于对所述第一请求信息中的应用权限信息进行验证，并在验证通过，且确定所述权限标识为应用权限信息通过验证后，向提供所述所请求的第三方应用的所述第二平台发送所述第二请求信息。

9.根据权利要求6、7或8所述的装置，其特征在于，所述第二平台为直通车业务平台。

10.根据权利要求6、7或8所述的装置，其特征在于，所述第一请求信息和第二请求信息为会话Session消息。