CN115705121A - 日历数据同步方法和电子设备 - Google Patents

Abstract

本申请提供一种日历数据同步方法和电子设备，属于智能终端技术领域，用于解决用户登录CalDAV服务器手动输入用户名和密码等信息，操作比较繁琐的问题。该方法包括：第一应用显示第一界面，第一界面包括第二应用对应的第一控件；响应于针对第一控件的第一操作，从第一界面跳转到第二界面；第二界面为第二应用对应的授权界面；第二界面包括第二控件；响应于针对第二控件的第二操作，获取用于登录目标服务器的身份信息；目标服务器中存储有第二应用对应的日历数据；基于身份信息，将日历数据同步到第一应用。

Description

日历数据同步方法和电子设备

技术领域

本申请涉及智能终端技术领域，特别涉及一种日历数据同步方法和电子设备。

背景技术

目前，支持CalDAV协议的不同应用程序之间，可同步日程等日历数据。日历等应用程序在基于CalDAV协议导入其他应用程序的日历数据时，需要用户手动输入CalDAV的用户名、密码和服务器地址，操作较为复杂，用户体验有待提升。

发明内容

本申请提供了一种日历数据同步方法和电子设备，在一键授权后自动同步日程数据，无需手动输入用户名、密码和服务器地址，提升用户体验。

第一方面，本申请实施例提供一种日历数据同步方法，包括：第一应用显示第一界面，第一界面包括第二应用对应的第一控件；响应于针对第一控件的第一操作，从第一界面跳转到第二界面；第二界面为第二应用对应的授权界面；第二界面包括第二控件；响应于针对第二控件的第二操作，获取用于登录目标服务器的身份信息；目标服务器中存储有第二应用对应的日历数据；基于身份信息，将日历数据同步到第一应用。

在一种可能的实现方式中，第二控件显示有第一文本；第一文本表示用户允许授权。

在一种可能的实现方式中，第一应用显示第一界面之后，从第一界面跳转到第二界面之前，方法还包括：响应于针对第一控件的第一操作，弹出第一弹窗；第一弹窗显示有第二文本，第二文本用于提示用户将要跳转到第二界面；第一弹窗包括第三控件；从第一界面跳转到第二界面，包括：响应于针对第三控件的第三操作，从第一界面跳转到第二界面。

在一种可能的实现方式中，获取用于访问目标服务器的身份信息，包括：获取令牌；令牌为获取身份信息的凭证；发起用于获取身份信息的第一请求至鉴权服务器；第一请求中携带有令牌；鉴权服务器部署于第二应用对应的服务端，用于对第一请求中的令牌进行验证；接收鉴权服务器返回的身份信息。

在一种可能的实现方式中，获取令牌，包括：获取授权码；发起用于获取令牌的第二请求至第一服务器，以触发第一服务器携带授权码向鉴权服务器申请令牌；其中，第二请求中携带有授权码；第一服务器部署于第一应用对应的服务端；接收第一服务器返回的令牌。

在一种可能的实现方式中，获取令牌，包括：获取授权码；发起用于获取令牌的第二请求至鉴权服务器；其中，第二请求中携带有授权码；接收鉴权服务器返回的令牌。

在一种可能的实现方式中，获取授权码，包括：响应于针对第二控件的第二操作，第一应用触发第二应用发起用于获取授权码的第三请求至鉴权服务器，以及接收鉴权服务器返回的授权码；第一应用接收第二应用转发的授权码。

在一种可能的实现方式中，获取令牌，包括：获取用户身份标识；发起第四请求至第一服务器；第四请求中携带有用户身份标识；第四请求用于请求第一服务器查询用户身份标识对应的令牌；接收第一服务器返回的查询结果，在查询结果表示查询到用户身份标识对应的令牌的情况下，读取查询结果中携带的令牌。

在一种可能的实现方式中，获取用户身份标识，包括：发起第五请求至第一账号服务器；第五请求用于登录第一账号服务器；第五请求至少携带有用于登录第一账号服务器的第一用户名；第一账号服务器用于保存用户的第一用户名与用户身份标识之间的映射关系；接收第一账号服务器下发的与第一用户名绑定的用户身份标识。

在一种可能的实现方式中，获取令牌之后，方法还包括：将用户身份标识和令牌上传至第一服务器，以触发第一服务器保存用户身份标识与令牌之间的映射关系。

在一种可能的实现方式中，基于身份信息，将日历数据同步到第一应用，包括：发起用于请求登录目标服务器的第六请求至目标服务器；第六请求中携带有身份信息；接收目标服务器返回的登录成功消息；向目标服务器请求获取日历数据；接收目标服务器返回的日历数据。

在一种可能的实现方式中，方法还包括：发起用于订阅第一消息的第七请求至第一服务器，以触发第一服务器向目标服务器订阅第一消息以及转达第一消息至第一应用；第一消息用于表示日历数据发生变化；在接收目标服务器返回的登录成功消息之后，方法还包括：接收第一服务器推送的第一消息；向目标服务器请求获取日历数据，包括：响应于第一消息，向目标服务器请求获取日历数据。

在一种可能的实现方式中，向目标服务器请求获取日历数据，包括：发起用于获取第一URL的第八请求至目标服务器；第一URL用于描述目标服务器中身份信息对应的日历数据资源的位置；日历数据资源包括第一日历列表；第一日历列表包括多个日程类目，一个日程类目包括至少一个日程；接收目标服务器返回的第一URL；发起用于获取日历列表的第九请求至目标服务器，第九请求中携带第一URL；接收目标服务器返回的日历数据，包括：接收目标服务器返回的第一日历列表。

在一种可能的实现方式中，接收目标服务器返回的日历列表之后，方法还包括：比较第一日历列表和第二日历列表分别对应的日程类目，确定出不同的目标日程类目；第二日历列表为已存储于第一应用的日历列表；在第二日历列表中新建目标日程类目。

在一种可能的实现方式中，向目标服务器请求获取日历数据，包括：确定发生变化的目标日程；发起用于获取第二URL的第十请求至目标服务器；第二URL用于描述在目标服务器中，目标日程对应的日程数据资源位置；接收目标服务器返回的第二URL；发起用于获取目标日程对应的日程数据的第十一请求至目标服务器，第十一请求中携带第二URL；接收目标服务器返回的日历数据，包括：接收目标服务器返回的目标日程的日程数据。

第二方面，本申请技术方案还提供一种日历数据同步系统，系统包括第一应用和第一服务器；

第一应用，用于执行以下操作：显示第一界面，第一界面包括第二应用对应的第一控件；响应于针对第一控件的第一操作，从第一界面跳转到第二界面；第二界面为第二应用对应的授权界面；第二界面包括第二控件；响应于针对第二控件的第二操作，发起请求至第一服务器以获取令牌；基于令牌，获取用于登录目标服务器的身份信息；以及，基于身份信息，将日历数据同步到第一应用；目标服务器中存储有第二应用对应的日历数据；

第一服务器，用于执行以下操作：响应于第一应用发起的请求，发起请求至鉴权服务器以获取令牌，以及接收鉴权服务器返回的令牌；鉴权服务器部署于第二应用对应的服务端；将鉴权服务器返回的令牌发送至第一应用。

第三方面，本申请实施例提供一种电子设备，电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发电子设备执行第一方面任一项的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行第一方面任一项的方法。

