CN115543646A - 联系人的处理方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种联系人的处理方法、装置、计算机设备和存储介质。所述方法包括：显示第一应用中的目标应用交互界面，第一应用通过第一用户标识登录；响应于在目标应用交互界面中触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面；在跨应用联系人添加界面中确定待添加的联系人后，向与联系人对应的第二用户标识发送联系人交互通知，第二用户标识是属于第二应用的用户标识，第一应用与第二应用为不同的应用程序。采用本方法能够提升添加联系人的便捷性与效率。

Description

联系人的处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种联系人的处理方法、装置、计算机设备和存储介质。

背景技术

随着计算机技术的发展，各式各样的应用程序成为人们日常生活不可或缺的通讯工具，大量的信息得以通过应用程序尤其是即时通信应用被便捷地传播。目前有些应用不仅可以独立运行，还可以依赖于即时通信应用提供的资源与环境运行。

由于不同的应用之间是相互独立的，目前，即便目标应用运行于某个原生应用之上，使用目标应用的用户若想与客户交互，如添加客户为联系人，或建立与客户之间的临时会话，一种方式是通过邀请客户同样注册目标应用之后，才能够在此基础之上通过目标应用建立联系人关系，这种添加联系人的方式需要客户额外安装并注册目标应用；另一种方式是，用户通过客户使用的其他即时通信应用去建立与客户之间的联系人关系。上述的方式均不能直接在运行于原生应用上的目标应用中发起添加联系人，导致添加联系人的操作繁琐、效率较低。

发明内容

基于此，有必要针对上述技术问题，提供一种能够的提升添加联系人的便捷性与效率的联系人的处理方法、装置、计算机设备和存储介质。

一种联系人的处理方法，所述方法包括：

显示第一应用中的目标应用交互界面，所述第一应用通过第一用户标识登录；

响应于在所述目标应用交互界面中触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面；

在所述跨应用联系人添加界面中确定待添加的联系人后，向与所述联系人对应的第二用户标识发送联系人交互通知，所述第二用户标识是属于第二应用的用户标识，所述第一应用与所述第二应用为不同的应用程序。

在一个实施例中，所述方法还包括：

进入以所述待添加的联系人对应的第二用户标识登录的第二应用；

在所述第二应用中，显示来自目标集体的所述第一用户标识的联系人交互通知；

响应于对所述联系人交互通知中的联系人添加操作，建立属于所述第二应用的第二用户标识与属于所述第二应用的第一用户标识之间的联系人关系。

在一个实施例中，所述方法还包括：

在所述第二应用中，显示所述第一用户标识在第二应用中的第一身份标识所对应的会话页面；

在所述会话页面中，向以所述第一用户标识登录的第一应用，发送来自所述第二用户标识的跨应用会话消息。

在一个实施例中，所述方法还包括：

在所述第一应用中，显示所述第二用户标识在第一应用中的第二身份标识所对应的会话页面；

在所述会话页面中，向以所述第二用户标识登录的第二应用，发送来自所述第一用户标识的跨应用会话消息。

一种联系人的处理装置，所述装置包括：

显示模块，用于显示第一应用中的目标应用交互界面，所述第一应用通过第一用户标识登录；

跳转模块，用于响应于在所述目标应用交互界面中触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面；

添加模块，用于在所述跨应用联系人添加界面中确定待添加的联系人后，向与所述联系人对应的第二用户标识发送联系人交互通知，所述第二用户标识是属于第二应用的用户标识，所述第一应用与所述第二应用为不同的应用程序。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

显示第一应用中的目标应用交互界面，所述第一应用通过第一用户标识登录；

响应于在所述目标应用交互界面中触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面；

在所述跨应用联系人添加界面中确定待添加的联系人后，向与所述联系人对应的第二用户标识发送联系人交互通知，所述第二用户标识是属于第二应用的用户标识，所述第一应用与所述第二应用为不同的应用程序。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

显示第一应用中的目标应用交互界面，所述第一应用通过第一用户标识登录；

响应于在所述目标应用交互界面中触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面；

在所述跨应用联系人添加界面中确定待添加的联系人后，向与所述联系人对应的第二用户标识发送联系人邀请通知，所述第二用户标识是属于第二应用的用户标识，所述第一应用与所述第二应用为不同的应用程序。

一种计算机程序，所述计算机程序包括计算机指令，所述计算机指令存储在计算机可读存储介质中，计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行上述联系人的处理方法的步骤。

上述联系人的处理方法、装置、计算机设备和存储介质，目标应用运行在作为原生应用的第一应用中，当以属于第一应用的第一用户标识登录了第一应用，并进入了第一应用中的目标应用交互界面之后，用户可以直接在该目标应用交互界面中触发联系人添加操作，目标应用就可以响应于该联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，当第一应用在跨应用联系人添加界面中确定待添加的联系人后，第一应用就能够向与该联系人对应的属于第二应用的第二用户标识发送联系人交互通知，触发跨应用添加属于第二应用的第二用户标识为联系人。这样，不需要双方都使用并注册目标应用，也可以通过目标应用建立第一用户标识与第二用户标识之间跨应用的联系人关系，也不需要双方都使用相同的第二应用才能建立联系人关系，从而提高了添加联系人的有效性与效率。

附图说明

图1为一个实施例中联系人的处理方法的应用环境图；

图2为一个实施例中联系人的处理方法的流程示意图；

图3为一个实施例中跨应用联系人添加界面的示意图；

图4为另一个实施例中跨应用联系人添加界面的示意图；

图5为一个实施例中生成集体权限验证配置信息的时序图；

图6为一个实施例中生成集体权限验证配置信息的时序图；

图7为一个实施例中从目标应用交互界面跳转至第一应用的跨应用联系人添加界面的流程示意图；

图8为一个实施例中从目标应用交互界面跳转至第一应用的跨应用联系人添加界面的界面示意图；

图9为一个实施例中从第一用户标识对应的第二应用联系人中确定待添加的联系人的界面示意图；

图10为一个实施例中从第一应用分享名片到第二应用的界面示意图；

图11为一个实施例中在第一应用搜索联系人显示用户信息的界面示意图；

图12为一个实施例中第二应用接收到的联系人邀请通知的界面示意图；

图13为一个实施例中通过邀请通知添加跨应用联系人的界面示意图；

图14为一个实施例中第二应用展示的与第一应用的联系人的会话页面的示意图；

图15为一个实施例中第一应用展示的与第二应用的联系人的会话页面的示意图；

图16为一个实施例中联系人的处理装置的结构框图；

图17为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的联系人的处理方法，可以应用于如图1所示的应用环境中。该应用场景包括第一终端102、第一应用服务器104、第二应用服务器106以及第二终端108。其中，第一终端102通过网络与第一应用服务器104进行通信，第一应用服务器104通过网络与第二应用服务器106进行通信，第二应用服务器106通过网络与第二终端108进行通信。第一应用服务器104为第一应用所对应的服务器，第二应用服务器106为第二应用所对应的服务器。

第一终端102中安装并运行有第一应用，该第一应用中登录有第一用户标识，目标应用运行于第一应用之上，目标应用可以是网页或基于第一应用提供的资源而运行的子应用。第二终端108中安装并运行有第二应用，该第二应用中登录有第二用户标识。当然，由于第一应用与第二应用是不同的应用程序(或称为客户端)，第一终端102中也可以安装并运行有第二应用，第二终端108中可以安装并运行有第一应用。第一应用与第二应用可以是不同的即时通信应用，比如，第一应用为属于集体中的用户与他人通信所使用的即时通信应用，第二应用为独立的用户与他人通信所使用的即时通信应用。本申请实施例所提出的跨应用联系人，指的就是在不同的第一应用与第二应用中相互添加为联系人，跨应用联系人可以相互发送跨应用会话消息。

第一终端102显示第一应用中的目标应用交互界面，第一应用通过第一用户标识登录；响应于在目标应用交互界面中触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面；在跨应用联系人添加界面中确定待添加的联系人后，向与联系人对应的第二用户标识发送联系人交互通知，第二用户标识是属于第二应用的用户标识，第一应用与第二应用为不同的应用程序。

其中，第一终端102和第二终端108可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，第一应用服务器104和第二应用服务器106可以用独立的服务器或者是多个服务器组成的服务器集群来实现。另外，第一应用服务器104和第二应用服务器106可以构成互通服务器集群。第一应用服务器104和第二应用服务器106也可以不是通过两个独立的服务器实现，而是替换为一个能够与第一终端以及第二终端进行交互的服务器或者服务器集群实现。

如本申请所提供的联系人的处理方法、装置、计算机设备和存储介质，在各实施例运行过程中生成的数据可以保存于区块链上。例如：使用第一应用的用户，通过目标应用添加的跨应用联系人之后，将这些跨应用联系人的相关数据保存在区块链中，可以防止这些数据被篡改，保证这些数据的存储可靠性，进而保证跨应用联系人数据处理过程的可靠性。

在一个实施例中，如图2所示，提供了一种联系人的处理方法，以该方法应用于图1中的第一终端为例进行说明，可以理解的是，该方法也可以应用于服务器，还可以应用于包括终端和服务器的系统，并通过终端和服务器的交互实现。

步骤202，显示第一应用中的目标应用交互界面，第一应用通过第一用户标识登录。

在一个实施例中，第一终端可以以属于第一应用的第一用户标识登录第一应用后，进入运行于第一应用中的目标应用，显示第一应用中的目标应用交互界面。

其中，用户可以是在网络中进行网络操作的主体，可以是应用程序中注册的网络账户。用户标识可以是对用户进行区分标识的信息，可以通过网络账号、网名等至少一项来表示。例如，第一用户标识可以是需要与客户保持联系、向客户销售商品或服务的销售人员对应的用户标识，第一用户标识还可以是需要与学生家长保持联系、向学生布置学习任务或传达学校通知的老师对应的用户标识。

应用可以为能够实现特定功能的应用程序。第一应用以及下文提及的第二应用是直接运行于操作系统的原生应用程序，第一应用以及第二应用是能够进行会话的会话应用程序，比如可以是社交应用、邮件应用、支付应用或者游戏应用等。社交应用，包括即时通信应用、SNS(Social Network Service，社交网站)应用或者直播应用等。进一步地，第一应用可以为属于集体中的用户与他人通信所使用的即时通信应用，该即时通讯应用程序可以是以集体为单位进行注册，并为集体内的各个成员提供相应的用户标识。其中，第一用户标识为第一应用中注册的用户标识，是属于第一应用的用户标识，具体可以为某一注册集体内的成员对应的用户标识。更进一步地，第一应用安装在第一终端上，且第一应用中登录有第一用户标识，此时，第一应用展示第一应用的交互界面。

目标应用是为实现目标功能而开发的特定应用，是可在原生应用程序提供的环境中运行的应用程序，目标应用可以是文件管理应用、邮件应用、客户信息管理应用、审批应用或者游戏应用。在一个实施例中，目标应用可以是运行于第一应用中的用于承载信息的网页，例如，目标应用可以是用于对客户资料进行管理的网页，还可以是用于对学生资料进行管理的网页。在另一个实施例中，目标应用还可以是运行于第一应用中的子应用(也可以称之为小程序)。

目标应用可以是注册了第一应用的集体自行开发的应用，例如，销售企业可以在注册了第一应用后，为方便对客户信息的管理，避免客户流失，可以开发用于对客户资料进行管理的应用，作为目标应用。目标应用还可以是第三方服务商为注册了第一应用的集体开发的应用，第三方服务商可以为多个不同的集体开发同一款用于对客户资料进行管理的应用，也可以为多个不同的集体按需开发不同的应用，例如，当集体为某个企业时，可以开发需要保持与客户联系的应用，当集体为学校时，可以开发需要与学生保持联系、派发学习任务的应用。

具体地，第一应用上运行了目标应用，可以在第一应用中进入目标应用的交互界面。例如，第一应用中包括进入目标应用的入口，通过该入口可以进入运行在第一应用中的至少一个目标应用。

步骤204，响应于在目标应用交互界面中触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面。

跨应用联系人添加界面，是用于添加不属于第一应用的注册用户为联系人的交互界面，也称之为外部联系人添加界面，为添加外部联系人的入口。本申请实施例中，第一应用与第二应用支持相互跨应用添加联系人，属于第一应用的注册用户可以在第一应用的跨应用联系人添加界面中，添加属于第二应用的注册用户为联系人，当然，属于第二应用的注册用户也可以在第二应用中，添加属于第一应用的注册用户为联系人。联系人添加操作，可以是在目标应用中触发的点击操作、移动操作、滑动操作或按压操作，等等。

在一个实施例中，第一终端在第一应用的目标应用交互界面中，展示联系人添加控件，用于添加跨应用联系人(外部联系人)，第一终端可以响应于在目标应用交互界面中触发的对该联系人添加控件的触发操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面。可选地，第一终端也可以响应于在目标应用中触发的对该联系人添加控件的触发操作，拉取与第一用户标识关联的第二应用联系人列表，当触发对第二应用联系人列表中联系人的选取操作时，直接将选取的属于第二应用的第二用户标识确定为待添加的联系人，再跳转至第一应用的跨应用联系人添加界面，在该跨应用联系人添加界面中向该待添加的联系人发送联系人交互通知。

在一个实施例中，第一终端在目标应用交互界面中，显示有联系人的联系方式，该联系方式可用于添加对应的联系人为跨应用联系人，第一终端可以响应于在目标应用中触发的对该联系方式的触发操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面。例如，目标应用为审批应用或客户资源管理应用，该目标应用中支持查看客户的基本资料，该基本资料包括客户的联系号码，用户点击该联系号码后，便可以携带该联系号码从目标应用自动跳转到第一应用的跨应用联系人添加界面。

如图3所示，为一个实施例中第一应用中的跨应用联系人添加界面的示意图。参照图3，在第一应用的消息界面300中设置了跨应用联系人添加控件302，当获取到对该跨应用联系人添加控件302的触发操作时，进入到第一应用的跨应用联系人添加界面320，在该跨应用联系人添加界面320中，使用第一应用的第一用户可以通过搜索手机号码，添加使用第二应用的第二用户为跨应用联系人。如图4所示，跨应用联系人添加界面320还可以包括第二应用联系人添加控件322，扫一扫图形码添加控件324和名片分享控件326。第二应用联系人添加控件，可以在使用第一应用的当前用户同时注册了第二应用时，从当前用户的属于第二应用的联系人中，直接添加使用第二应用的第二用户为跨应用联系人。扫一扫图形码添加控件，用户可以通过采集第二应用生成的图形码，添加使用第二应用的第二用户为跨应用联系人。名片分享控件，可以在使用第一应用的当前用户同时注册了第二应用时，将第一应用生成的当前用户的名片信息发送给第二应用中的联系人，以让第二应用中的联系人根据该名片信息主动添加属于第一应用的当前用户为跨应用联系人。

在一个实施例中，运行与第一应用中的目标应用可以通过调用第一应用的跨应用联系人添加界面的接口，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面。进一步地，在目标应用调用该接口之前，目标应用在页面中注入鉴权配置信息，第一应用对应的第一应用服务器需要对在目标应用的页面中注入的鉴权配置信息进行验证，以对当前登录第一应用的集体与需要使用第一应用的接口的目标应用各自对应的身份与权限进行验证，验证通过后目标应用才能获得调用第一应用的接口的权限，从而实现从目标应用跳转至跨应用联系人添加界面。关于目标应用在页面中注入鉴权配置信息的实施例，将在下文进行详细介绍。

步骤206，在跨应用联系人添加界面中确定待添加的联系人后，向与联系人对应的第二用户标识发送联系人交互通知，第二用户标识是属于第二应用的用户标识，第一应用与第二应用为不同的应用程序。

其中，联系人交互通知可以是联系人邀请通知，用于邀请待添加的联系人为联系人或好友。联系人交互通知还可以是联系人会话通知，用于邀请待添加的联系人为临时会话好友，建立与待添加的联系人之间的临时会话。本申请实施例将主要以联系人交互通知为联系人邀请通知为例来详细说明，提供的这些实施例也适用于联系人会话通知。

具体地，第一终端从目标应用交互界面跳转至第一应用的跨应用联系人添加界面后，在该跨应用联系人添加界面中确定待添加的联系人，第一应用具备添加跨应用联系人的能力，第一终端可以通过第一应用向以确定的待添加的联系人对应的第二用户标识登录的第二应用发送联系人邀请通知。

其中，第二应用为独立的用户与他人通信所使用的即时通信应用，第二用户标识为第二应用中注册的用户标识，是属于第二应用的用户标识，具体可以为某个客户或学生对应的用户标识。更进一步地，第二应用安装在第二终端上，且第二应用中登录有第二用户标识。可选地，第一终端上也可以安装并运行了第二应用，且第二应用中登录有第二用户标识。第一应用与第二应用是不同的应用程序。

在一个实施例中，第二终端通过第二应用显示该邀请通知，当该第二用户标识对应的第二用户通过该邀请通知发出同意添加第一用户标识对应的第一用户为外部联系人的答复时，则第一用户与第二用户可以互相成为跨应用联系人。

例如，第一终端可以通过第一应用向第一应用服务器发起携带待添加的联系人的第二用户标识的交互请求，第一应用服务器接收到该交互请求后，检查到第二用户标识为属于第二应用的用户标识，则将该联系人标记为外部联系人，向第二应用服务器发起携带第二用户标识的跨应用联系人邀请请求。当该联系人通过第二应用发出接收邀请的回复后，第一应用服务器可从第二应用服务器获取为该分联系人分配的与第二用户标识对应的身份标识，并生成该联系人属于第一应用的第一用户标识，第一应用就可以将该联系人的第一用户标识显示在第一应用中。相应地，第二应用服务器可以从第一应用服务器获取为该联系人分配的身份标识，并生成该联系人对应的属于第二应用的第二用户标识，第二应用就可以将该联系人的第二用户标识显示在第二应用中。

比如，用户A为集体用户，用户B为个人用户，用户A可以在第一应用中触发添加用户B为跨应用联系人邀请请求，则第一应用服务器接收到该请求后，检查到请求要添加的联系人是个人用户，则第一应用服务器将该对象标记为外部联系人，并向第二应用服务器发起添加用户B为联系人的请求。第二应用服务器在接收到B同意的应答后，就会为用户B分配相应的第二应用身份标识(wx_openid)，将该第二应用身份标识发送至第一应用服务器，第一应用服务器就可以生成与该第二应用身份标识对应的用于指代用户B的标识(B@第二应用简称)，并将该标识显示在第一应用中，用于指代用户B。第二应用服务器可以根据第二应用身份标识查询到与之对应的用户B。

相应地，第二应用服务器可以从第二应用服务器获取为用户A分配的第二应用身份标识(wxwork_openid)，并生成与该第二应用身份标识对应的用于指代用户A的标识(A@集体标识)，并将该标识显示在第二应用中，用于指代用户A。由于第一应用为属于集体中的用户与他人通信所使用的客户端，则上述的集体标识可以是用户A所在的企业的简称。

添加联系人的相关技术中，不能提供跨应用的账号互通能力，需要用户邀请对方注册同一个应用才可以添加联系人，而本申请提供的联系人的处理方法，为使用第一应用的属于某个集体的第一用户提供与使用第二应用的第二用户建立联系人的能力，第二用户不需要另外注册第一应用就可以使用本身已经在使用的第二应用与第一用户建立跨应用联系人的关系，并且，使用第一应用的属于某个集体的第一用户，在通过目标应用处理集体业务时，可以直接从该目标应用交互界面跳转至第一应用的跨应用联系人添加界面，提供添加联系人的快捷入口，直接唤起跨应用联系人添加界面的接口，让第一用户可以方便的添加好友，在该界面中使用第一应用具备的跨应用联系人添加能力，去添加使用第二应用的第二用户标识为联系。

例如，当第一用户为老师，使用第一应用的老师可通过目标应用为学生派发学习任务，当老师需要在目标应用中直接添加学生属于第二应用的第二用户标识为联系人时，可以直接从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，然后在该跨应用联系人添加界面中添加使用第二应用的学生为跨应用联系人。