第五方面，本申请实施例提供一种计算机程序产品，计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行第一方面任一项的方法。

在一种可能的设计中，第五方面中的程序可以全部或者部分存储在与处理器封装在一起的存储介质上，也可以部分或者全部存储在不与处理器封装在一起的存储器上。

附图说明

图1为现有技术手动输入CalDAV用户名、密码和服务器地址的界面示例图；

图2为本申请提供的日历数据同步方法一个实施例中的界面示例图；

图3本申请提供的日历数据同步方法另一个实施例中的界面示例图；

图4本申请提供的日历数据同步方法又一个实施例中的界面示例图；

图5为本申请提供的日历数据同步方法的硬件系统架构示意图；

图6为本申请提供的日历数据同步方法一个实施例的流程图；

图7为本申请提供的日历数据同步方法一个实施例中的鉴权流程示意图；

图8为本申请提供的日历数据同步方法另一个实施例中的鉴权流程示意图；

图9为本申请提供的日历数据同步方法中鉴权流程的多方信令交互流程图；

图10为本申请提供的日历数据同步方法中同步流程的流程示意图；

图11为本申请提供的日历数据同步方法中同步流程的多方信令交互流程图；

图12为本申请提供的日历数据同步方法的一个实施例中的界面示例图；

图13为本申请提供的日历数据同步方法的软件分层架构示意图；

图14为本申请提供的电子设备的结构示意图。

具体实施方式

本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。

本申请实施例提供的方案，可应用于不同客户端之间同步日历数据的应用场景中。

目前，基于CalDAV协议，能够实现不同的应用程序或者不同电子设备之间的日历数据同步。日历数据可以包括日程数据、日历数据、行事历数据等。CalDAV协议是允许客户端访问远程服务器上的日程信息的互联网标准，是基于HTTP1.1协议的通信协议(Web-based Distributed Authoring and Versioning，WebDAV)进行数据操作的一种开放协议，允许用户通过WebDAV访问日历。

为便于日程管理，用户需要在不同的应用程序之间同步日程等日历数据，例如需要将第二应用的日程数据导入到第一应用中。以第一应用为日历、第二应用为

作为示例，当用户需要将飞书的日历数据导入到日历时，一种已有方式为，用户点击日历App(第一应用)的月视图界面中用于显示扩展选项的控件，弹出下拉菜单，下拉菜单中包括“设置”候选项，用户点击“设置”进入日历设置界面，在日历设置界面中显示“日程导入”按钮，点击该“日程导入”按钮，可以打开如图1中所示的界面11，界面11为日程导入界面，可以看到，该界面11中显示有“CalDAV账号导入”选项，点击该选项，可以打开如图1中所示的界面12。可以看到，界面12中，需要用户输入CalDAV的账号(或者可以称为用户名)、密码和服务器地址。另一种已有方式中，可以在日历App中打开系统设置主界面中的“邮箱、联系人、日历”(Mail、Contacts、calenders)选项，进入“邮箱、联系人、日历”的设置界面，并点击该设置界面下的添加账户(Add Account)选项，进入添加账户界面，添加账户界面中显示有“添加CalDAV账户”(Add CalDAV Account)选项，点击“Add CalDAV Account”选项，该种方式也需要手动输入CalDAV的账号、密码和服务器地址。

此时，用户需要从第二应用手动获取账号、密码和服务器地址。用户在第二应用的设置界面中找到“CalDAV同步”选项，点击该选项可以打开如图1中所示的CalDAV同步界面13，CalDAV同步界面13中显示有“生成CalDAV密码”的控件，用户点击该控件，则触发向服务器请求账号、密码和服务器地址，获取成功后，会在界面14中显示账号、密码和服务器地址，用户将界面14中的账号、密码和服务器地址手动复制粘贴到界面12中，实现CalDAV服务器的登录，以同步日历数据。

上述方式，需要用户从第二应用中手动获取CalDAV账号、密码和服务器地址，再分别输入到第一应用的登录界面中，需要用户在不同的应用程序之间切换界面，操作较为繁琐，且CalDAV协议的用户名和密码都是比较复杂，例如一种现行的CalDAV登录密码示例为vbgh-tmay-sird-lcgk，字符数达到16位以上，手动输入费时费力。此外，界面14中生成的CalDAV用户名、密码均仅仅是临时的用户名和密码，并非长期有效的用户名和密码，仅在短时间内有效，每一次同步请求都会对应生成一个临时的用户名和密码，也就是每一次同步，都需要用户手动获取CalDAV账号、密码和服务器地址，多次同步就需要多次手动填写CalDAV账号、密码和服务器地址，用户体验有待改善。

鉴于此，本申请提供了一种日历数据同步方法和电子设备，能够实现一键授权以同步日程数据，无需手动获取、输入CalDAV账号、密码和服务器地址，至少解决了用户在日程数据同步场景中需要手动获取以及输入复杂密码、用户名等信息的痛点，提升了用户体验。

本申请实施例中，日历数据同步的过程，可以是第一应用将第二应用的日历数据导入到本地的过程，其中，为描述清楚，日历数据导入的应用程序对象，称之为第一应用，作为日历数据导出方的应用程序称之为第二应用。例如，将飞书服务器的用户日历数据导入到同一用户的日历中，则日历为第一应用，飞书为第二应用。第一应用还可以是日历以外的其他支持日程管理的应用程序，第二应用可以是支持日程管理或者具有日历数据访问权限的应用程序，例如第二应用可以是

等。在其他实施例中，第一应用可以是

等支持日程管理的App，而第二应用为日历App。

本申请实施例提供的日历数据同步方法，可以包括如下步骤：

第一应用显示第一界面，第一界面包括第二应用对应的第一控件；第一界面可以是第一应用中包含第二应用对应的候选项的任一界面，例如第一界面可以是添加账户界面。

响应于针对第一控件的第一操作，从第一界面跳转到第二界面；第二界面为第二应用对应的授权界面；一种可能的实现方式为，第一应用检测到用户针对第一控件的第一操作后，调用第二应用以触发第二应用显示第二界面，例如当第二应用为飞书时，则相应的第二界面可以如图2中的界面25所示。

第二界面包括第二控件；响应于针对第二控件的第二操作，获取用于登录目标服务器的身份信息；目标服务器中存储有第二应用对应的日历数据；目标服务器可以是支持CalDAV协议的服务器。

接下来，在拿到身份信息后，第一应用基于身份信息，将第二应用的日历数据同步到第一应用。

其中，第一操作和第二操作可以是单击、长按、双击等操作中的任意一种。

本申请实施例提供的日历数据同步方法的实现，可以包括前端用户界面(UserInterface，UI)交互和后台交互两个层面。下面首先介绍基于该方法实现的UI交互流程。

本申请实施例中，至少提供一种UI交互途径以实现一键同步日历数据。其中第一种UI交互途径为添加账户，也就是将第二应用作为一个账户添加到第一应用可管理的账户集合中，账户添加成功，则自动将第二应用的日历数据同步到第一应用中。

具体地，示例性地，基于第一种途径添加账户的UI界面交互流程如下：