又例如，当第一用户为企业中的客户管理人员，该客户管理人员可通过目标应用为对客户信息进行管理，当该客户管理人员需要在目标应用交互界面中直接添加客户属于第二应用的第二用户标识为联系人时，可以直接从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，然后在该跨应用联系人添加界面中添加使用第二应用的客户为跨应用联系人。

上述联系人的处理方法，目标应用运行在作为原生应用的第一应用中，当以属于第一应用的第一用户标识登录了第一应用，并进入了第一应用中的目标应用交互界面之后，用户可以直接在该目标应用交互界面中触发联系人添加操作，目标应用就可以响应于该联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，当第一应用在跨应用联系人添加界面中确定待添加的联系人后，第一应用就能够向以该联系人对应的属于第二应用的第二用户标识发送联系人交互通知，触发跨应用添加属于第二应用的第二用户标识为联系人。这样，不需要双方都使用并注册目标应用，也可以通过目标应用建立第一用户标识与第二用户标识之间跨应用的联系人关系，也不需要双方都使用相同的第二应用才能建立联系人关系，从而提高了添加联系人的有效性。

由于目标应用跳转到第一应用的跨应用联系人添加界面，需要调用第一应用服务器提供的客户端接口，为了使第一应用了解当前具体是哪个企业正在申请接口调用权限，第一用户标识登录的目标集体是否具备调用接口的权限，需要在目标应用的页面中注入集体权限验证配置信息，以确认当前第一用户标识所关联的集体的身份与权限，只有在验证了集体的身份与权限后，目标应用才能调用第一应用服务器提供的客户端的预定义接口。

在一个实施例中，第一用户标识与目标集体关联，在显示第一应用中的目标应用交互界面之后，还包括在目标应用的页面中注入集体权限验证配置信息的步骤：通过目标应用对应的目标应用服务器，获取在第一应用服务器的接口调用凭证，根据接口调用凭证从第一应用服务器获取第一接口调用临时票据，第一接口调用临时票据用于目标应用调用第一应用服务器提供的预定义接口；根据第一接口调用临时票据生成用于对目标集体进行鉴权的集体权限验证配置信息后，在目标应用的页面中注入集体权限验证配置信息。

其中，第一应用是属于集体的用户使用的应用程序，一个用户可以以属于不同的集体的身份登录第一应用，在以第一用户标识登录第一应用时，需要选取当前登录的集体，即目标集体。目标应用服务器是为目标应用提供服务的服务器，当目标应用为集体自行开发的应用时，目标应用服务器可以理解为集体使用的服务器。目标应用服务器在第一应用服务器的接口调用凭证(access_token)，是用于目标应用服务器从第一应用服务器调用接口从而获取数据或权限的凭证。例如，当目标应用服务器需要获取当前登录的第一用户标识对应的用户信息并返回至目标应用进行展示时，需要先从第一应用服务器获取接口调用凭证，才能调用第一应用服务器的用户信息调用接口去获取用户信息。目标应用服务器在第一应用服务器的接口调用凭证，在第一用户以第一用户标识登录第一应用成功后由第一应用服务器下发至目标应用服务器，具有短暂的有效期(比如2小时)，过期后需要从第一应用服务器获取新的接口调用凭证，接口调用凭证是与当前登录的目标集体标识(corpid)关联的。

目标应用服务器获取到在第一应用服务器的接口调用凭证后，可以根据该接口调用凭证从第一应用服务器换取第一接口调用临时票据(集体的jsapi_ticket)，并将该第一接口调用临时票据发送至目标应用，目标应用可以通过该第一接口调用临时票据调用第一应用服务器提供的预定义接口，如跨应用联系人界面的调用接口。由于第一接口调用凭证需要通过目标应用服务器在第一应用服务器的接口调用凭证access_token换取，而在第一应用服务器的接口调用凭证是根据目标集体标识生成的，故而生成的该第一接口调用临时票据可以用于对目标集体的身份与权限进行验证。

可选地，第一接口调用临时票据以及下文的第二接口调用临时票据可以存在有效期，例如有效期为7200秒，通过接口调用凭证access_token来获取，并且一个集体在预设时间范围内获取接口调用临时票据的接口的调用次数是有限制的，例如一小时内，一个集体最多可获取400次，且该集体使用的单个目标应用不能超过100次，那么可以将该接口调用临时票据缓存在目标应用服务器上，以避免多次调用获取接口调用临时票据的接口。

目标应用服务器在获得第一接口调用临时票据后，可以根据第一接口调用临时票据生成用于对目标集体进行鉴权的集体权限验证配置信息，并将该集体权限验证配置信息返回至目标应用，目标应用可以在目标应用的页面中注入集体权限验证配置信息。例如，目标应用可以通过调用wx.config接口注入该集体权限验证配置信息，注入该集体权限验证配置信息的页面可以是需要调用第一应用服务器提供的客户端的预定义接口的页面，例如需要跳转至跨应用联系人添加界面的页面。可选地，同一个页面仅需调用wx.config接口一次，对于页面地址经常变换的页面，则需要在每次变化时进行调用。

在一个实施例中，通过目标应用对应的目标应用服务器，获取在第一应用服务器的接口调用凭证，包括：通过目标应用服务器，根据目标集体标识与目标应用的凭证秘钥，从第一应用服务器获取接口调用凭证；或者，通过目标应用服务器，根据目标集体标识与目标集体的授权码，从第一应用服务器获取接口调用凭证。

其中，目标集体标识(corpid)是第一用户标识所登录的目标集体对应的集体标识，每个集体都对应了唯一的集体标识。目标应用的凭证秘钥(secret)是运行在第一应用中的每个目标应用都拥有的独立的访问秘钥，可用于保证数据安全，是由第一应用服务器为目标应用分配的。

在一个实施例中当目标应用为集体自行开发时，也就是目标应用服务器为集体自行使用的服务器时，目标应用服务器可以根据目标集体标识与目标应用的凭证秘钥，从第一应用服务器获取接口调用凭证。

在一个实施例中，当目标应用为第三方开发时，也就是目标应用服务器为第三方使用的服务器时，目标集体授权了第三方为其开发目标应用，此种情况下，目标应用服务器可以根据授权的目标集体标识(auth_corpid)与目标集体提供的授权码(permanent_code)，从第一应用服务器获取接口调用凭证。

在一个实施例中，根据第一接口调用临时票据生成用于对目标集体进行鉴权的集体权限验证配置信息，包括：获取时间戳、随机字符串和触发联系人添加操作的页面地址；根据随机字符串、时间戳、页面地址以及第一接口调用临时票据，生成第一签名信息；根据目标集体的集体标识、时间戳、随机字符串以及第一签名信息生成用于对目标集体进行鉴权的集体权限验证配置信息。

其中，触发联系人添加操作的页面地址，是目标应用中触发跨应用联系人添加操作的页面对应的页面地址。可选地，对于目标应用中需要触发跨应用联系人添加操作的页面，目标应用均可以在相应的页面中注入对目标集体进行鉴权的权限验证配置信息。

集体权限验证配置信息可以通过目标应用服务器发送至目标应用。可选地，目标应用服务器可以获取用于生成签名的时间戳(timestamp)、随机字符串(nonceStr)，将获取的时间戳、随机字符串、需要触发跨应用联系人添加操作的页面对应的页面地址(url)和上述第一接口调用临时票据，使用键值对的格式(即key1＝value1&key2＝value2…)拼接成字符串，然后对该拼接成的字符串进行数据加密后获得第一签名信息。例如可以采用安全哈希加密算法对该拼接成的字符串进行加密，获得第一签名信息(signature)。目标应用服务器可以根据目标集体的集体标识(corpid)、时间戳(timestamp)、随机字符串(nonceStr)，以及第一签名信息(signature)获得用于对目标集体进行鉴权的集体权限验证配置信息。进一步地，第一终端可通过目标应用在需要触发跨应用联系人添加操作的页面中，注入上述集体权限验证配置信息，并在进入到该目标应用的上述触发跨应用联系人添加操作的页面时，第一应用服务器可以根据注入的集体权限验证配置信息对当前目标集体的身份与权限进行验证。

如图5所示，为一个实施例中生成集体权限验证配置信息的时序图，参照图5，首先，目标应用服务器根据目标集体标识corpid与目标应用的凭证秘钥secret，从第一应用服务器获取接口调用凭证access_token，或者，根据目标集体标识(auth_corpid)与目标集体的授权码(permanent_code)，从第一应用服务器获取接口调用凭证access_token。接着，目标应用服务器可以根据该接口调用凭证，调用第一应用服务器中用于获取接口调用临时票据的接口，获得第一接口调用临时票据(目标集体的jsapi_ticket)。接着，目标应用服务器获取用于生成签名的时间戳(timestamp)、随机字符串(nonceStr)，以及触发联系人添加操作的页面地址(url)，根据随机字符串、时间戳、页面地址以及第一接口调用临时票据，生成第一签名信息(signature)，目标应用服务器将时间戳(timestamp)、随机字符串(nonceStr)，以及第一签名信息(signature)发送至目标应用后，目标应用将目标集体标识(corpid)、时间戳(timestamp)、随机字符串(nonceStr)，以及第一签名信息(signature)作为集体权限验证配置信息注入到目标应用中需要触发跨应用联系人添加操作的页面中。

进一步地，由于目标应用跳转到第一应用的跨应用联系人添加界面，需要调用第一应用服务器提供的客户端接口，为了使第一应用了解当前具体是哪个目标应用正在申请接口调用权限，还可以进一步在目标应用的页面中注入应用权限验证配置信息，以确认从第一应用中进入的目标应用的身份与权限，只有在同时验证了集体与应用的身份与权限后，目标应用才能调用第一应用服务器提供的客户端的预定义接口。

例如，当目标应用为第三方为集体开发的应用、目标应用服务器为第三方使用的服务器时，第三方可以为集体开发多个目标应用，显然，仅通过集体权限验证配置信息无法准确区分出调用接口的是哪个目标应用，在一些场景下又必须严谨区分出目标应用的身份，此时即需要通过应用权限验证配置信息来区分目标应用的身份与权限。当目标应用为目标集体自行开发的应用时，若目标集体开发了多个应用用于在第一应用中运行，那么也需要准确区分出调用接口的是该目标集体开发的哪个目标应用。

在一个实施例中，在目标集体通过鉴权之后，方法还包括：通过目标应用服务器，根据在第一应用服务器的接口调用凭证，从第一应用服务器获取第二接口调用临时票据；根据第二接口调用临时票据生成用于对目标应用进行鉴权的应用权限验证配置信息，通过目标应用在目标应用的页面中注入应用权限验证配置信息。

可选地，目标应用服务器可以根据目标集体标识与目标应用的凭证秘钥，从第一应用服务器获取接口调用凭证。

具体地，目标应用服务器获取到在第一应用服务器的接口调用凭证，并且对目标集体的权限与身份验证通过后，可以根据该接口调用凭证从第一应用服务器换取第二接口调用临时票据(应用的jsapi_ticket)，目标应用服务器可以根据该第二接口调用临时票据生成签名。由于第二接口调用凭证需要通过目标应用服务器在第一应用服务器的接口调用凭证access_token换取，而在第一应用服务器的接口调用凭证是根据目标集体标识以及该目标应用(agentid)对应的凭证秘钥(secret)生成的，故而生成的该第二接口调用临时票据可以用于对目标应用的身份与权限进行验证。

目标应用服务器在获得第二接口调用临时票据后，可以根据第二接口调用临时票据生成用于对目标应用进行鉴权的应用权限验证配置信息，并将该应用权限验证配置信息返回至目标应用，目标应用可以在目标应用的页面中注入应用权限验证配置信息。例如，在wx.config配置成功的回调中监听到对目标集体的身份与权限校验成功后，再调用wx.agentConfig，通过调用wx.agentConfig接口注入该应用权限验证配置信息，注入该应用权限验证配置信息的页面可以是需要调用第一应用服务器提供的客户端的预定义接口的页面，例如需要跳转至跨应用联系人添加界面的页面。可选地，同一个页面仅需调用wx.agentConfig接口一次，对于页面地址经常变换的页面，则需要在每次变化时进行调用。

在一个实施例中，根据第二接口调用临时票据生成用于对目标应用进行鉴权的应用权限验证配置信息，包括：获取对目标集体进行鉴权时所使用的时间戳和随机字符串；确定触发联系人添加操作的页面地址；根据随机字符串、时间戳、页面地址以及第二接口调用临时票据，生成第二签名信息；根据目标集体的集体标识、目标应用的应用标识、时间戳、随机字符串以及第二签名信息生成用于对目标应用进行鉴权的应用权限验证配置信息。

需要说明的是，为保证先对目标集体的身份与权限验证通过之后，再对目标应用的身份与权限进行验证，此处生成对目标应用的签名所使用的时间戳和随机字符串，与对目标集体进行鉴权时所使用的时间戳和随机字符串相同。

可选地，目标应用服务器可以获取该时间戳(timestamp)、随机字符串(nonceStr)，将获取的时间戳、随机字符串、需要触发跨应用联系人添加操作的页面对应的页面地址(url)和上述第二接口调用临时票据，使用键值对的格式(即key1＝value1&key2＝value2…)拼接成字符串，然后对该拼接成的字符串进行数据加密后获得第二签名信息。例如可以采用安全哈希加密算法对该拼接成的字符串进行加密，获得第二签名信息(signature)。目标应用服务器可以根据目标集体的集体标识(corpid)、该时间戳(timestamp)、随机字符串(nonceStr)，以及该第二签名信息(signature)获得用于对目标应用进行鉴权的集体权限验证配置信息。进一步地，第一终端可通过目标应用在需要触发跨应用联系人添加操作的页面中，注入上述应用权限验证配置信息，并在进入到该目标应用的上述触发跨应用联系人添加操作的页面时，第一应用服务器可以根据注入的集体权限验证配置信息对当前目标集体的身份与权限进行验证之后，利用该应用权限验证配置信息对当前目标应用的身份与权限进行验证。

如图6所示，为一个实施例中生成应用权限验证配置信息的时序图，参照图5，首先，目标应用服务器根据目标集体标识corpid与目标应用的凭证秘钥secret，从第一应用服务器获取接口调用凭证access_token。接着，目标应用服务器可以根据该接口调用凭证，调用第一应用服务器中用于获取接口调用临时票据的接口，获得第二接口调用临时票据(应用的jsapi_ticket)。接着，目标应用服务器获取对目标集体鉴权时使用的时间戳(timestamp)、随机字符串(nonceStr)，以及触发联系人添加操作的页面地址(url)，根据随机字符串、时间戳、页面地址以及第二接口调用临时票据，生成第二签名信息(signature)。目标应用服务器将时间戳(timestamp)、随机字符串(nonceStr)，以及第二签名信息(signature)发送至目标应用后，目标应用将目标集体标识(corpid)、时间戳(timestamp)、随机字符串(nonceStr)，以及第二签名信息(signature)作为应用权限验证配置信息注入到目标应用中需要触发跨应用联系人添加操作的页面中。

至此，通过上述的集体权限验证配置信息与应用权限验证配置信息，实现对当前第一用户标识登录的目标集体的身份与在第一应用中进入的目标应用的身份与权限进行验证，在验证通过后，目标应用获得了调用第一应用服务器提供的客户端的预定义接口的权限，目标应用就可以调用第一应用服务器提供的客户端的调用接口，例如第一应用的拍照、选图、语音、位置等功能的接口，又例如直接发起调用跨应用联系人添加界面的请求，以实现直接从目标应用交互界面跳转至第一应用的跨应用联系人添加界面。

在一个实施例中，响应于在目标应用中触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，包括：在目标应用通过鉴权之后，响应于在目标应用中触发的联系人添加操作，向第一应用发起跨应用添加联系人界面的跳转请求，跳转请求携带了跨应用联系人添加界面的接口名；通过第一应用在监听到跳转请求时，识别跳转请求所携带的接口名后，从目标应用跳转至接口名对应的跨应用联系人添加界面。

可选地，为了保证在集体权限验证配置信息与应用权限验证配置信息验证通过之后才能调用第一应用服务器提供的客户端的预定义接口，上述两种配置信息通过验证后会执行wx.ready方法。也就是说，目标应用发起的接口调用请求，需要先监听wx.ready事件，wx.ready事件被触发时表示上述两种配置信息通过了验证。监听wx.ready事件触发后，可以在回调中处理第一应用发起跨应用添加联系人界面的跳转请求，第一应用通过识别该跳转请求的接口名以及参数，进行页面的跳转，从目标应用跳转到第一应用中原生的跨应用联系人添加界面。

在一个实施例中，目标应用发起跳转请求通过JSBridge通信机制(实现原生应用和网页应用双向通信的一种机制)与第一应用进行通信。目标应用通过第一应用流入的JSBridge对象的方法发起跳转请求，该跳转请求携带了用于跳转至跨应用联系人界面的方法名、参数和回调等信息，第一应用捕获该请求后分析出方法名、参数、回调函数等信息，并执行该方法名对应的方法，在第一应用执行完该请求的方法后，通过第一应用服务器提供的回调集合，调用目标应用的回调函数，发送回调标识给目标应用的回调函数，目标应用响应回调函数并解析回调结果，如发现成功则为用户进行相应的提示和业务逻辑的处理。

如图7所示，为一个实施例中目标应用发起跳转至第一应用的跨应用联系人添加界面的跳转请求后第一应用进行响应的流程示意图。参照图7，首先，目标应用通过JSBridge调用registerHandler注册本地方法，并将本地注册方法添加到本地注册方法集合中。当需要从目标应用发起接口调用请求时，目标应用通过调用JSBridge调用本地注册方法，将对应方法的回调函数添加至本地回调函数集合中，同时目标应用调用回调函数。当在目标应用的原生页面中触发接口调用请求时，可以通过iframe.src发送URL Scheme请求。第一应用在拦截到该请求时，捕获对应的URL Scheme，对其进行分析，分析出需要执行的方法名、参数和回调标识等信息。第一应用通过调用handleMessageFromNative执行该方法名对应的方法后，通过JSBridge执行目标应用的回调函数，执行回调函数时可以传入前面分析出的回调标识，执行完毕后在本地回调函数集合中删除对应的方法。

当第一应用的原生页面通过JSBridge主动调用目标应用的方法时，则判断是否需要回调函数，若需要则调用本地注册方法，调用后通过URL Scheme将回调信息传递给第一应用页面，第一应用页面捕获到URL Scheme时，判断是否是本地的回调方法，若不需要则判断目标应用是否已经注册了本地方法，若没有则确定调用失败可以进行相应的提示，若已经注册了本地方法则调用本地注册方法集合中的本地方法，此时不需要执行回调函数。

在一个具体的实施例中，当目标应用为第三方为集体开发的H5应用时，从H5网页跳转到第一应用的原生页面，包括以下步骤：

1、第三方需要在第一应用对应的第一应用服务器的管理后台，创建一个应用，如H5网页，用于在第一应用的应用市场中上架后提供集体安装应用和使用，而第三方创建该应用后可以获取到该应用的应用标识(agentid)，用于授权第一应用的接口的初始化授权时使用。

2、集体安装第三方上架的应用后，打开应用后要先调用wx.config进行集体权限校验配置信息的配置，注入的是集体的身份与权限，在第一应用中，所有需要使用第一应用服务器提供的预定义接口的页面都需先注入配置信息。

3、在wx.config配置成功的回调函数中监听集体权限校验配置信息校验成功后，再调用wx.agentConfig，注入应用的身份与权限。agentConfig注册时需要提供当前登录的目标集体标识、目标应用标识、签名信息以及签名所需要的必要字段，还包括需要注册的接口的列表。

4、在wx.config和wx.agentConfig都配置成功后，用于跳转跨应用联系人添加界面的调用接口就会授权成功，第三方的目标应用就可以发起调用该接口的请求。

5、目标应用中发起的请求，需要先监听wx.ready事件，config信息验证后会执行ready方法，所有接口调用都必须在config接口获得结果之后。