参阅图2所示，在日历App的月视图界面21中，显示有控件201，控件201可以是一个扩展按钮。检测到用户针对该控件201执行了第一目标操作，弹出一个下拉菜单202。下拉菜单202中显示多个候选项，多个候选项中包含“日历账户管理”，检测到用户针对“日历账户管理”进行了第二目标操作，例如进行了点击操作，则打开日历账户管理界面22。上述第一或第二目标操作可以是点击、长按、双击操作中的任意一种。以下描述中，针对各种控件的操作均以点击操作进行示例性阐述，可以理解，点击操作可以替换为其他操作，不再逐一强调。

日历账户管理界面22中显示有控件203，控件203的文本内容可以是“添加账户”或者能够表达同等语义的文本内容。检测到用户针对控件203的第三操作，从当前的日历账户管理界面22跳转到添加账户界面23(第一界面)，在添加账户界面23中，显示多个可添加的候选项。例如，如图2中所示，添加账户界面23中待添加的多个候选项可以包括

等，其中当第二应用为飞书时，则

候选项对应的控件即为第一控件。其中，在一种实现方式中，添加账户界面23中仅显示第一应用所在的电子设备已安装的应用程序作为候选项，电子设备从未使用过的应用程序，则不出现在该界面的候选项中，例如图2中所示的添加账户界面23中显示的多个候选项

均为已安装在本地设备的应用程序。在另外的实现方式中，可以预设多个固定的待添加账户的候选项，即无论是否第一应用所在的电子设备(本地设备)是否安装或者使用过第二应用，都将该第二应用添加到界面23中作为候选项。例如，同一用户持有不同设备，该用户在手机中安装了飞书，在笔记本电脑中安装了WPS，此种情形下，在手机中第一应用显示的添加账户界面(例如图2中所示界面23)中，飞书和WPS都可以作为添加的账户候选项。

检测到用户在界面23中点击“飞书”候选项，则显示第一弹窗(或者对话框)24，第一弹窗24中显示用于提示用户将要跳转到所述第二界面的第二文本，例如第二文本可以是“即将跳转到飞书授权页，是否继续？”，或者其他具有等同自然语义的文本，并且第一弹窗24至少包括第三控件，第三控件显示有第三文本；第三文本表示用户允许跳转到所述第二界面。例如，第一弹窗24显示表示同意跳转到飞书授权页和不同意跳转到飞书授权页的两个控件，例如显示如图2中弹窗24中所示的两个候选按钮“取消”和“继续”，用户点击“继续”(第三控件)，则进入飞书授权界面25。

在飞书授权界面25中，显示相应的文本内容以告知用户当前界面的用途或作用，例如“荣耀日历飞书助手，请求使用你的飞书账号信息”，并且显示另外的文本内容，以提示用户申请授权的身份以及对方将要获得的权限，例如显示文本“你将使用以下身份授权：荣耀日历账户”以及“授权后该应用将获得以下权限：获取你的个人信息(姓名、头像)；生成CalDAV配置信息”等。其中，授权后该应用将要获得的权限包括两种权限，一种是获取用户的个人信息例如姓名、头像等，另一种是生成CalDAV配置信息，如界面25中所示，作为一种可实现的方式，在授权界面中还设置第四控件，用于检测用户是否选中该项权限，用户选中，则认为用户允许获取该项权限，用户未选中，则视为用户不允许获取该项权限。第四控件可以是多个，例如第四控件包括界面25中所示的控件204和控件205，带有斜线标记的控件205表示为被用户选中状态，控件204表示未被选中，则当前用户仅允许生成CalDAV配置信息，而不允许飞书应用获得用户的姓名、头像等个人信息。实际应用中，一种可行方式为，被选中的空间高亮显示，未被选中的控件灰度显示。在本申请实施例提供的日历数据同步方案中，仅需要生成CalDAV配置信息，因而可以在授权界面中，默认控件为选中状态，而控件204为非选中状态。

授权界面下方还设置有第二控件，第二控件显示有第一文本；第一文本表示用户允许授权。例如第二控件可以是用于用户表示确认的按钮或标签控件，相应显示的第一文本可以是“确认授权”“同意授权”“允许授权”等等。需要说明的是，在另外的实现方式中，第二控件也可以不显示第一文本，而是以图形或者符号来代替第一文本，表示确认或者允许。以界面25为例，检测用户针对第二控件进行了第二操作，例如检测到用户点击“确认授权”，若授权成功，则显示刷新后的日历账户管理界面26，在界面26中，相比于之前的原来的日历账户管理界面22，增加了“飞书”账户，即飞书已成为日历应用可管理的账户对象之一。并弹出提示消息“添加成功”。若授权失败，则弹出提示消息“添加失败”。

需要说明的是，图2所示的飞书授权界面25仅为一个示例，待添加的第二应用还可以是

或者

不同的添加对象可以设计不同的授权界面，例如，WPS为添加账户的对象时，如图3所示，基于界面23点击WPS选项，且用户在弹窗30中点击“继续”按钮后，可以跳转到如图3中所示的WPS授权界面31中。

在界面25中，带有文本“31”的图标用于表示日历App，该图标仅为一种示例，还可以在该授权界面中设置其他形式的图标或者标识。

此外，在另外的实现方式中，为与CalDAV协议兼容，图2中所示的添加账户界面23还可以添加CalDAV选项。参阅图4所示，用户点击日历账户管理界面22中的“添加账户”控件203之后，可以打开如图4中所示的添加账户界面41，该界面41中还显示了“CalDAV”账户选项，用户点击该“CalDAV”选项，打开添加CalDAV账户的界面42，即在该种实现方式中，保留了原有的手动添加CalDAV账户的方式，以兼容更多支持CalDAV协议的应用程序。

本申请实施例还可以提供第二种UI交互途径以实现一键同步日历数据，第二种UI交互途径是从日程导入界面跳转到授权界面。例如，如图2中界面21所示，用户可以在日历App的月视图主界面点击第一控件201，在弹出的下拉菜单中，还显示有“设置”，检测到用户点击“设置”，打开日历设置界面，在日历设置界面中会显示“日程导入”按钮或者标签，检测到用户点击“日程导入”后，会进入日程导入界面，在该日程导入界面中，选择“CalDAV账号导入”，会弹出一个对话框或者弹窗，对话框或者弹窗中显示多个支持CalDAV协议的第二应用，用户选择其中一个应用，则也可以跳转到授权界面，例如用户选择飞书，则跳转到界面25，用户选择WPS，则跳转到界面31。授权成功，则可以自动将第二应用的日历数据导入到第一应用中。

需要说明的是，在一个实施例中，用户在添加账户界面23中点击飞书或者WPS之后，不会直接显示控件24，而是后台查询当前日历客户端是否已登录荣耀账号，是，则显示控件24，否则，则跳转到荣耀账号登录界面，待登录荣耀账号之后，再刷新界面23，并显示控件24，用户点击“继续”，则跳转到授权界面，例如跳转到界面31或者界面25。

或者，用户点击控件24中的“继续”按钮后，后台查询当前日历客户端是否已登录荣耀账号，是，则直接跳转到授权界面，例如跳转到界面31或界面25；否，则跳转到荣耀账号登录界面，待登录荣耀账号之后，再跳转到授权界面。