6、监听wx.ready事件触发后，可以在回调函数中处理目标应用发起的请求，第一应用在Webview注入的监听方法，会接收目标应用发起的请求，通过识别请求的接口名以及参数，就可以进行跳转到第一应用的原生页面，例如为目标应用跳转到跨应用联系人添加界面。

7、目标应用发起的请求是通过JSBridge通信机制与第一应用进行通信。目标应用通过第一应用流入的JSBridge对象的方法发起一个URL Scheme请求，第一应用捕获请求后分析出方法名、参数、回调等信息，在第一应用执行完该请求的方法后，通过接口调用的回调队列集合，调用请求指定的方法，如跳转到添加外部联系人界面。并发送回调集合给目标应用的回调函数，目标应用响应回调函数并解析回调结果，如发现成功则为用户进行相应的提示和业务逻辑的处理。

在一个实施例中，响应于在目标应用交互界面中触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，包括：在目标应用中显示待添加的联系人标识；响应于在目标应用交互界面中对联系人标识触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面；在跨应用联系人添加界面中确定待添加的联系人，包括：在跨应用联系人添加界面的联系人搜索框中，显示联系人标识；当触发对联系人标识的搜索操作时，将联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人。

本实施例中，待添加的联系人标识可以是从目标应用中传递到第一应用中的。进一步地，在目标应用的交互界面中，显示有联系人的联系方式，该联系方式可用于添加对应的联系人为跨应用联系人，第一终端可以响应于在目标应用交互界面中触发的对该联系方式的触发操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面的同时，将该联系方式复制到第一应用并显示在跨应用联系人添加界面的联系人搜索框中。这样，当在该跨应用联系人添加界面触发对联系人标识的搜索操作时，直接将联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人。也就是说，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，可以直接带入联系人标识，无需要用户手动输入，尤其在目标应用管理的联系人较多的场景中，用户能够快捷地添加联系人。

在一个实施例中，在目标应用交互界面中，还可以显示联系人在第一应用的图形码，第一终端可以响应于在目标应用交互界面中触发的对该图形码的触发操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面的同时，确定该图形码对应的属于第一应用的用户标识后，确定与该属于第一应用的用户标识关联的属于第二应用的用户标识，将该属于第二应用的用户标识复制到第一应用的跨应用联系人添加界面中进行搜索与添加，例如可以将该属于第二应用的用户标识显示在跨应用联系人添加界面的联系人搜索框中。当然，在目标应用交互界面中，还可以显示联系人在第二应用的图形码，第一终端可以响应于在目标应用交互界面中触发的对该图形码的触发操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面的同时，将该属于第二应用的用户标识复制到第一应用的跨应用联系人添加界面中进行搜索与添加。

在一个实施例中，目标应用服务器还可以根据当前登录第一应用的第一用户标识所对应的用户画像数据，确定与该第一用户标识存在相关性的相关联系人，亦即是当前用户意图进行跨应用添加的联系人，目标应用服务器将该相关联系人推送至目标应用，目标应用将该相关联系人的联系方式展示在目标应用交互界面中，这样，第一终端可以响应于在该目标应用交互界面中对展示的相关联系人的触发操作，将该相关联系人的联系方式复制到第一应用的跨应用联系人添加界面中进行搜索与添加。

在一个实施例中，在跨应用联系人添加界面中确定待添加的联系人，包括：在跨应用联系人添加界面中，显示联系人搜索框；获取在联系人搜索框中输入的联系人标识；当触发对联系人标识的搜索操作时，将与联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人。

本实施例中，跨应用联系人添加界面中包括联系人搜索框，在从目标应用交互界面跳转至第一应用的跨应用联系人添加界面之后，第一用户可以在该联系人搜索框中输入联系人标识，例如手机号码、邮箱地址等等，当触发对输入的该联系人标识的搜索操作时，将与联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人。

参照图8，在第一应用中进入到目标应用的交互界面800，参照图8的(a)部分，该交互界面800中可设置联系人添加控件802，当获取到对该联系人添加控件802的触发操作时，进入到第一应用的跨应用联系人添加界面804。可选地，参照图8的(b)部分，该交互页面800中显示客户的基本资料，基本资料包括客户的电话号码，当获取到对该电话号码的触发操作时，弹出联系人添加控件806，当获取到对该联系人添加控件806的触发操作时，进入到第一应用的跨应用联系人添加界面804。可选地，进入到第一应用的跨应用联系人添加界面804时，可将该电话号码直接显示在跨应用联系人添加界面804中的搜索框808中，当前登录第一应用的第一用户可以通过搜索该手机号码，添加使用第二应用的第二用户为跨应用联系人。

在一个实施例中，在跨应用联系人添加界面中确定待添加的联系人，包括：在跨应用联系人添加界面中，显示第二应用联系人添加图标；响应于对第二应用联系人添加图标的触发操作，显示与第一用户标识关联的第二应用联系人列表；当触发对第二应用联系人列表中联系人的选取操作时，将选取的属于第二应用的第二用户标识确定为待添加的联系人。

本实施例中，第一应用还支持从第二应用的联系人中添加跨应用联系人。在用户注册了属于第一应用的第一用户标识，也注册了属于第二应用的第二用户标识时，第一应用可以显示与第一用户标识关联的第二应用联系人列表，根据用户从该第二应用联系人列表中的选取操作，确定待添加的跨应用联系人。

如图9所示，为一个实施例中从第一用户标识对应的属于第二应用的联系人中确定待添加的联系人的界面示意图。参照图9，在跨应用联系人添加界面900中，显示第二应用联系人添加图标902，当用户点击该第二应用联系人添加图标902时，可在第一应用中显示当前登录的第一用户标识关联的第二应用联系人列表904，当用户选取该列表中的任意一个属于第二应用的联系人，就可以确定为待添加的联系人。

在一个实施例中，响应于对第二应用联系人添加图标的触发操作，显示与第一用户标识关联的第二应用联系人列表，包括：通过第一应用，响应于对第二应用联系人添加图标的触发操作，根据第一用户标识向第一应用服务器发起第二应用联系人请求后，接收第一应用服务器响应于第二应用联系人请求，根据第一应用服务器在第二应用服务器的接口调用凭证，从第二应用服务器拉取并返回的与第一用户标识关联的第二应用联系人；通过第一应用根据第二应用联系人显示第二应用联系人列表。

由于第一用户标识是属于第一应用的用户标识，第二应用联系人是属于第二应用的用户标识，第一应用需要通过第一应用服务器从第二应用服务器拉取与当前登录的第一用户标识关联的属于第二应用的联系人。前文提到，目标应用服务器调用第一应用服务器提供的接口时，需要使用目标应用服务器在第一应用服务器的接口调用凭证，类似地，第一应用服务器需要从第二应用服务器获取当前登录的第一用户标识关联的联系人列表时，也需要使用第一应用服务器在第二应用服务器的接口调用凭证。接口调用凭证是第二应用服务器为第一应用服务器下发的身份凭证。

具体地，当用户通过第一应用的跨应用联系人添加界面中的第二应用联系人添加图标，触发第二应用联系人请求后，第一应用服务器根据在第二应用服务器的接口调用凭证以及第一用户标识，调用第二应用服务器的联系人获取接口，获取到第一用户标识关联的属于第二应用的联系人列表。更进一步地，第一服务器确定第一用户标识对应的身份标识，将在第二应用服务器的接口调用凭证与该身份标识发送至第二应用服务器，第二应用服务器确定与该身份标识对应的属于第二应用的注册用户标识后，获取与该注册用户标识对应的属于第二应用的联系人，并返回至第一应用服务器，第一应用服务器将对应的属于第二应用的联系人发送至第一应用，第一应用显示联系人列表。

在一个实施例中，在跨应用联系人添加界面中确定待添加的联系人，包括：在跨应用联系人添加界面中，显示扫码添加联系人图标；响应于对扫码添加联系人图标的触发操作，显示扫码界面；在扫码界面中采集并解析属于第二应用的图形码，获得属于第二应用的第二用户标识，作为待添加的联系人。

本实施例中，第一应用还支持采集属于第二应用的图形码后添加跨应用联系人。属于第二应用的图形码可以是第二应用二维码。属于第二应用的图形码中携带了属于第二应用的第二用户标识。第一应用可以通过解析扫描的属于第二应用的图形码，获得属于第二应用的第二用户标识。

在一个实施例中，上述方法还包括：在跨应用联系人添加界面中，显示第一应用名片分享图标；响应于对第一应用名片分享图标的触发操作，从第一应用跳转至本地的第二应用，将与第一用户标识对应的、且属于第一应用的名片信息传递至本地的第二应用；获取在本地的第二应用的会话列表中选取的目标会话；通过本地的第二应用将名片信息，发送至以目标会话的会话成员对应的第二用户标识登录的第二应用。

本实施例中，第一应用还支持转发属于第一应用的名片信息至第二应用，为第一用户提供更高效的添加跨应用联系人的能力。可选地，在本地同时案子了第一应用与第二应用，且第二应用处于登录状态时，第一应用可以响应于对第一应用名片分享图标的触发操作，在第一应用中拉起第二应用，在拉起的第二应用中显示第二应用中的会话列表，当前用户选取了会话列表中的目标会话后，就可以通过第二应用将属于第一应用的名片信息分享到目标会话的会话成员对应的第二用户标识登录的第二应用。可选地，用户也可以在拉起的第二应用中选取联系人，通过第二应用将属于第一应用的名片信息分享到该联系人对应的第二用户标识登录的第二应用。

其中，第一用户标识对应的、且属于第一应用的名片信息，可以包括该第一用户在第一应用中设置的头像、昵称、所属的目标集体和该第一用户标识中的至少一种。用户从第二应用中选取的目标会话可以是群组会话，也可以是单聊会话。选取的目标会话为群组会话时，则通过第二应用将第一用户标识对应的、且属于第一应用的名片信息发送至该群组会话中的每个会话成员。

如图10所示，为一个实施例中从第一应用分享名片到第二应用的界面示意图。参照图10，在跨应用联系人添加界面1000中，显示第一应用名片分享图标1002，当用户点击该第一应用名片分享图标1002时，可在第一应用中拉起第二应用，显示第二应用的会话列表1004，当用户选取该会话列表中的任意一个会话时，就通过第二应用将属于第一应用的名片发送至参与该会话的属于第二应用的联系人。