如此，基于本申请实施例提供的方法，用户仅需要在授权界面中点击“允许”或者“确认授权”等按钮，即可自动同步日历数据，实现一键授权自动同步日历数据，无需手动输入用户名、密码和服务器地址，操作便捷度明显提升。

上述添加账户的实现，还依赖于后台执行了相应的鉴权流程，后台鉴权成功，则在前端的UI交互表现为账户添加成功；鉴权失败，则账户添加失败，无法实现日程等日历数据的同步。

下面从后台交互角度，阐述本申请提供的日历数据同步方案中，如何实现鉴权。

本申请实施例中提供的鉴权机制以及后续的日历数据同步机制，可以基于图5所示的系统架构实现。下面以图5所示的系统架构为例，对本申请实施例提供的方法的后台交互流程进行示例性说明。

如图5所示，第一应用服务平台为第一应用的服务端，第二应用服务平台为第二应用的服务端。第一应用服务平台中至少部署有第一应用服务器，第二应用服务平台中部署有鉴权服务器和CalDAV服务器。例如，若第一应用为日历，则第一应用服务平台则为日历App的服务端，第一应用服务器也可以称为日历服务器，即日历客户端对应的服务器。若第二应用为飞书，则第二应用服务平台即飞书App的服务端，也可以称为飞书服务平台，或者称之为第三方服务平台。第一或第二应用服务平台可以是独立的服务器，也可以是服务器集群，图5中所示的第二应用平台可以包括支持oAuth2.0协议的鉴权服务器和支持CalDAV协议的CalDAV服务器；第一应用服务平台，除包括图5中所示的第一应用服务器以外，还可以包括第一应用开发者的账号管理服务器，例如第一应用开发者为荣耀，则账号管理服务器为荣耀账号服务器。OAuth2.0协议是OAuth协议的延续版本，可以通过组织在资源拥有者(例如CalDAV服务器)和资源访问者以及客户端之间的交互动作，获得用户访问第三方应用的数据资源(例如飞书日程数据)的权限。

安装有第一应用的第一终端设备，基于oAuth2.0协议，首先会向鉴权服务器申请一个授权码，基于该授权码，通过第一应用平台，向鉴权服务器申请换取令牌，第一终端设备从第一应用服务器拿到令牌后，携带该令牌向鉴权服务器申请可以访问CalDAV服务器的用户名和密码以及服务器地址，第一应用拿到用户名和密码以及服务器地址之后，则携带用户名和密码以及服务器地址，访问CalDAV服务器，以请求同步第二应用的日历数据。

具体地，示例性地，参阅图6所示，本申请实施例提供的方法中，后台交互流程可以包括：

601，第一应用发起鉴权请求，获取授权码。

第一应用(例如日历客户端)向第二应用服务平台(飞书服务平台)的鉴权服务器发起授权登录请求，响应于该请求，鉴权服务器通知第一应用显示授权登录界面(例如界面25)，检测到用户点击“确认授权”按钮后，鉴权服务器会重定向到日历客户端，并且携带临时票据code参数，也就是授权码。

602，第一应用以授权码换取令牌。

第一应用通过code参数调用鉴权服务器的接口，以获取令牌，例如获取access_token、refresh_token等字段信息。

603，第一应用服务器(例如日历服务器)绑定该用户的荣耀账号和令牌之间的映射关系。

第一应用将荣耀账号和令牌等上传到第一应用服务器，第一应用服务器保存荣耀账号和令牌的映射关系。以便于在下次申请鉴权时预先查询该荣耀账号是否具有对应的有效的令牌，是，则无需再获取令牌。

604，第一应用通过令牌获取CalDAV用户名、密码和服务器地址。

605，第一应用利用CalDAV用户名、密码和服务器地址，访问CalDAV服务器，开始同步日历数据。

上述流程可以划分为鉴权和同步两部分流程实现，只有鉴权通过才能进行数据同步。

下面详细阐述鉴权流程。从第一终端设备的角度描述，鉴权流程至少包括如下步骤：

获取令牌；令牌为获取身份信息的凭证；第一应用发起用于获取身份信息的第一请求至鉴权服务器；第一请求中携带有令牌；然后，接收鉴权服务器返回的身份信息鉴权服务器部署于第二应用对应的服务端，用于对第一请求中的令牌进行验证。身份信息包括用于登录CalDAV服务器的用户名、密码和服务器地址。

示例性地，鉴权流程可以基于图7所示的硬件系统架构实现。图7中，第一终端设备为手机71，该手机71中安装有日历App，第一应用服务器(或者称为第一服务器)即日历服务器73，部署于第一应用服务平台，例如荣耀服务平台。鉴权服务器72部署于飞书服务平台。相应的鉴权流程包括如下步骤：

701，手机71向鉴权服务器72申请获取授权码；

例如获取授权码oAuthCode。oAuthCode仅为授权码的一种示例性的字段标识，在请求消息中“code”参数也可以用于表示授权码。

702，鉴权服务器72返回授权码(oAuthCode)；

例如，鉴权服务器72回传授权码的消息中可以包含“code＝AUTHORIZATION_CODE”，该code参数的值即为授权码。

703，手机71将获得的授权码(oAuthCode)传递给日历服务器73；

704，日历服务器73向鉴权服务器72发起以授权码换取令牌的请求；例如，以授权码oAuthCode换取accesstoken的请求。

705，鉴权服务器72返回令牌(包括accesstoken)至日历服务器73；

鉴权服务器72下发的令牌包括accesstoken。例如，鉴权服务器72下发的令牌可以是accesstoken，也可以是同时下发accesstoken和refresh_token。refresh_token用于在accesstoken失效后，换取新的accesstoken，以延长accesstoken的时效，减少活跃用户的鉴权次数。

706，日历服务器73将令牌(包括accesstoken)返回手机71；

707，手机71携带令牌向鉴权服务器72请求获取CalDAV用户名、密码和服务器地址；

708，鉴权服务器72检查令牌的合法性和权限，检查通过，则返回CalDAV用户名、密码和服务器地址至手机71。

手机71拿到CalDAV用户名、密码和服务器地址之后，就可以访问CalDAV服务器，获取飞书App下的日历数据，进而导入到日历App中。

其中，鉴权服务器72为支持oAuth2.0协议的服务器，可以基于oAuth2.0协议先后下发oAuthCode和accesstoken，在步骤708中，鉴权服务器72对手机71发送的accesstoken的合法性和权限进行检查，检查通过，鉴权服务器72会向CalDAV服务器申请生成CalDAV用户名、密码和服务器地址，在CalDAV服务器将生成的CalDAV用户名、密码和服务器地址返回给鉴权服务器72之后，鉴权服务器72再将CalDAV用户名、密码和服务器地址返回给手机71。

需要说明的是，在一种实现方式中，步骤701之前，日历服务器73会先向鉴权服务器72申请备案，拿到客户端ID(client ID)，或者还一起拿到客户端密钥(client secret)，客户端ID为应用级ID，一般而言，一个应用开发者开发的一种应用程序对应于同一应用级ID。

日历服务器73会将客户端ID(或者，连同密钥)主动下发给手机71，或者作为出厂值写入到日历应用程序中，或者在程序升级时写入，也就是说，在一种可行的实现方式中，该应用级ID和密钥可以作为出厂值写入日历客户端中，即合法的日历App中本身存储有合法的客户端ID和密钥，无需手机71再向日历服务器73获取。

在另外的实现方式中，手机71也可以会向日历服务器73申请获得该应用级的合法的客户端ID，手机71获得客户端ID和密钥后，再执行步骤701，步骤701中手机71向鉴权服务器72申请获取oAuthCode的请求中，携带有该客户端ID和密钥，鉴权服务器72中存储有白名单，白名单中记录已备案的具有合法访问权限的多个合法的客户端ID，鉴权服务器72基于该白名单，对手机71发送的客户端ID和密钥进行校验，校验通过，则手机71中安装的日历客户端为合法客户端，返回oAuthCode。

需要说明的是，在手机71中安装有第一应用和第二应用的前提下，参阅图8所示，上述图7所示的流程中，在一种可能的实现方式中，步骤701和702可以基于如下流程实现：

用户在第一界面弹出的弹窗中确认跳转到第二应用的授权界面，则第一应用触发第二应用显示第二界面。例如，以第二应用为飞书或者WPS为例，在如图2所示的弹窗24或者如图3所示的弹窗30中，用户点击“继续”按钮，则第一应用调用第二应用，以触发第二应用显示如图2中所示的界面25或者如图3中所示的界面31，第二应用检测到用户点击界面25中的“确认授权”或者界面31中的“允许”，则响应于用户的操作，第二应用执行步骤701，也就是向鉴权服务器发起请求以获取授权码，步骤701发送的请求中可以携带第二应用的用户账号或者用户身份标识信息，以便于第二应用平台能够识别手机71持有者的用户身份；鉴权服务器向第二应用返回授权码，第二应用接收到该授权码之后，再转发给第一应用。第一应用获得授权码之后，再执行步骤703。

为进一步理解本申请实施例提供的鉴权流程，下面列举一个鉴权流程的具体示例，该示例性方案的信令交互流程图如图9所示。

901，用户发出添加第二应用账户的指令；

例如，用户在图2所示的添加账户界面23中点击“飞书”，视为用户发出添加飞书账户(第二应用账户)的指令，日历客户端检测到了用户针对“飞书”控件的点击操作，则进入步骤902；

902，日历客户端判断当前用户是否已登录荣耀账号，否，则进入步骤903；是，则进入步骤905；

903，日历客户端向荣耀账号服务器(第一账号服务器)发起登录荣耀账号服务器的请求；

该请求中携带有用户用于登录荣耀账号服务器的第一用户名和第一密码或验证码等信息，以用于登录荣耀账号服务器。例如，该第一用户名为手机号或者邮箱地址等，验证码可以是手机短信获取的验证码等等。需要说明的是，此处的用户名和密码不同于用于登录CalDAV服务器的用户名和密码，为防止混淆，将此处用于登录荣耀账号服务器的用户名和密码定义为第一用户名和第一密码。

该步骤在UI交互层面可以表现为自动跳转到登录荣耀账号的界面，对于已注册用户，也可以仅由后台程序执行而不在UI交互层面表现，即后台自动登录到荣耀账号服务器，而用户无感知；对于还未注册荣耀账号的新用户，则可以跳转到荣耀账号注册界面；

904，荣耀账号服务器返回荣耀账号信息；

需要说明的是，本申请实施例中的荣耀账号可以理解为用户身份标识或者用户身份证明(User Identification，UID)。在903中携带的第一用户名和第一密码验证通过后，则登录成功，荣耀账号服务器返回该第一用户名对应的UID，该UID为第一应用和第一应用服务平台系统用于唯一标识一个用户的编号，例如，实际应用中，示例性地，该UID可以是64位的二进制数字编号。荣耀账号服务器会保存第一用户名与UID之间的映射关系。

905，根据荣耀账号信息到日历服务器中查询该荣耀账号是否已有对应的令牌。

在905中，根据荣耀账号服务器返回的UID，查询该用户是否已有对应的令牌。日历服务器需要保存令牌与UID之间的映射关系。

例如，查询当前荣耀账号是否绑定了仍处在有效期内的accesstoken。

906，日历服务器返回查询结果。

907，日历客户端接收日历服务器返回的查询结果，查询结果表示查询到了该荣耀账号存在绑定的accesstoken，且在查询结果中携带了accesstoken，则跳转到步骤916；

如果日历服务器没有查询到与该荣耀账号绑定的有效的accesstoken，则进入步骤908，以发起鉴权请求；

908，日历客户端向鉴权服务器(例如飞书鉴权服务器)发起鉴权请求，该鉴权请求即基于oAuth2.0协议对日历客户端的登录权限进行授权的请求；

如前所述，该鉴权请求中，可以携带日历客户端(第一应用)的客户端ID和客户端密钥，鉴权服务器对客户端ID和客户端密钥进行验证，通过，则进入步骤909，否则，拒绝日历客户端的鉴权请求。

909，对日历客户端的客户端ID验证通过，则鉴权服务器返回允许登录的消息，以触发显示授权界面；

示例性地，鉴权服务器可以直接触发第二应用(例如飞书客户端)显示授权界面，也可以是先通知日历客户端，然后通过日历客户端触发第二应用显示授权界面。

910，显示授权界面；

需要说明的是，步骤910可以是日历客户端调用第二应用以显示授权界面，例如，触发WPS客户端显示图3中所示的授权界面31，或者触发飞书客户端显示图2中所示的授权界面25；用户点击“允许”或者“确认授权”，第二应用检测到用户的确认操作后，向鉴权服务器发送用户已确认的通知；该确认通知中可以携带有第二应用的用户账号或者用户身份标识信息。该确认通知可以理解为图7中步骤701发送的获取授权码的请求。

911，鉴权服务器重定向到日历客户端，并下发oAuthCode至日历客户端。

在步骤911中，作为一种可实现的方式，在下发oAuthCode之前，可以是鉴权服务器重定向到第一应用也就是日历客户端，然后将oAuthCode直接发送给日历客户端；在另外的实现方式中，也可以按照图8中所示的流程，鉴权服务器先将oAuthCode发送给飞书客户端，飞书客户端再转发给日历客户端。

912，日历客户端以oAuthCode获取accesstoken。

913，日历服务器返回accesstoken至日历客户端。

此处需要说明的是，作为一种实施方式，如上述图7所示的鉴权流程，日历服务器返回的accesstoken是向鉴权服务器申请得到的，也就是在步骤912和步骤913之间，还包括：日历服务器将oAuthCode发送给鉴权服务器，以请求获得accesstoken，鉴权服务器会向日历服务器返回accesstoken，日历服务器接收鉴权服务器返回的accesstoken，即，日历服务器返回给日历客户端的accesstoken是向鉴权服务器申请获得的。在该种实现方式中，鉴权服务器仅对日历服务器开放以授权码换取令牌的数据接口，不会直接将令牌下发给日历客户端，而是先下发给日历服务器，由日历服务器将令牌转发给日历客户端。这种处理方式，相比于直接将令牌下发给客户端，安全性更高。

在另外的实施方式中，也可以采用鉴权服务器直接下发令牌到客户端的方式，日历客户端可以直接向鉴权服务器申请以授权码换取令牌，而无需通过日历服务器转发，也就是在另外的实施例中，在步骤911和914之间，可以包括步骤：