在一个实施例中，第二应用在接收到来自第一应用的名片信息后，在会话中显示该名片消息，并响应于第二用户针对该名片消息的触发操作，打开第一用户在第一应用的名片信息，第二用户可以在浏览到该名片信息后，主动添加第一用户为跨应用联系人。此时，第一应用接收第二应用发起的联系人添加操作，在第一用户通过第一应用接收邀请后，建立双向的跨应用联系人关系。

在一个实施例中，在确定待添加的联系人之后，方法还包括：通过第一应用，接收第一应用服务器根据第一应用服务器在第二应用服务器的接口调用凭证，从第二应用服务器拉取并返回的与联系人对应的第二用户标识的用户信息；显示待添加的联系人对应的第二用户标识的用户信息。

本实施例中，当用户通过在跨应用联系人添加界面的联系人搜索框中输入联系人标识，或是第二应用联系人添加图标选取了与第一用户标识关联的第二应用联系人列表中的联系人，或是通过采集属于第二应用的图形码确定待添加的联系人后，第一应用均可以显示待添加的联系人对应的第二用户标识的用户信息。用户信息例如可以是用户昵称、用户头像等等。

在一些实施例中，当确定待添加的联系人也注册了属于第一应用的用户标识，但当前登录的第一用户标识未与其建立联系人关系时，第一应用除了显示与该联系人对应的属于第二应用的用户标识之外，还可以显示与该联系人对应的属于第一应用的用户标识，用户可以通过第一应用添加属于第二应用的用户标识为跨应用联系人，当然也可以添加属于第一应用的用户标识为同一个应用内的联系人。此外，用户还可以点击属于第二应用的用户标识，查看对应的用户信息，还可以点击属于第一应用的用户标识，查看对应的用户信息。

如图11所示，为一个实施例中从第一应用中搜索联系人后显示用户信息的界面示意图。参照图11的(a)部分，当用户通过在跨应用联系人添加界面的联系人搜索框中输入联系人标识进行搜索后，显示相应的属于第一应用的第一用户标识和属于第二应用的第二用户标识，用户可以查看对应的用户个人信息。参照图11的(b)部分，第一用户通过点击第一应用中的第二应用联系人添加图标，第一应用显示第二应用联系人列表，第一用户选取了与第一用户标识关联的第二应用联系人列表中的联系人后，显示属于第二应用的第二用户标识，用户可以查看对应的用户信息。参照图11的(c)部分，第一应用通过采集属于第二应用的图形码显示对应的属于第二应用的第二用户标识，用户可以查看对应的用户信息。

在一个实施例中，通过第一应用，向以联系人对应的第二用户标识登录的第二应用发送联系人邀请通知，包括：通过第一应用，将待添加的联系人对应的联系人标识发送至第一应用服务器后，通过第一应用服务器从第二应用服务器获取与联系人标识对应的第二用户标识，并根据第二用户标识、第一用户标识与邀请通知模板标识，向第二应用服务器发起联系人添加请求；通过第二应用服务器基于联系人添加请求，根据第一用户标识以及第一用户标识所关联的目标集体的集体标识，生成第一用户标识在第二应用的第一身份标识，在邀请通知模板标识对应的邀请通知模板中填充第一身份标识得到联系人邀请通知，并将联系人邀请通知发送至以第二用户标识登录的第二应用。

在本实施例中，第一应用发起的跨应用联系人添加请求，是通过联系人邀请通知的形式传递到第二应用的。在一个实施例中，第二应用服务器预先生成了一些通知模板与模板标识之间的对应关系，并将该目标标识以及对应的通知模板存储在第二应用服务器中。例如，通知模板包括联系人邀请通知模板、支付通知模板、快递提醒通知模板，等等。

具体地，第一应用将待添加的联系人标识发送至第一应用服务器，第一应用服务器根据在第二应用服务器的接口调用凭证，从第二应用服务器获取与该联系人标识对应的第二用户标识，再根据第二用户标识、第一用户标识与邀请通知模板标识，向第二应用服务器发起联系人添加请求，第二应用服务器响应于该请求，根据第一用户标识以及第一用户标识所关联的目标集体的集体标识，生成第一用户标识在第二应用的第一身份标识，如“xx@目标集体”。第二应用服务器获取与第一应用服务器发送的邀请通知模板标识对应的联系人邀请通知模板，并在该联系人邀请通知模板中填充发起邀请的用户的第一身份标识，得到联系人邀请通知，将联系人邀请通知发送至以第二用户标识登录的第二应用。

如图12所示，为一个实施例中第二应用接收到的联系人邀请通知的界面示意图。参照图12，该联系人邀请通知中显示了“XX公司的YY正在邀请您添加他为好友，加入与他的聊天”，其中“XX公司”是第一用户所在的集体标识，“YY”指代的是第一用户对应的第一用户标识。第二应用接收该联系人邀请通知后，使用第二应用的第二用户就可以通过该联系人邀请通知，对第一用户发起的邀请作出应答。

可选地，为避免使用第一应用的第一用户直接添加使用第二应用的第二用户给第二用户带来不便的问题，由第一用户通过第一应用发起的跨应用联系人邀请，是单向的邀请，在第二用户通过接收的联系人邀请通知进行答复后，才能建立双向的跨应用联系人关系。

在一个实施例中，上述方法还包括：进入以待添加的联系人对应的第二用户标识登录的第二应用；在第二应用中，显示来自目标集体的第一用户标识的联系人邀请通知；响应于对联系人邀请通知中的联系人添加操作，建立属于第二应用的第二用户标识与属于第二应用的第一用户标识之间的联系人关系。

具体地，第二应用显示该联系人邀请通知，并响应第二用户的触发操作，可以进入到该联系人邀请通知的详情页面，以便于第二用户可以在详情页面中了解到发出邀请的第一用户的基本信息。可选地，第二用户可以在详情页面中打开第一用户属于第一应用的名片信息后，再添加第一用户为跨应用联系人。

如图13所示，为一个实施例中通过联系人邀请通知建立跨应用联系人关系的界面示意图。参照图13，通过第二应用显示来自目标集体的第一用户的联系人邀请通知，当进入该联系人邀请通知的邀请详情页面后，可以在该邀请详情页面中触发联系人添加操作，建立与第二用户的跨应用联系人关系。参照图13，邀请详情页面包括第一用户标识在第二应用中的身份标识，即“XX@目标集体”以及第一用户标识对应的、且属于第一应用的图形码，还可以包括第一用户标识在第一应用中设置的头像信息。第二用户可以通过该图形码，打开第一用户在第一应用的名片信息后，再添加第一用户为跨应用联系人。

在一个实施例中，上述方法还包括：在第二应用中，显示第一用户标识在第二应用中的第一身份标识所对应的会话页面；在会话页面中，向以第一用户标识登录的第一应用，发送来自第二用户标识的跨应用会话消息。

如图14所示，为一个实施例中第二应用展示的与第一应用的联系人进行会话的会话页面的示意图。参照图14，该会话页面中，显示了第一应用的第一用户标识在第二应用中的身份标识，如“王小明@XX公司”，用于表示该会话是与跨应用联系人之间的会话。

在一个实施例中，上述方法还包括：在第一应用中，显示第二用户标识在第一应用中的第二身份标识所对应的会话页面；在会话页面中，向以第二用户标识登录的第二应用，发送来自第一用户标识的跨应用会话消息。

如图15所示，为一个实施例中第一应用展示的与第二应用的联系人进行会话的会话页面的示意图。参照图15，该会话页面中，显示了第二应用的第二用户标识在第一应用中的身份标识，如“Ellen@第一应用”，用于表示该会话是与跨应用联系人之间的会话。

本申请还提供一种应用场景，该应用场景应用上述的联系人的处理方法。具体地，该联系人的处理方法在该应用场景的应用如下：

第一应用为企业的员工使用的即时通信应用，第二应用为个人使用的即时通信应用，第一应用提供了外部联系人添加界面，可支持第一应用的用户添加第二应用的注册用户为联系人。目标应用为运行于第一应用中的H5网页，H5网页中可以设置外部联系人添加图标，XX企业的用户A登录了第一应用后进入H5网页的交互界面，H5网页可以是对客户资料进行管理的应用程序，当该H5网页的交互界面中注入了用于对该企业以及该H5网页的身份与权限进行验证的权限验证配置信息，并通过了验证后，H5网页就可以使用第一应用服务器提供的客户端的预定义接口，如跳转至第一应用的外部联系人添加界面的的接口。

在一些场景中，当用户A在H5网页中操作时，想要使用第一应用的外部联系人添加界面的功能时，就可以直接从H5网页跳转至该外部联系人添加界面。在另一些场景中，当用户A在H5网页中获取到用户B的联系方式，并意图通过该联系方式添加用户B在第二应用的注册账号为外部联系人时，就可以直接从该H5网页中跳转至该外部联系人添加界面，根据该联系方式添加用户B在第二应用的注册账号为外部联系人，向以该注册账号登录的第二应用发起外部联系人邀请通知。

在一个具体的实施例中，联系人的处理方法包括以下步骤：

1、以属于第一应用的第一用户标识登录第一应用，并与目标企业关联；

2、进入运行于第一应用中的网页；

3、通过该网页对应的网页服务器，根据目标企业标识corpid与网页(agentid)的凭证秘钥(secret)，从第一应用服务器获取接口调用凭证(access_token)，根据接口调用凭证(access_token)从第一应用服务器获取企业的第一接口调用临时票据(企业的jsapi_ticket)，第一接口调用临时票据用于网页调用第一应用服务器提供的预定义接口；

3、获取时间戳(timestamp)、随机字符串(nonceStr)和网页中的用于触发联系人添加操作的页面地址(url)；

4、根据随机字符串、时间戳、页面地址以及第一接口调用临时票据，生成第一签名信息(signature)；

5、根据目标企业的集体标识(corpid)、时间戳(timestamp)、随机字符串(nonceStr)以及第一签名信息(signature)生成集体权限验证配置信息，调用wx.config接口在网页的页面中注入该集体权限验证配置信息以对目标企业的身份与权限进行验证；