日历客户端发起携带有oAuthCode的请求至鉴权服务器，以申请获取accesstoken；响应于该请求，鉴权服务器返回accesstoken至日历客户端。将该步骤替换步骤912和913，可获得另外的实施例。

914，日历客户端将接收到的令牌和荣耀账号上传给日历服务器，以使得日历服务器保存荣耀账号和令牌的映射关系。

这样，在接收到下一次添加账户请求时，可以根据荣耀账号查询当前荣耀账号是否在近期已执行过鉴权，并且获得了仍处在有效期内的令牌，例如能够查询到仍处在有效期内的accesstoken或refresh_token，则直接跳过本次鉴权流程，进入步骤915，避免短时间内重复执行鉴权流程。

915，日历客户端使用令牌向鉴权服务器请求获取CalDAV用户名、密码和服务器地址。

916，鉴权服务器根据日历客户端发送的令牌，向CalDAV服务器申请CalDAV用户名、密码和服务器地址。

917，CalDAV服务器返回CalDAV用户名、密码和服务器地址至鉴权服务器。

在一种实现方式中，一种第二应用对应的CalDAV服务器地址是相对固定的，或者说，第二应用服务平台为第一应用指定的具有访问权限的CalDAV服务器地址在一段时间内是固定的，因而在916中，鉴权服务器如果能够确定第一应用可以访问的CalDAV服务器地址，则仅需向CalDAV服务器申请用户名和密码，无需每次鉴权均获取服务器地址。在917中，CalDAV服务器可以仅返回用户名和密码，由鉴权服务器自动去填充服务器地址。

需要说明的是，已有的CalDAV协议中，默认每次下发给访问方的用户信息中，包含服务器地址信息，因而，为与已有的CalDAV协议兼容，保持统一的数据格式，在916和917中，仍需要交互服务器地址。

919，鉴权服务器将CalDAV用户名、密码和服务器地址返回给日历客户端。

日历客户端拿到CalDAV用户名、密码和服务器地址之后，就可以申请访问CalDAV服务器以获得同步日历数据的权限。日历客户端登录CalDAV服务器之后的流程即为日历数据同步的流程。

基于图10所示的硬件系统架构，日历数据同步流程可以包括如下步骤：

1001，安装有日历客户端的手机71，向CalDAV服务101(即目标服务器)发起登录请求，登录请求中携带有CalDAV用户名、密码和服务器地址；

1002，CalDAV服务器101返回登录成功消息；

1003，手机71向CalDAV服务器101请求第二应用的日历数据；

1004，CalDAV服务器101返回第二应用的日历数据至手机71。

步骤1001-1004是在成功登录CalDAV服务器后，由日历客户端主动向CalDAV服务器请求日历数据。

可选的，还可以通过日历服务器73推送日程变化通知给日历客户端。

1005，日历客户端向日历服务器请求订阅日程变化通知；

在一种可能的实现方式中，该请求中可以携带CalDAV用户名和密码信息；

1006，日历服务器73在接收到日历客户端发送的订阅请求后，会向CalDAV服务器请求订阅日程变化通知；

日历服务器发出的该请求中可以携带CalDAV用户名和密码信息，以使得CalDAV服务器能够识别请求订阅的用户的身份；

1007，CalDAV服务器检测到日历数据变化后，返回日程变化通知给日历服务器；

1008，日历服务器73向手机71中的日历客户端推送日程变化通知；

日历客户端在接收到日历服务器73推送的日程变化通知后，可以触发执行步骤1003。可见，步骤1001-1004与步骤1005-1008之间在执行时序上并无明确的先后顺序，步骤1005-1007可以在1001和1002之前执行。步骤1003和1004可以在步骤1008之后执行。步骤1003和1004一般在步骤1002之后执行。步骤序号仅为一种执行时序下的示例性编号，不可作为对各个步骤执行顺序的限定。

具体地，日历客户端向CalDAV服务器请求的触发条件不唯一，例如，用户在日历App中执行上述添加账户的操作，执行上述鉴权流程并且登录到CalDAV服务器之后，会触发日历客户端向CalDAV服务器请求日历数据；日历客户端在收到日历服务器推送的日程变化通知，也会触发日历客户端请求日历数据；此外，还可以在用户交互层面，提供用于用户设置日历数据同步的控件，例如可以设置实时同步、周期性同步的控件让用户选择，或者设置是全量同步还是增量同步的控件，等等。若用户设置周期性同步，则到达一个计时周期，触发一次日历数据的请求。

参阅图11所示，日历数据同步的流程可以包括：

1101，日历客户端基于CalDAV用户名、密码和服务器地址，登录CalDAV服务器；

1102，CalDAV服务器返回登录成功消息；

1103，日历客户端向日历服务器申请订阅日程变化通知；

1104，日历服务器向CalDAV服务器申请订阅日程变化通知；

1105，CalDAV服务器检测到日程变化，发送日程变化通知到日历服务器；

1106，日历服务器推送日程变化通知到日历客户端；

1107，日历客户端向CalDAV服务器申请获取要访问的日程数据资源对应的第一统一资源定位地址(Uniform Resource Locator,URL)；

该第一URL，为CalDAV服务器上第二应用对应的日程数据资源中对应于当前用户的资源地址。CalDAV服务器根据日历客户端发送的用户名和密码识别其用户身份，进而查询该用户对应的第二应用下的日程数据资源的地址。例如，飞书在CalDAV服务器上的地址可以是feishu.caldav.cn，日历客户端可以发送一个PROPFIND请求：https://feishu.caldav.cn/获取current-user-principal，返回的current-user-principal的值即为当前用户对应的第一URL。

1108，返回第一URL。

1109，根据第一URL，获取日历列表；

日历列表为用于维护和管理日程的数据表，日历列表将日程划分为多个类目，将多个日程按照类目分别管理和存储。本申请实施例中的日历客户端支持用户新建类目，例如参阅图2和图12所示，图2中所示界面22中“我的日历”选项被选中后，会显示如图12所示的界面111，“我的日历”可以理解为一个日历列表，该日历列表下包括“工作”“旅游”“学习”“刘XX”“王XX”的多个类目，其中“工作”类目下的日程可以是都关于工作的，“刘XX”类目下的日程则可以是与“刘XX”相关的日程。

1110，CalDAV服务器返回日历列表；

1111，日历客户端比较CalDAV服务器返回的日历列表与本地日历列表；

首先，比较本地日历列表与CalDAV服务器返回的日历列表的类目是否一致，例如本地日历列表仅有一个类目，而CalDAV服务器返回的日历列表中包括多个类目，或者类目数目一致，但类目名称不一致，也认为是不同的类目，则在本地新建类目，以与CalDAV服务器返回的日历列表保持一致，也就是保持同步。日历列表中的一个类目可以包括多个日程，日历列表下的类目可以理解为日程集合。

具体地，每个日历都有一个CTag，CTag的作用类似于更改ID。每次CTag更改时，可以知道日历中的某些内容也更改了。CalDAV使用了许多类似的属性，在这种情况下，日历客户端可以向CalDAV服务器获取包含有“displayname”(显示名称)和CTag的日历列表；其中，显示名称是用户为日历指定的可读名称。每次获取的CTag要保存在本地，以在之后通过对比CTag来判断服务器一端的日历数据是否有变化。

1112，更新本地日历；

日历存储模块可以独立于日历客户端的小程序，也可以是日历客户端内部的存储模块。图10仅为清楚示意流程，日历存储模块与日历客户端可以合并为一个执行主体。

1113，日历客户端根据上次日程数据同步的synctoken，查询变化日程；

与鉴权流程相似的是，在数据同步的流程中，每一次数据同步，CalDAV服务器还会下发一个synctoken，用于记录本次同步的时间和同步的日程范围，例如，上一次同步的synctoken是更新了某日12:00之前的日程，则本次同步仅获取某日12:00之后的日程。

1114，返回第二URL；

1115，根据第二URL地址获取日程ics文件；

1116，解析ics文件；

1117，更新本地日程。

本申请实施例还提出了一种软件分层架构以实现上述方法。具体地，参阅图13所示，该软件分层系统架构分为四层：

第一层：第二应用服务平台。

该第二应用服务平台部署有鉴权服务器、数据变化监听接口、Rest Api数据同步接口、CalDav服务器。其中，鉴权服务器即oAtuh 2.0协议服务器，例如可以是支持oAtuh2.0For Native版本的鉴权服务器或者是支持oAtuh 2.0标准协议的鉴权服务器。Caldav服务器即支持Caldav协议的服务器，Caldav服务器用于实现数据同步，并且上述方法实施例也多以Caldav服务器为例进行阐述。在另外的实施例中，也可以采用Rest Api数据同步接口来实现日历数据同步。例如，当第二应用为WPS时，则采用oAtuh 2.0标准协议进行鉴权，且采用Rest Api数据同步接口来实现数据同步。当第二应用为飞书时，则适于采用oAtuh2.0For Native方案进行鉴权，采用Caldav服务器进行数据同步。

第二层：第一应用服务平台。

至少部署有第一应用服务器，当第一应用为日历时，则第一应用服务器为日历服务器。日历服务器中部署有如图13中所示的鉴权服务模块。基于该模块，日历服务器可以作为第二应用服务平台与客户端之间进行鉴权的纽带，出于数据安全性考虑，第二应用平台中的Caldav服务器的部分接口或Rest Api数据同步接口，有时只能服务器调用，而客户端不能调用，因而需要以日历服务器作为鉴权的中介。

第一应用服务平台还可以部署有账号服务器，账号服务器中可以部署如图13中所示的账号关系存储服务模块，该模块主要用于管理荣耀账号，处理登录荣耀账号的请求等。在鉴权场景中，将鉴权和荣耀账号绑定，通过荣耀账号对用户进行识别和管理，可以应对同一用户持有多设备、用户更换硬件设备或者在不同的硬件设备之间切换使用的场景，保证换机场景或者多设备场景不用重复鉴权、重复数据订阅。

示例性地，账号关系存储服务模块中，可以通过以下数据表1维护账号信息：

表1

荣耀ID	Code	accesstoken	refresh_token
				Xxxxxxx	Xxxxxxx	Xxxxxx	Xxxxxxx

日历服务器中还可以部署有如图13中所示的数据订阅模块，该模块用于订阅第二应用服务平台的日程变化通知服务，当第二应用服务平台数据变化时通知日历服务器。

日历服务器中还可以部署有如图13中所示的push消息服务模块，该模块用于在收到第二应用服务平台发送的日程变化消息之后，push给日历客户端。

第三层：日历客户端。

日历客户端可以包括鉴权客户端模块、荣耀账号模块、账号管理模块、Push消息接收模块、数据同步模块和同步设置模块。

鉴权客户端模块用于实现oAuth2.0鉴权中由客户端执行的部分流程。

荣耀账号模块，用于向服务端获取荣耀账号以及处理荣耀账号登录等相关操作。

账号管理模块，用于维护荣耀账号与获取到的令牌、授权码以及用户名、密码和服务器地址，例如，账号管理模块可以通过如下表2维护用户账号信息：

表2

push消息接收模块，用于接收日历服务器推送的日程变化消息。

数据同步模块，包括CalDAV客户端模块和Rest Api客户端模块，用于与服务端的CalDAV服务器或者Reat API数据同步接口对接，以同步日历数据。

同步设置模块，用于通过UI交互，设置自动同步、立即同步或者每隔预定周期进行周期性同步，例如按照15分钟、30分钟等频率同步。

第四层：日历存储客户端。

主要是存储日程、日历列表等个人日历数据。

其中，上述第三层和第四层设置于客户端。在终端设备的操作系统提供的分层架构环境中，例如基于安卓(Android)系统的分层架构，从上至下分别为应用层，框架层，安卓运行时(Android runtime)和系统库，以及内核层。上述第三层中日历客户端中的各个模块以及第四层的日历存储模块，可以部署于安卓分层架构中的应用层。

综上，基于本申请实施例提供的方案，用户点击一个“允许”或者“确认授权”等表示确认的按钮就可以同步日历等日历数据，无需输入用户名，密码，服务器地址，实现一键同步日历数据。

与上述实施例对应，本申请还提供了一种电子设备。图14为本发明实施例提供的一种电子设备的结构示意图，所述电子设备1400可以包括：处理器1401、存储器1402及通信单元1403。其中，处理器1401、存储器1402及通信单元1403之间可以通过内部连接通路互相通信，传递控制和/或数据信号，存储器1402用于存储计算机程序，处理器1401用于从存储器1402中调用并运行该计算机程序。

其中，通信单元1403，用于建立通信信道，从而使电子设备可以与服务端进行通信。

处理器1401，为存储设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器1402内的软件程序和/或模块，以及调用存储在存储器内的数据，以执行电子设备的各种功能和/或处理数据。

存储器1402可以是只读存储器(read-only memory，ROM)、可存储静态信息和指令的其它类型的静态存储设备、随机存取存储器(random access memory，RAM)或可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者还可以是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质等。

上述处理器1401可以和存储器1402合成一个处理装置，更常见的是彼此独立的部件，处理器1401用于执行存储器1402中存储的程序代码来实现上述功能。具体实现时，该存储器1402可以集成在处理器1401中，或者，独立于处理器1401。

当存储器1402中的执行指令由处理器1401执行时，使得电子设备1400能够执行上述实施例中的部分或全部步骤。具体可参考上述实施例，在此不再赘述。

本申请还提供一种电子设备，所述设备包括存储介质和中央处理器，所述存储介质可以是非易失性存储介质，所述存储介质中存储有计算机可执行程序，所述中央处理器与所述非易失性存储介质连接，并执行所述计算机可执行程序以实现本申请上述任一实施例提供的方法。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行本申请上述任一实施例提供的方法。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行本申请上述任一实施例提供的方法。

本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示单独存在A、同时存在A和B、单独存在B的情况。其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项”及其类似表达，是指的这些项中的任意组合，包括单项或复数项的任意组合。例如，a，b和c中的至少一项可以表示：a，b，c，a和b，a和c，b和c或a和b和c，其中a，b，c可以是单个，也可以是多个。

本领域普通技术人员可以意识到，本文中公开的实施例中描述的各单元及算法步骤，能够以电子硬件、计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