6、在目标企业通过验证后，通过网页服务器，根据在第一应用服务器的接口调用凭证，从第一应用服务器获取第二接口调用临时票据(网页的jsapi_ticket)；

7、获取对目标企业进行鉴权时所使用的时间戳和随机字符串；确定触发联系人添加操作的页面地址；根据随机字符串、时间戳、页面地址以及第二接口调用临时票据，生成第二签名信息；

8、根据目标企业标识(corpid)、网页的应用标识(agentid)、时间戳、随机字符串以及第二签名信息生成用于对网页进行鉴权的应用权限验证配置信息；调用wx.agentConfig接口在网页的页面中注入应用权限验证配置信息；

9、在网页通过鉴权之后，响应于在网页中触发的联系人添加操作，向第一应用发起跨应用添加联系人界面的跳转请求，跳转请求携带了跨应用联系人添加界面的接口名；

10、通过第一应用在监听到跳转请求时，识别跳转请求所携带的接口名后，从网页跳转至接口名对应的跨应用联系人添加界面；

11-a、在跨应用联系人添加界面中，显示联系人搜索框；获取在联系人搜索框中输入的联系人标识；当触发对联系人标识的搜索操作时，将与联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人；

11-b、在跨应用联系人添加界面中，显示第二应用联系人添加图标；响应于对第二应用联系人添加图标的触发操作，显示与第一用户标识关联的第二应用联系人列表；当触发对第二应用联系人列表中联系人的选取操作时，将选取的属于第二应用的第二用户标识确定为待添加的联系人；

11-c、在跨应用联系人添加界面中，显示扫码添加联系人图标；响应于对扫码添加联系人图标的触发操作，显示扫码界面；在扫码界面中采集并解析属于第二应用的图形码，获得属于第二应用的第二用户标识，作为待添加的联系人；

12、在跨应用联系人添加界面中确定待添加的联系人后，通过第一应用，接收第一应用服务器根据在第二应用服务器的接口调用凭证，从第二应用服务器拉取并返回的与联系人对应的第二用户标识的用户信息，显示待添加的联系人对应的第二用户标识的用户信息。

13、通过第一应用，将待添加的联系人对应的联系人标识发送至第一应用服务器后，通过第一应用服务器从第二应用服务器获取与联系人标识对应的第二用户标识，并根据第二用户标识、第一用户标识与邀请通知模板标识，向第二应用服务器发起联系人添加请求；

14、通过第二应用服务器基于联系人添加请求，根据第一用户标识以及第一用户标识所关联的目标企业的集体标识，生成第一用户标识在第二应用的第一身份标识，在邀请通知模板标识对应的邀请通知模板中填充第一身份标识得到联系人邀请通知，并将联系人邀请通知发送至以第二用户标识登录的第二应用；

15、进入以待添加的联系人对应的第二用户标识登录的第二应用；

16、在第二应用中，显示来自目标企业的第一用户标识的联系人邀请通知；

17、响应于对联系人邀请通知中的联系人添加操作，建立属于第二应用的第二用户标识与属于第二应用的第一用户标识之间的联系人关系；

18、在第二应用中，显示第一用户标识在第二应用中的第一身份标识所对应的会话页面；

19、在会话页面中，向以第一用户标识登录的第一应用，发送来自第二用户标识的跨应用会话消息；

20、在第一应用中，显示第二用户标识在第一应用中的第二身份标识所对应的会话页面；

21、在会话页面中，向以第二用户标识登录的第二应用，发送来自第一用户标识的跨应用会话消息。

本申请实施例提供的联系人的处理方法，为使用目标应用的用户提供与客户建立互通的能力，客户不需要另外注册目标应用，就可以使用已有的属于第二应用的用户账号，与使用目标应用的用户通过第一应用建立联系。此外，基于第一应用提供的使用手机号添加客户为外部联系人，并匹配该手机号绑定的属于第二应用的账号、属于第一应用的账号，除手机号搜索添加外部联系人之外，也提供了非常丰富的添加联系人的方式，通过添加当前用户在第二应用的好友为外部联系，通过扫一扫属于第二应用的图形码添加外部联系人，还可以转发第一应用的名片信息到第二应用中，为用户提供更为高效的添加外部联系人的能力。企业可以通过第一应用的客户联系管理能力，可以更灵活的维护客户关系，为用户提供更好的客户管理方式，提升客户维护和管理的效率。

应该理解的是，虽然上述流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图16所示，提供了一种联系人的处理装置1600，该装置可以采用软件模块或硬件模块，或者是二者的结合成为计算机设备的一部分，该装置具体包括：第一应用登录模块1602、目标应用交互模块1604、跳转模块1606和添加模块1608，其中：

第一应用登录模块1602，用于以属于第一应用的第一用户标识登录第一应用；

目标应用交互模块1604，用于进入运行于第一应用中的目标应用；

跳转模块1606，用于响应于在目标应用交互界面中触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面；

添加模块1608，用于在跨应用联系人添加界面中确定待添加的联系人后，向以联系人对应的第二用户标识登录的第二应用发送联系人交互通知，第二用户标识是属于第二应用的用户标识。

在一个实施例中，装置还包括集体权限验证模块，用于通过目标应用对应的目标应用服务器，获取在第一应用服务器的接口调用凭证，根据接口调用凭证从第一应用服务器获取第一接口调用临时票据，第一接口调用临时票据用于目标应用调用第一应用服务器提供的预定义接口；根据第一接口调用临时票据生成用于对目标集体进行鉴权的集体权限验证配置信息后，在目标应用的页面中注入集体权限验证配置信息。

在一个实施例中，集体权限验证模块，还用于通过目标应用服务器，根据目标集体标识与目标应用的凭证秘钥，从第一应用服务器获取接口调用凭证；或者，通过目标应用服务器，根据目标集体标识与目标集体的授权码，从第一应用服务器获取接口调用凭证。

在一个实施例中，集体权限验证模块，还用于获取时间戳、随机字符串和触发联系人添加操作的页面地址；根据随机字符串、时间戳、页面地址以及第一接口调用临时票据，生成第一签名信息；根据目标集体的集体标识、时间戳、随机字符串以及第一签名信息生成用于对目标集体进行鉴权的集体权限验证配置信息。

在一个实施例中，装置还包括应用权限验证模块，用于通过目标应用服务器，根据在第一应用服务器的接口调用凭证，从第一应用服务器获取第二接口调用临时票据；根据第二接口调用临时票据生成用于对目标应用进行鉴权的应用权限验证配置信息；在目标应用的页面中注入应用权限验证配置信息。

在一个实施例中，应用权限验证模块，还用于获取对目标集体进行鉴权时所使用的时间戳和随机字符串；确定触发联系人添加操作的页面地址；根据随机字符串、时间戳、页面地址以及第二接口调用临时票据，生成第二签名信息；根据目标集体的集体标识、目标应用的应用标识、时间戳、随机字符串以及第二签名信息生成用于对目标应用进行鉴权的应用权限验证配置信息。

在一个实施例中，跳转模块1606还用于在目标应用通过鉴权之后，响应于在目标应用中触发的联系人添加操作，向第一应用发起跨应用添加联系人界面的跳转请求，跳转请求携带了跨应用联系人添加界面的接口名；通过第一应用在监听到跳转请求时，识别跳转请求所携带的接口名后，从目标应用跳转至接口名对应的跨应用联系人添加界面。

在一个实施例中，跳转模块1606还用于在目标应用中显示待添加的联系人标识；响应于在目标应用交互界面中对联系人标识触发的联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面；

在一个实施例中，添加模块1608还用于在跨应用联系人添加界面的联系人搜索框中，显示联系人标识；当触发对联系人标识的搜索操作时，将联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人。

在一个实施例中，添加模块1608还用于在跨应用联系人添加界面中，显示联系人搜索框；获取在联系人搜索框中输入的联系人标识；当触发对联系人标识的搜索操作时，将与联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人。

在一个实施例中，添加模块1608还用于在跨应用联系人添加界面中，显示第二应用联系人添加图标；响应于对第二应用联系人添加图标的触发操作，显示与第一用户标识关联的第二应用联系人列表；当触发对第二应用联系人列表中联系人的选取操作时，将选取的属于第二应用的第二用户标识确定为待添加的联系人。

在一个实施例中，添加模块1608还用于通过第一应用，响应于对第二应用联系人添加图标的触发操作，根据第一用户标识向第一应用服务器发起第二应用联系人请求后，接收第一应用服务器响应于第二应用联系人请求，根据第一应用服务器在第二应用服务器的接口调用凭证，从第二应用服务器拉取并返回的与第一用户标识关联的第二应用联系人；通过第一应用根据第二应用联系人显示第二应用联系人列表。

在一个实施例中，添加模块1608还用于在跨应用联系人添加界面中，显示扫码添加联系人图标；响应于对扫码添加联系人图标的触发操作，显示扫码界面；在扫码界面中采集并解析属于第二应用的图形码，获得属于第二应用的第二用户标识，作为待添加的联系人。

在一个实施例中，装置还包括名片分享模块，用于在跨应用联系人添加界面中，显示第一应用名片分享图标；响应于对第一应用名片分享图标的触发操作，从第一应用跳转至本地的第二应用，将与第一用户标识对应的、且属于第一应用的名片信息传递至本地的第二应用；获取在本地的第二应用的会话列表中选取的目标会话；通过本地的第二应用将名片信息，发送至以目标会话的会话成员对应的第二用户标识登录的第二应用。

在一个实施例中，添加模块1608还用于通过第一应用，接收第一应用服务器根据第一应用服务器在第二应用服务器的接口调用凭证，从第二应用服务器拉取并返回的与联系人对应的第二用户标识的用户信息；显示待添加的联系人对应的第二用户标识的用户信息。

在一个实施例中，添加模块1608还用于通过第一应用，将待添加的联系人对应的联系人标识发送至第一应用服务器后，通过第一应用服务器从第二应用服务器获取与联系人标识对应的第二用户标识，并根据第二用户标识、第一用户标识与邀请通知模板标识，向第二应用服务器发起联系人添加请求；通过第二应用服务器基于联系人添加请求，根据第一用户标识以及第一用户标识所关联的目标集体的集体标识，生成第一用户标识在第二应用的第一身份标识，在邀请通知模板标识对应的邀请通知模板中填充第一身份标识得到联系人邀请通知，并将联系人邀请通知发送至以第二用户标识登录的第二应用。

在一个实施例中，装置还包括邀请通知响应模块，用于进入以待添加的联系人对应的第二用户标识登录的第二应用；在第二应用中，显示来自目标集体的第一用户标识的联系人邀请通知；响应于对联系人邀请通知中的联系人添加操作，建立属于第二应用的第二用户标识与属于第二应用的第一用户标识之间的联系人关系。

在一个实施例中，装置还包括会话模块，用于在第二应用中，显示第一用户标识在第二应用中的第一身份标识所对应的会话页面；在会话页面中，向以第一用户标识登录的第一应用，发送来自第二用户标识的跨应用会话消息。

在一个实施例中，装置还包括会话模块，用于在第一应用中，显示第二用户标识在第一应用中的第二身份标识所对应的会话页面；在会话页面中，向以第二用户标识登录的第二应用，发送来自第一用户标识的跨应用会话消息。

上述联系人的处理装置1600，目标应用运行在作为原生应用的第一应用中，当以属于第一应用的第一用户标识登录了第一应用，并进入了第一应用中的目标应用交互界面之后，用户可以直接在该目标应用中触发联系人添加操作，目标应用就可以响应于该联系人添加操作，从目标应用交互界面跳转至第一应用的跨应用联系人添加界面，当第一应用在跨应用联系人添加界面中确定待添加的联系人后，第一应用就能够向以该联系人对应的属于第二应用的第二用户标识发送联系人交互通知，触发跨应用添加属于第二应用的第二用户标识为联系人。这样，不需要双方都使用并注册目标应用，也可以通过目标应用建立第一用户标识与第二用户标识之间跨应用的联系人关系，也不需要双方都使用相同的第二应用才能建立联系人关系，从而提高了添加联系人的有效性。

关于联系人的处理装置1600的具体限定可以参见上文中对于联系人的处理方法的限定，在此不再赘述。上述联系人的处理装置1600中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图17所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种联系人的处理方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图17中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法实施例中的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (15)

1.一种联系人的处理方法，其特征在于，所述方法包括：

显示第一应用中的目标应用交互界面，所述第一应用通过第一用户标识登录；

响应于在所述目标应用交互界面中触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面；

在所述跨应用联系人添加界面中确定待添加的联系人后，向与所述联系人对应的第二用户标识发送联系人交互通知，所述第二用户标识是属于第二应用的用户标识，所述第一应用与所述第二应用为不同的应用程序。

2.根据权利要求1所述的方法，其特征在于，所述第一用户标识与目标集体关联，在所述显示第一应用中的目标应用交互界面之后，所述方法还包括：

通过所述目标应用对应的目标应用服务器，获取在第一应用服务器的接口调用凭证，根据所述接口调用凭证从所述第一应用服务器获取第一接口调用临时票据，所述第一接口调用临时票据用于所述目标应用调用所述第一应用服务器提供的预定义接口；

根据所述第一接口调用临时票据生成用于对所述目标集体进行鉴权的集体权限验证配置信息后，在所述目标应用的页面中注入所述集体权限验证配置信息。

3.根据权利要求2所述的方法，其特征在于，所述通过所述目标应用对应的目标应用服务器，获取在第一应用服务器的接口调用凭证，包括：

通过所述目标应用服务器，根据所述目标集体标识与所述目标应用的凭证秘钥，从第一应用服务器获取接口调用凭证；或者，通过所述目标应用服务器，根据所述目标集体标识与所述目标集体的授权码，从第一应用服务器获取接口调用凭证。

4.根据权利要求2所述的方法，其特征在于，所述根据所述第一接口调用临时票据生成用于对所述目标集体进行鉴权的集体权限验证配置信息，包括：

获取时间戳、随机字符串和触发所述联系人添加操作的页面地址；

根据所述随机字符串、所述时间戳、所述页面地址以及所述第一接口调用临时票据，生成第一签名信息；

根据所述目标集体的集体标识、所述时间戳、所述随机字符串以及所述第一签名信息生成用于对所述目标集体进行鉴权的集体权限验证配置信息。

5.根据权利要求2所述的方法，其特征在于，在所述目标集体通过鉴权之后，所述方法还包括：

通过所述目标应用服务器，根据在所述第一应用服务器的接口调用凭证，从所述第一应用服务器获取第二接口调用临时票据；

根据所述第二接口调用临时票据生成用于对所述目标应用进行鉴权的应用权限验证配置信息；

在所述目标应用的页面中注入所述应用权限验证配置信息。

6.根据权利要求5所述的方法，其特征在于，所述根据所述第二接口调用临时票据生成用于对所述目标应用进行鉴权的应用权限验证配置信息，包括：

获取对所述目标集体进行鉴权时所使用的时间戳和随机字符串；

确定触发所述联系人添加操作的页面地址；

根据所述随机字符串、所述时间戳、所述页面地址以及所述第二接口调用临时票据，生成第二签名信息；

根据所述目标集体的集体标识、所述目标应用的应用标识、所述时间戳、所述随机字符串以及所述第二签名信息生成用于对所述目标应用进行鉴权的应用权限验证配置信息。

7.根据权利要求5所述的方法，其特征在于，所述响应于在所述目标应用交互界面中触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面，包括：

在所述目标应用通过鉴权之后，响应于在所述目标应用交互界面中触发的联系人添加操作，向所述第一应用发起跨应用添加联系人界面的跳转请求，所述跳转请求携带了所述跨应用联系人添加界面的接口名；

通过所述第一应用在监听到所述跳转请求时，识别所述跳转请求所携带的接口名后，从所述目标应用交互界面跳转至所述接口名对应的跨应用联系人添加界面。

8.根据权利要求1所述的方法，其特征在于，所述响应于在所述目标应用交互界面中触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面，包括：

在所述目标应用交互界面中显示待添加的联系人标识；

响应于在所述目标应用交互界面中对所述联系人标识触发的联系人添加操作，从所述目标应用交互界面跳转至所述第一应用的跨应用联系人添加界面；

所述在所述跨应用联系人添加界面中确定待添加的联系人，包括：

在所述跨应用联系人添加界面的联系人搜索框中，显示所述联系人标识；

当触发对所述联系人标识的搜索操作时，将所述联系人标识对应的属于第二应用的第二用户标识确定为待添加的联系人。

9.根据权利要求1所述的方法，其特征在于，所述在所述跨应用联系人添加界面中确定待添加的联系人，包括：

在所述跨应用联系人添加界面中，显示联系人搜索框；

获取在所述联系人搜索框中输入的联系人标识；

当触发对所述联系人标识的搜索操作时，将与所述联系人标识对应的属于所述第二应用的第二用户标识确定为待添加的联系人。

10.根据权利要求1所述的方法，其特征在于，所述在所述跨应用联系人添加界面中确定待添加的联系人，包括：

在所述跨应用联系人添加界面中，显示第二应用联系人添加图标；

响应于对所述第二应用联系人添加图标的触发操作，显示与所述第一用户标识关联的第二应用联系人列表；

当触发对所述第二应用联系人列表中联系人的选取操作时，将选取的属于第二应用的第二用户标识确定为待添加的联系人。

11.根据权利要求10所述的方法，其特征在于，所述响应于对所述第二应用联系人添加图标的触发操作，显示与所述第一用户标识关联的第二应用联系人列表，包括：

通过所述第一应用，响应于对所述第二应用联系人添加图标的触发操作，根据所述第一用户标识向第一应用服务器发起第二应用联系人请求后，接收所述第一应用服务器响应于所述第二应用联系人请求，根据所述第一应用服务器在第二应用服务器的接口调用凭证，从所述第二应用服务器拉取并返回的与所述第一用户标识关联的第二应用联系人；

通过所述第一应用根据所述第二应用联系人显示第二应用联系人列表。

12.根据权利要求1所述的方法，其特征在于，所述在所述跨应用联系人添加界面中确定待添加的联系人，包括：

在所述跨应用联系人添加界面中，显示扫码添加联系人图标；

响应于对所述扫码添加联系人图标的触发操作，显示扫码界面；

在所述扫码界面中采集并解析属于第二应用的图形码，获得属于第二应用的第二用户标识，作为待添加的联系人。

13.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述跨应用联系人添加界面中，显示第一应用名片分享图标；

响应于对所述第一应用名片分享图标的触发操作，从所述第一应用跳转至本地的第二应用，将与所述第一用户标识对应的、且属于所述第一应用的名片信息传递至所述本地的第二应用；

获取在所述本地的第二应用的会话列表中选取的目标会话；

通过所述本地的第二应用将所述名片信息，发送至以所述目标会话的会话成员对应的第二用户标识登录的第二应用。

14.根据权利要求1所述的方法，其特征在于，在确定待添加的联系人之后，所述方法还包括：

通过所述第一应用，接收所述第一应用服务器根据所述第一应用服务器在第二应用服务器的接口调用凭证，从所述第二应用服务器拉取并返回的与所述联系人对应的第二用户标识的用户信息；

显示所述待添加的联系人对应的第二用户标识的用户信息。

15.根据权利要求1所述的方法，其特征在于，所述联系人交互通知为用于添加联系人的联系人邀请通知，所述通过所述第一应用，向与所述联系人对应的第二用户标识发送联系人交互通知，包括：

通过所述第一应用，将待添加的联系人对应的联系人标识发送至第一应用服务器后，通过所述第一应用服务器从第二应用服务器获取与所述联系人标识对应的第二用户标识，并根据所述第二用户标识、所述第一用户标识与邀请通知模板标识，向所述第二应用服务器发起联系人添加请求；

通过所述第二应用服务器基于所述联系人添加请求，根据所述第一用户标识以及所述第一用户标识所关联的目标集体的集体标识，生成所述第一用户标识在第二应用的第一身份标识，在所述邀请通知模板标识对应的邀请通知模板中填充所述第一身份标识得到联系人邀请通知，并将所述联系人邀请通知发送至以所述第二用户标识登录的第二应用。

Images