在本申请所提供的几个实施例中，任一功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory；以下简称：ROM)、随机存取存储器(Random Access Memory；以下简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (19)

1.一种日历数据同步方法，其特征在于，所述方法包括：

第一应用显示第一界面，所述第一界面包括第二应用对应的第一控件；

响应于针对所述第一控件的第一操作，从所述第一界面跳转到第二界面；所述第二界面为所述第二应用对应的授权界面；所述第二界面包括第二控件；

响应于针对所述第二控件的第二操作，获取用于登录目标服务器的身份信息；所述目标服务器中存储有所述第二应用对应的日历数据；

基于所述身份信息，将所述日历数据同步到所述第一应用。

2.根据权利要求1所述的方法，其特征在于，

所述第二控件显示有第一文本；所述第一文本表示用户允许授权。

3.根据权利要求1所述的方法，其特征在于，所述第一应用显示第一界面之后，从所述第一界面跳转到所述第二界面之前，所述方法还包括：

响应于针对所述第一控件的第一操作，弹出第一弹窗；所述第一弹窗显示有第二文本，所述第二文本用于提示用户将要跳转到所述第二界面；所述第一弹窗包括第三控件；

所述从所述第一界面跳转到所述第二界面，包括：

响应于针对所述第三控件的第三操作，从所述第一界面跳转到所述第二界面。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述获取用于访问目标服务器的身份信息，包括：

获取令牌；所述令牌为获取所述身份信息的凭证；

发起用于获取所述身份信息的第一请求至鉴权服务器；所述第一请求中携带有所述令牌；所述鉴权服务器部署于所述第二应用对应的服务端，用于对所述第一请求中的令牌进行验证；

接收所述鉴权服务器返回的身份信息。

5.根据权利要求4所述的方法，其特征在于，所述获取令牌，包括：

获取授权码；

发起用于获取所述令牌的第二请求至第一服务器，以触发所述第一服务器携带所述授权码向所述鉴权服务器申请令牌；其中，所述第二请求中携带有所述授权码；所述第一服务器部署于所述第一应用对应的服务端；

接收所述第一服务器返回的令牌。

6.根据权利要求4所述的方法，其特征在于，所述获取令牌，包括：

获取授权码；

发起用于获取所述令牌的第二请求至所述鉴权服务器；其中，所述第二请求中携带有所述授权码；

接收所述鉴权服务器返回的令牌。

7.根据权利要求5或6所述的方法，其特征在于，所述获取授权码，包括：

响应于针对所述第二控件的第二操作，第一应用触发第二应用发起用于获取授权码的第三请求至所述鉴权服务器，以及接收所述鉴权服务器返回的授权码；

第一应用接收所述第二应用转发的授权码。

8.根据权利要求4所述的方法，其特征在于，所述获取令牌，包括：

获取用户身份标识；

发起第四请求至所述第一服务器；所述第四请求中携带有所述用户身份标识；所述第四请求用于请求所述第一服务器查询所述用户身份标识对应的令牌；

接收所述第一服务器返回的查询结果，在所述查询结果表示查询到所述用户身份标识对应的令牌的情况下，读取所述查询结果中携带的令牌。

9.根据权利要求8所述的方法，其特征在于，所述获取用户身份标识，包括：

发起第五请求至所述第一账号服务器；所述第五请求用于登录所述第一账号服务器；所述第五请求至少携带有用于登录所述第一账号服务器的第一用户名；所述第一账号服务器用于保存用户的第一用户名与用户身份标识之间的映射关系；

接收所述第一账号服务器下发的与所述第一用户名绑定的用户身份标识。

10.根据权利要求8或9所述的方法，其特征在于，所述获取令牌之后，所述方法还包括：

将所述用户身份标识和所述令牌上传至所述第一服务器，以触发所述第一服务器保存所述用户身份标识与所述令牌之间的映射关系。

11.根据权利要求1所述的方法，其特征在于，所述基于所述身份信息，将所述日历数据同步到所述第一应用，包括：

发起用于请求登录所述目标服务器的第六请求至所述目标服务器；所述第六请求中携带有所述身份信息；

接收所述目标服务器返回的登录成功消息；

向所述目标服务器请求获取所述日历数据；

接收所述目标服务器返回的日历数据。

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

发起用于订阅第一消息的第七请求至所述第一服务器，以触发所述第一服务器向所述目标服务器订阅所述第一消息以及转达所述第一消息至所述第一应用；所述第一消息用于表示日历数据发生变化；

在所述接收所述目标服务器返回的登录成功消息之后，所述方法还包括：

接收所述第一服务器推送的所述第一消息；

所述向所述目标服务器请求获取所述日历数据，包括：

响应于所述第一消息，向所述目标服务器请求获取所述日历数据。

13.根据权利要求11或12所述的方法，其特征在于，

所述向所述目标服务器请求获取所述日历数据，包括：

发起用于获取第一URL的第八请求至所述目标服务器；所述第一URL用于描述所述目标服务器中所述身份信息对应的日历数据资源的位置；所述日历数据资源包括第一日历列表；所述第一日历列表包括多个日程类目，一个日程类目包括至少一个日程；

接收所述目标服务器返回的第一URL；

发起用于获取日历列表的第九请求至所述目标服务器，所述第九请求中携带所述第一URL；

所述接收所述目标服务器返回的日历数据，包括：

接收所述目标服务器返回的第一日历列表。

14.根据权利要求13所述的方法，其特征在于，所述接收所述目标服务器返回的日历列表之后，所述方法还包括：

比较所述第一日历列表和第二日历列表分别对应的日程类目，确定出不同的目标日程类目；第二日历列表为已存储于所述第一应用的日历列表；

在所述第二日历列表中新建所述目标日程类目。

15.根据权利要求11或12所述的方法，其特征在于，所述向所述目标服务器请求获取所述日历数据，包括：

确定发生变化的目标日程；

发起用于获取第二URL的第十请求至所述目标服务器；所述第二URL用于描述在所述目标服务器中，所述目标日程对应的日程数据资源位置；

接收所述目标服务器返回的所述第二URL；

发起用于获取所述目标日程对应的日程数据的第十一请求至所述目标服务器，所述第十一请求中携带所述第二URL；

所述接收所述目标服务器返回的日历数据，包括：

接收所述目标服务器返回的所述目标日程的日程数据。

16.一种日历数据同步系统，其特征在于，所述系统包括第一应用和第一服务器；

所述第一应用，用于执行以下操作：

显示第一界面，所述第一界面包括第二应用对应的第一控件；响应于针对所述第一控件的第一操作，从所述第一界面跳转到第二界面；所述第二界面为所述第二应用对应的授权界面；所述第二界面包括第二控件；

响应于针对所述第二控件的第二操作，发起请求至第一服务器以获取令牌；

基于所述令牌，获取用于登录目标服务器的身份信息；以及，基于所述身份信息，将所述日历数据同步到所述第一应用；所述目标服务器中存储有所述第二应用对应的日历数据；

所述第一服务器，用于执行以下操作：

响应于所述第一应用发起的请求，发起请求至鉴权服务器以获取令牌，以及接收所述鉴权服务器返回的令牌；所述鉴权服务器部署于所述第二应用对应的服务端；

将所述鉴权服务器返回的令牌发送至所述第一应用。

17.一种电子设备，其特征在于，所述电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述电子设备执行权利要求1至15任一项所述的方法。

18.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行权利要求1至15任一项所述的方法。

19.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行权利要求1至15任一项所述的方法。

Images