CN116954693A - 状态协同方法、装置、计算机设备及存储介质 - Google Patents

状态协同方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
CN116954693A
CN116954693A CN202310765029.8A CN202310765029A CN116954693A CN 116954693 A CN116954693 A CN 116954693A CN 202310765029 A CN202310765029 A CN 202310765029A CN 116954693 A CN116954693 A CN 116954693A
Authority
CN
China
Prior art keywords
state
application
information
condition
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310765029.8A
Other languages
English (en)
Inventor
吴岳廷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202310765029.8A priority Critical patent/CN116954693A/zh
Publication of CN116954693A publication Critical patent/CN116954693A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请实施例公开了一种状态协同方法、装置、计算机设备及存储介质,属于计算机技术领域。该方法包括:响应于将第一应用变更为第一状态的状态变更操作,通过第一应用,调用第二应用的状态查询程序,获取第二应用的状态信息;通过第一应用,向服务器发送状态变更请求,状态变更请求用于请求将第一应用变更为第一状态,状态变更请求携带第二应用的状态信息,服务器用于响应于状态变更请求,在第二应用的状态信息满足状态协同条件的情况下,返回验证成功消息;在接收到服务器返回的验证成功消息的情况下,控制第一应用变更为第一状态。本申请提供的方案,保证了状态信息的准确性和验证过程的可靠性,能够提高应用之间进行状态协同的安全性。

Description

状态协同方法、装置、计算机设备及存储介质
技术领域
本申请实施例涉及计算机技术领域,特别涉及一种状态协同方法、装置、计算机设备及存储介质。
背景技术
随着计算机技术的飞速发展,终端中安装的应用的种类也越来越丰富。其中,终端安装的不同应用之间可以具有依赖关系,例如通讯应用可以依赖于安全防护应用,由安全防护应用为通讯应用提供安全防护功能。
具有依赖关系的应用之间需要进行状态协同,相关技术中,不同应用之间通过调用接口来查询状态,由应用直接根据查询到的状态进行状态协同。但是,由于仅依靠应用之间的接口调用,而接口调用的过程极容易被干涉和破坏,因此状态协同的安全性较低。
发明内容
本申请实施例提供了一种状态协同方法、装置、计算机设备及存储介质,能够提高应用之间进行状态协同的安全性。所述技术方案如下:
一方面,提供了一种状态协同方法,由终端执行,所述终端安装有第一应用和第二应用,所述第一应用和所述第二应用之间具有依赖关系;所述方法包括:
响应于将所述第一应用变更为第一状态的状态变更操作,通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的状态信息;
通过所述第一应用,向服务器发送状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带所述第二应用的状态信息,所述服务器用于响应于所述状态变更请求,在所述第二应用的状态信息满足状态协同条件的情况下,返回验证成功消息,所述状态协同条件包括将所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
可选地,所述第一应用的应用信息满足所述第二应用的验证条件,包括以下至少一项:
所述第一应用的可执行文件位于目标目录下;
所述第一应用具备目标版权信息;
所述第一应用具备数字签名;
所述第一应用的哈希值命中预设列表中的哈希值。
可选地,所述第一状态是指启动状态,所述服务器用于响应于所述状态变更请求,在所述状态信息指示所述第二应用处于启动状态的情况下,返回所述验证成功消息;
所述在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态,包括:
在接收到所述验证成功消息的情况下,启动所述第一应用。
可选地,所述第一状态是指登录状态,所述服务器用于响应于所述状态变更请求,在所述状态信息指示所述第二应用处于登录状态的情况下,返回所述验证成功消息;
所述在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态,包括:
在接收到所述验证成功消息的情况下,控制所述第一应用进行登录。
可选地,所述在发送所述状态变更请求后的时长达到目标时长,但还未收到所述服务器返回的所述验证成功消息或者验证失败消息的情况下,控制所述第一应用变更为所述第一状态之后,所述方法还包括:
在接收到所述服务器返回的所述验证失败消息的情况下,将所述第一应用从所述第一状态恢复至状态变更前。
可选地,所述服务器包括第一服务器和第二服务器,所述第一服务器与所述第一应用关联,所述第二服务器与所述第二应用关联,所述通过所述第一应用,向服务器发送状态变更请求,包括:
通过所述第一应用,向所述第一服务器发送所述状态变更请求,所述第一服务器用于将所述状态变更请求转发给所述第二服务器,所述第二服务器用于响应于所述状态变更请求,在所述第二应用的状态信息满足所述状态协同条件的情况下,向所述第一服务器发送所述验证成功消息,所述第一服务器还用于将所述验证成功消息发送给所述终端;
所述在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态,包括:
在接收到所述第一服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
另一方面,提供了一种状态协同方法,由服务器执行,所述方法包括:
接收终端通过第一应用发送的状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带第二应用的状态信息;其中,所述终端安装有所述第一应用和所述第二应用,所述第一应用和所述第二应用之间具有依赖关系;
获取所述第一应用和所述第二应用之间的状态协同条件,所述状态协同条件包括所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
在所述第二应用的状态信息满足所述状态协同条件的情况下,向所述终端返回验证成功消息,所述终端用于在接收到所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
可选地,所述在所述第二应用的变化后的状态信息不满足所述状态协同条件的情况下,基于所述状态协同条件确定第二状态,包括:
周期性获取所述第二应用的状态信息,在获取到的状态信息不满足所述状态协同条件的情况下,基于所述状态协同条件确定所述第二状态;或者,
在所述第二应用进行状态变更后,获取所述第二应用的变化后的状态信息,在变化后的状态信息不满足所述状态协同条件的情况下,基于所述状态协同条件确定所述第二状态。
另一方面,提供了一种状态协同装置,设置于终端中,所述终端安装有第一应用和第二应用,所述第一应用和所述第二应用之间具有依赖关系;所述装置包括:
信息获取模块,用于响应于将所述第一应用变更为第一状态的状态变更操作,通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的状态信息;
请求发送模块,用于通过所述第一应用,向服务器发送状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带所述第二应用的状态信息,所述服务器用于响应于所述状态变更请求,在所述第二应用的状态信息满足状态协同条件的情况下,返回验证成功消息,所述状态协同条件包括将所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
状态变更模块,用于在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
可选地,所述状态信息包括多种状态子信息,所述状态查询程序包括多个,每个状态查询程序用于获取至少一种状态子信息;所述信息获取模块,用于:
通过所述第一应用,分别调用所述第二应用的多个状态查询程序,获取每个状态查询程序对应的状态子信息。
可选地,所述信息获取模块,用于:
通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的待处理信息;
按照预设算法,对所述待处理信息进行处理,得到所述状态信息。
可选地,所述状态信息包括登录信息,所述待处理信息包括路径信息和密码信息,所述预设算法为预设加密算法;
所述信息获取模块,用于:
在所述路径信息指示的存储路径中获取加密登录信息;
按照所述预设加密算法,采用所述密码信息对所述加密登录信息进行解密,得到所述登录信息。
可选地,所述状态信息包括设备标识,所述设备标识用于指示所述第二应用所在的终端,所述待处理信息包括所述第二应用所在的终端的硬盘信息、主板信息和设备属性信息中的至少一项,所述预设算法为预设转换算法;
所述信息获取模块,用于:
按照所述预设转换算法,对所述硬盘信息、所述主板信息和所述设备属性信息中的至少一项进行计算,得到所述设备标识。
可选地,所述信息获取模块,用于:
通过所述第一应用,调用所述第二应用的状态查询程序,以使所述状态查询程序在所述第一应用的应用信息满足所述第二应用的验证条件的情况下,返回所述第二应用的状态信息。
可选地,所述第一应用的应用信息满足所述第二应用的验证条件,包括以下至少一项:
所述第一应用的可执行文件位于目标目录下;
所述第一应用具备目标版权信息;
所述第一应用具备数字签名;
所述第一应用的哈希值命中预设列表中的哈希值。
可选地,所述第一状态是指启动状态,所述服务器用于响应于所述状态变更请求,在所述状态信息指示所述第二应用处于启动状态的情况下,返回所述验证成功消息;
所述状态变更模块,用于:
在接收到所述验证成功消息的情况下,启动所述第一应用。
可选地,所述第一状态是指登录状态,所述服务器用于响应于所述状态变更请求,在所述状态信息指示所述第二应用处于登录状态的情况下,返回所述验证成功消息;
所述状态变更模块,用于:
在接收到所述验证成功消息的情况下,控制所述第一应用进行登录。
可选地,所述状态变更模块,还用于:
在发送所述状态变更请求后的时长达到目标时长,但还未收到所述验证成功消息或者验证失败消息的情况下,控制所述第一应用变更为所述第一状态。
可选地,所述状态变更模块,还用于:
在接收到所述服务器返回的所述验证失败消息的情况下,将所述第一应用从所述第一状态恢复至状态变更前。
可选地,所述服务器包括第一服务器和第二服务器,所述第一服务器与所述第一应用关联,所述第二服务器与所述第二应用关联,所述请求发送模块,用于:
通过所述第一应用,向所述第一服务器发送所述状态变更请求,所述第一服务器用于将所述状态变更请求转发给所述第二服务器,所述第二服务器用于响应于所述状态变更请求,在所述第二应用的状态信息满足所述状态协同条件的情况下,向所述第一服务器发送所述验证成功消息,所述第一服务器还用于将所述验证成功消息发送给所述终端;
所述状态变更模块,用于:
在接收到所述第一服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
可选地,所述状态变更模块,还用于:
接收所述服务器发送的状态变更指令,所述状态变更指令用于指示将所述第一应用变更为第二状态;其中,所述状态变更指令是所述服务器在所述第二应用的状态发生变化后,所述第二应用的变化后的状态信息不满足所述状态协同条件时发送的,所述第二状态为所述第二应用处于变化后的状态信息指示的状态时,所述第一应用所需处于的状态;
控制所述第一应用变更为所述第二状态。
另一方面,提供了一种状态协同装置,设置于服务器中,所述装置包括:
请求接收模块,用于接收终端通过第一应用发送的状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带第二应用的状态信息;其中,所述终端安装有所述第一应用和所述第二应用,所述第一应用和所述第二应用之间具有依赖关系;
条件获取模块,用于获取所述第一应用和所述第二应用之间的状态协同条件,所述状态协同条件包括所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
消息发送模块,用于在所述第二应用的状态信息满足所述状态协同条件的情况下,向所述终端返回验证成功消息,所述终端用于在接收到所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
可选地,所述装置还包括指令发送模块,用于:
在所述第二应用的变化后的状态信息不满足所述状态协同条件的情况下,基于所述状态协同条件确定第二状态,所述第二状态为所述第二应用处于变化后的状态信息指示的状态时,所述第一应用所需处于的状态;
向所述终端发送状态变更指令,所述状态变更指令用于指示将所述第一应用变更为所述第二状态。
可选地,所述指令发送模块,用于:
周期性获取所述第二应用的状态信息,在获取到的状态信息不满足所述状态协同条件的情况下,基于所述状态协同条件确定所述第二状态;或者,
在所述第二应用进行状态变更后,获取所述第二应用的变化后的状态信息,在变化后的状态信息不满足所述状态协同条件的情况下,基于所述状态协同条件确定所述第二状态。
另一方面,提供了一种计算机设备,所述计算机设备包括处理器和存储器,所述存储器中存储有至少一条计算机程序,所述至少一条计算机程序由所述处理器加载并执行,以实现如上述方面所述的状态协同方法所执行的操作。
另一方面,提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有至少一条计算机程序,所述至少一条计算机程序由处理器加载并执行,以实现如上述方面所述的状态协同方法所执行的操作。
另一方面,提供了一种计算机程序产品,包括计算机程序,所述计算机程序由处理器加载并执行,以实现如上述方面所述的状态协同方法所执行的操作。
本申请实施例提供的方案,在第一应用和第二应用之间具有依赖关系的情况下,如果第一应用想要进行状态变更,则需要查询第二应用当前的状态。第一应用通过调用第二应用提供的状态查询程序,获取第二应用的状态信息,并将第二应用的状态信息提供给服务器,由服务器验证是否满足状态协同条件,在验证通过的情况下允许第一应用进行状态变更。首先通过调用状态查询程序获取状态信息,使得状态信息的获取过程不易被干涉和破坏,保证了状态信息的准确性。并且通过服务器对状态信息进行验证,使得状态信息的验证过程不易被干涉和破坏,保证了验证过程的可靠性,因此本申请提供的方案能够提高应用之间进行状态协同的安全性。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请实施例的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种实施环境的示意图;
图2是本申请实施例提供的一种状态协同方法的流程图;
图3是本申请实施例提供的一种应用之间的依赖关系的示意图;
图4是本申请实施例提供的另一种状态协同方法的流程图;
图5是本申请实施例提供的另一种状态协同方法的流程图;
图6是本申请实施例提供的另一种状态协同方法的流程图;
图7是本申请实施例提供的另一种状态协同方法的流程图;
图8是本申请实施例提供的另一种状态协同方法的流程图;
图9是本申请实施例提供的另一种状态协同方法的流程图;
图10是本申请实施例提供的另一种状态协同方法的流程图;
图11是本申请实施例提供的另一种状态协同方法的流程图;
图12是本申请实施例提供的一种应用界面的示意图;
图13是本申请实施例提供的另一种应用界面的示意图;
图14是本申请实施例提供的另一种应用界面的示意图;
图15是本申请实施例提供的一种资源访问方法的流程图;
图16是本申请实施例提供的另一种资源访问方法的流程图;
图17是本申请实施例提供的一种状态协同装置的结构示意图;
图18是本申请实施例提供的另一种状态协同装置的结构示意图;
图19是本申请实施例提供的另一种状态协同装置的结构示意图;
图20是本申请实施例提供的一种终端的结构示意图;
图21是本申请实施例提供的一种服务器的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
可以理解,本申请所使用的术语“第一”、“第二”等可在本文中用于描述各种概念,但除非特别说明,这些概念不受这些术语限制。这些术语仅用于将一个概念与另一个概念区分。举例来说,在不脱离本申请的范围的情况下,可以将第一应用称为第二应用,且类似地,可将第二应用称为第一应用。
其中,至少一个是指一个或者一个以上,例如,至少一个应用可以是一个应用、两个应用、三个应用等任一大于等于一的整数个应用。多个是指两个或者两个以上,例如,多个应用可以是两个应用、三个应用等任一大于等于二的整数个应用。每个是指至少一个中的每一个,例如,每个应用是指多个应用中的每一个应用,若多个应用为3个应用,则每个应用是指3个应用中的每一个应用。
可以理解的是,在本申请的实施方式中,涉及到应用信息以及状态信息等相关的数据,当本申请以上实施例运用到具体产品或技术中时,需要获得用户许可或者同意,且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
云技术(Cloud Technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术。云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成重要支撑。技术网络***的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。
云安全(Cloud Security)是指基于云计算商业模式应用的安全软件、硬件、用户、机构、安全云平台的总称。云安全融合了并行处理、网格计算、未知病毒行为判断等新兴技术和概念,通过网状的大量客户端对网络中软件行为的异常监测,获取互联网中木马、恶意程序的最新信息,并发送到服务端进行自动分析和处理,再把病毒和木马的解决方案分发到每一个客户端。
云安全主要研究方向包括:云计算安全,主要研究如何保障云自身及云上各种应用的安全,包括云计算机***安全、用户数据的安全存储与隔离、用户接入认证、信息传输安全、网络攻击防护、合规审计等;安全基础设施的云化,主要研究如何采用云计算新建与整合安全基础设施资源,优化安全防护机制,包括通过云计算技术构建超大规模安全事件、信息采集与处理平台,实现对海量信息的采集与关联分析,提升全网安全事件把控能力及风险控制能力;云安全服务,主要研究各种基于云计算平台为用户提供的安全服务,如防病毒服务等。
图1是本申请实施例提供的一种实施环境的示意图,参见图1,该实施环境包括:终端101、第一服务器102和第二服务器103。其中,终端101安装有第一应用和第二应用,第一应用和第二应用之间具有依赖关系。第一服务器102与第一应用关联,第二服务器103与第二应用关联。终端101与第一服务器102和第二服务器103两两之间通过有线或无线通信方式进行直接或间接地连接。
其中,当终端101中的第一应用需要进行状态变更时,第一应用调用第二应用提供的状态查询程序,获取第二应用的状态信息,并向第一服务器102发送携带该状态信息的状态变更请求,第一服务器102将该状态变更请求转发给第二服务器103,在第二服务器103确定该状态信息满足状态协同条件的情况下,向第一服务器102返回验证成功消息,由第一服务器将验证成功消息转发给终端,以使终端控制第一应用进行状态变更,从而实现第一应用与第二应用之间的状态协同。
在一种可能实现方式中,第一服务器102和第二服务器103可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式***,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network,内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端101可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载终端等,但并不局限于此。
图2是本申请实施例提供的一种状态协同方法的流程图,本申请实施例由终端执行,参见图2,该方法包括:
201、终端响应于将第一应用变更为第一状态的状态变更操作,通过第一应用,调用第二应用的状态查询程序,获取第二应用的状态信息。
终端安装有第一应用和第二应用,第一应用和第二应用之间具有依赖关系,例如第一应用依赖于第二应用,或者第一应用与第二应用之间相互依赖。其中,应用之间的依赖关系是指一个应用的运行依赖于另一个应用的运行,具有依赖关系的应用之间需要进行状态协同。两个应用之间进行状态协同是指一个应用处于某种状态时另一个应用需要处于特定的状态。
可选地,第一应用为业务应用,例如邮箱应用或者企业应用等,第二应用为具有安全防护能力的安全防护应用,业务应用需要安全防护应用提供的安全防护能力,在业务应用的运行过程中需要安全防护应用对业务应用进行安全防护,因此业务应用和安全防护应用之间需要进行状态协同,以保证在业务应用运行时安全防护应用也在运行。
本申请实施例中,第二应用向第一应用提供了状态查询程序的调用接口,该状态查询程序用于查询第二应用的状态信息,该状态信息用于指示第二应用当前所处的状态。因此,在第一应用需要进行状态变更时,终端通过该第一应用调用该状态查询程序,由状态查询程序将第二应用的状态信息返回给第一应用。
图3是本申请实施例提供的一种应用之间的依赖关系的示意图,如图3所示,终端安装有第一应用和第二应用,第一应用中加载了多个程序,第二应用中加载了多个程序,该多个程序用于与应用关联的服务器进行数据交互,以实现特定的业务功能,该第一应用和第二应用之间具有依赖关系,第一应用和第二应用之间需要进行状态协同,例如第一应用需要在启动或者登录时查询第二应用的状态信息。其中,第二应用的多个程序中包括状态查询程序,第一应用可通过调用该状态查询程序获取第二应用的状态信息。
202、终端通过第一应用,向服务器发送状态变更请求,状态变更请求用于请求将第一应用变更为第一状态,状态变更请求携带第二应用的状态信息。
终端通过第一应用获取到第二应用的状态信息后,生成状态变更请求,向服务器发送该状态变更请求。其中,服务器响应于该状态变更请求,在第二应用的状态信息满足状态协同条件的情况下,返回验证成功消息,状态协同条件包括将第一应用变更为第一状态时,第二应用的状态信息所需满足的条件。该验证成功消息用于表示允许将第一应用变更为第一状态。
其中,状态协同条件规定了在第一应用和第二应用中,其中一个应用处于某种状态时,另一个应用需要处于哪种状态。例如,状态协同条件规定了第一应用处于第一状态时,第二应用需要处于哪种状态,因此可以根据第二应用的状态信息判断该第二应用是否处于该状态协同条件所规定的状态,如果第二应用的状态信息指示的状态与状态协同条件所规定的状态一致,则该第二应用的状态信息满足状态协同条件,如果第二应用的状态信息指示的状态与状态协同条件所规定的状态不一致,则该第二应用的状态信息不满足状态协同条件。
203、终端在接收到服务器返回的验证成功消息的情况下,控制第一应用变更为第一状态。
终端在通过第一应用接收到验证成功消息的情况下,说明第二应用当前的状态正是第一应用处于第一状态时第二应用所需处于的状态,因此可以将第一应用变更为第一状态,则终端控制第一应用变更为第一状态,从而实现第一应用与第二应用之间的状态协同。
本申请实施例提供的方法,在第一应用和第二应用之间具有依赖关系的情况下,如果第一应用想要进行状态变更,则需要查询第二应用当前的状态。第一应用通过调用第二应用提供的状态查询程序,获取第二应用的状态信息,并将第二应用的状态信息提供给服务器,由服务器验证是否满足状态协同条件,在验证通过的情况下允许第一应用进行状态变更。首先通过调用状态查询程序获取状态信息,使得状态信息的获取过程不易被干涉和破坏,保证了状态信息的准确性。并且通过服务器对状态信息进行验证,使得状态信息的验证过程不易被干涉和破坏,保证了验证过程的可靠性,因此本申请提供的方案能够提高应用之间进行状态协同的安全性。
图4是本申请实施例提供的另一种状态协同方法的流程图,本申请实施例由服务器执行,参见图4,该方法包括:
401、服务器接收终端通过第一应用发送的状态变更请求,状态变更请求用于请求将第一应用变更为第一状态,状态变更请求携带第二应用的状态信息。
终端安装有第一应用和第二应用,第一应用和第二应用之间具有依赖关系,该状态变更请求的发送过程可参见上述图2所示的实施例。
402、服务器获取第一应用和第二应用之间的状态协同条件,状态协同条件包括第一应用变更为第一状态时,第二应用的状态信息所需满足的条件。
状态协同条件规定了在第一应用和第二应用中,其中一个应用处于某种状态时,另一个应用需要处于哪种状态。
403、服务器在第二应用的状态信息满足状态协同条件的情况下,向终端返回验证成功消息。
状态协同条件规定了第一应用处于第一状态时,第二应用需要处于哪种状态,因此服务器可以根据状态变更请求中携带的第二应用的状态信息判断该第二应用是否处于该状态协同条件所规定的状态,如果第二应用的状态信息指示的状态与状态协同条件所规定的状态一致,则该第二应用的状态信息满足状态协同条件,如果第二应用的状态信息指示的状态与状态协同条件所规定的状态不一致,则该第二应用的状态信息不满足状态协同条件。
其中,终端在接收到验证成功消息的情况下,控制第一应用变更为第一状态。
本申请实施例提供的方法,在第一应用和第二应用之间具有依赖关系的情况下,如果第一应用想要进行状态变更,则需要查询第二应用当前的状态。第一应用通过调用第二应用提供的状态查询程序,获取第二应用的状态信息,并将第二应用的状态信息提供给服务器,由服务器验证是否满足状态协同条件,在验证通过的情况下允许第一应用进行状态变更。首先通过调用状态查询程序获取状态信息,使得状态信息的获取过程不易被干涉和破坏,保证了状态信息的准确性。并且通过服务器对状态信息进行验证,使得状态信息的验证过程不易被干涉和破坏,保证了验证过程的可靠性,因此本申请提供的方案能够提高应用之间进行状态协同的安全性。
上述图2和图4所示的实施例分别说明了终端和服务器在状态协同方法中所执行的操作。其中,该服务器包括第一服务器和第二服务器,第一服务器与第一应用关联,第二服务器与第二应用关联,通过终端、第一服务器和第二服务器之间的交互,来实现第一应用和第二应用之间的状态协同,详细过程可参见下述图5所示的实施例。本申请实施例提供的方法应用于C/S模式(Client/Server,客户/服务器模式)的***架构下,在部署并维护服务器的同时,在终端安装与服务器关联的应用来连接服务器,终端中的第一应用与关联的第一服务器连接,第二应用与关联的第二服务器连接。
图5是本申请实施例提供的另一种状态协同方法的流程图,本申请实施例由终端、第一服务器和第二服务器执行,参见图5,该方法包括:
501、终端响应于将第一应用变更为第一状态的状态变更操作,通过第一应用,调用第二应用的状态查询程序,获取第二应用的状态信息。
第一服务器和第二服务器在第一应用和第二应用中配置有依赖关系,该依赖关系可以由具有特定格式的配置信息表示,该依赖关系指定了第一应用和第二应用在何种状态下需要进行状态协同。终端响应于将第一应用变更为第一状态的状态变更操作,通过该依赖关系判断是否需要查询第二应用的状态信息,如果需要查询第二应用的状态信息,则需要调用第二应用提供的状态查询程序获取第二应用的状态查询程序获取第二应用的状态信息。
其中,第二应用向第一应用提供状态查询程序的调用接口,第一应用调用该状态查询程序,状态查询程序接收特定格式的请求参数,并向第一应用返回第二应用的状态信息,该状态信息可用于指示第二应用与第一应用是否位于同一终端、第二应用是否处于启动状态、第二应用是否处于登录状态等。
其中,状态查询程序是指由多个文件组成的用于实现状态查询功能的集合,该状态查询程序可以以插件的形式存在。
在一种可能实现方式中,状态信息包括多种状态子信息,状态查询程序包括多个,每个状态查询程序用于获取至少一种状态子信息。则终端通过第一应用,分别调用第二应用的多个状态查询程序,获取每个状态查询程序对应的状态子信息。
例如,状态信息包括多种状态子信息,该多种状态子信息包括状态子信息1和状态子信息2,状态子信息1用于表示第二应用是否处于登录状态,状态子信息2为第二应用的登录信息。第二应用提供有状态查询程序A和状态查询程序B,状态查询程序A用于获取状态子信息1,状态查询程序B用于获取状态子信息2。则终端通过第一应用调用状态查询程序A获取状态子信息1,调用状态查询程序B获取状态子信息2,状态子信息1和状态子信息2组成第二应用的状态信息。
本申请实施例中,第一应用分别调用不同的状态查询程序获取不同类型的状态子信息,也即是将获取状态信息的过程分散给多个不同的状态查询程序进行处理,从而保证获取到的状态信息的可靠性和安全性。
在一种可能实现方式中,终端通过第一应用,调用第二应用的状态查询程序,获取第二应用的待处理信息,按照预设算法,对待处理信息进行处理,得到状态信息。
本申请实施例中,第二应用不直接向第一应用提供状态信息,而是提供待处理信息,第一应用需要按照与第二应用约定的预设算法,对该待处理信息进行处理,才能得到状态信息,因此即使该待处理信息被攻击者截获,攻击者也无法获取到第二应用的状态信息,相当于为状态信息提供了一道安全屏障,有利于保证获取到的状态信息的可靠性和安全性。
可选地,终端通过第一应用按照预设算法,对待处理信息进行处理,得到状态信息,包括以下两种情况。
第一种情况:状态信息包括登录信息,待处理信息包括路径信息和密码信息,预设算法为预设加密算法。该路径信息用于指示存储路径,该密码信息用于进行解密。则按照预设算法,对待处理信息进行处理,得到状态信息,包括:在路径信息指示的存储路径中获取加密登录信息,按照预设加密算法,采用密码信息对加密登录信息进行解密,得到登录信息。
其中,该路径信息包括加密登录信息的注册表路径或者本地文件路径。该密码信息包括解密所需的密码套件或者数值等。该预设加密算法可以为AEAD(AuthenticatedEncryption with Associated Data,关联数据的认证加密)算法。例如该预设加密算法为AES(Advanced Encryption Standard,高级加密标准)的GCM(Grinding Cycle Monitor,研磨周期监测仪)模式,解密时需要计数器的初始值以及身份验证标签值。
第二种情况:状态信息包括设备标识,设备标识用于指示第二应用所在的终端,待处理信息包括第二应用所在的终端的硬盘信息、主板信息和设备属性信息中的至少一项,预设算法为预设转换算法。则按照预设算法,对待处理信息进行处理,得到状态信息,包括:按照预设转换算法,对硬盘信息、主板信息和设备属性信息中的至少一项进行计算,得到设备标识。
其中,终端的硬盘信息包括***盘的硬盘序列号和其他类型磁盘的硬盘序列号等,其他类型磁盘包括移动硬盘、USB(Universal Serial Bus,通用串行总线)和光驱等。主板信息包括主板序列号和主板UUID(Universally Unique Identifier,通用唯一识别码)。设备属性信息包括设备资产号和设备类型信息等,设备类型信息用于指示设备属于虚拟机还是实体机以及属于哪种类型虚拟机。
终端通过第一应用获取到硬盘信息、主板信息和设备属性信息中的至少一项后,按照与第二应用约定的预设转换算法,对硬盘信息、主板信息和设备属性信息中的至少一项进行计算,得到计算结果,该计算结果即为设备标识。
在一种可能实现方式中,终端通过第一应用,调用第二应用的状态查询程序,以使状态查询程序在第一应用的应用信息满足第二应用的验证条件的情况下,返回第二应用的状态信息。
本申请实施例中,第一应用在调用状态查询程序获取第二应用的状态信息时,状态查询程序需要验证该第一应用的应用信息是否满足验证条件,在满足验证条件的情况下,才向第一应用返回第二应用的状态信息,如果第一应用的应用信息不满足验证条件,则状态查询程序向第一应用返回调用失败消息,以保证状态信息不被泄露,提高了状态信息的安全性。
可选地,第一应用的应用信息满足第二应用的验证条件,包括以下至少一项:
(1)第一应用的可执行文件位于目标目录下。
(2)第一应用具备目标版权信息。
(3)第一应用具备数字签名。
(4)第一应用的哈希值命中预设列表中的哈希值。
如果第一应用与第二应用之间规定在满足以上全部验证条件时才验证成功,则在第一应用的应用信息满足上述全部验证条件的情况下,状态查询程序向第一应用返回第二应用的状态信息。如果第一应用与第二应用之间规定在满足以至少一条验证条件时就验证成功,则第一应用的应用信息只要满足上述验证条件中的至少一条,状态查询程序就向第一应用返回第二应用的状态信息。
可选地,上述验证条件不是预埋在第二应用的可执行文件或模块文件中,而是存储在加密的持久化库中,如果第一应用依赖于第二应用时,由第二应用的服务器下发针对第一应用的验证条件到第二应用,并存储在持久化库中。如果服务器要求删除针对第一应用的验证条件,则通知第二应用执行对验证条件的删除操作。本申请实施例中,通过服务器下发验证条件,并将验证条件存储于持久化库中,可以提升状态查询程序调用的安全性,并且便于对验证条件进行调整。
其中,持久化是指将内存中的数据结构或对象模型转换为关系模型、XML、JSON、二进制流等格式,以及将存储模型转换为内存中的数据模型的统称,持久化库就是存储在设备本地的磁盘文件或数据文件中的由内存中数据结构或对象模型转换而来的关系模型、XML、JSON、二进制流等内容的存储介质,可以使用加密文件,嵌入型数据库等实现。例如,持久化库包括白盒加密持久化库,白盒密码技术是一项能够抵抗白盒攻击的密码技术,白盒密码技术从实现方式上可以分为静态密钥白盒和动态密钥白盒。静态密钥白盒是指将算法的密钥和指定的加密算法绑定混淆,从而生成静态密钥白盒。
需要说明的是,上述多种实现方式之间可以相互结合,形成一种新的实现方式,本申请实施例对此不做限定。
本申请实施例中,第二应用通过向第一应用提供状态查询程序,实现了第一应用与第二应用之间的相互结构,避免第一应用和第二应用的依赖关系发生变化时两者需要同步进行更新的问题。
502、终端通过第一应用,向第一服务器发送状态变更请求,状态变更请求用于请求将第一应用变更为第一状态,状态变更请求携带第二应用的状态信息。
终端通过第一应用获取到第二应用的状态信息后,生成状态变更请求,通过第一应用向该第一应用关联的第一服务器发送该状态变更请求,该第一服务器用于为第一应用提供服务。
503、第一服务器将状态变更请求转发给第二服务器。
第一服务器与第二服务器之间建立有通信连接,第一服务器在接收到终端通过第一应用发送的状态变更请求后,将该状态变更请求转发给第二应用关联的第二服务器,该第二服务器用于为第二应用提供服务。
504、第二服务器响应于状态变更请求,在第二应用的状态信息满足状态协同条件的情况下,向第一服务器发送验证成功消息。
第二服务器接收到第一服务器发送的状态变更请求后,获取该状态变更请求中携带的第二应用的状态信息,并获取第一应用和第二应用之间的状态协同条件,该状态协同条件包括第一应用变更为第一状态时,第二应用的状态信息所需满足的条件。第二服务器判断该第二应用的状态信息是否满足状态协同条件,在第二应用的状态信息满足状态协同条件的情况下,向第一服务器发送验证成功消息,该验证成功消息用于表示允许将第一应用变更为第一状态。在另一实施例中,在第二应用的状态信息不满足状态协同条件的情况下,向第一服务器发送验证失败消息,该验证失败消息用于表示不允许将第一应用变更为第一状态。
其中,状态协同条件规定了在第一应用和第二应用中,其中一个应用处于某种状态时,另一个应用需要处于哪种状态。例如,状态协同条件规定了第一应用处于第一状态时,第二应用需要处于哪种状态,因此可以根据第二应用的状态信息判断该第二应用是否处于该状态协同条件所规定的状态,如果第二应用的状态信息指示的状态与状态协同条件所规定的状态一致,则该第二应用的状态信息满足状态协同条件,因此允许第一应用变更为第一状态。如果第二应用的状态信息指示的状态与状态协同条件所规定的状态不一致,则该第二应用的状态信息不满足状态协同条件,因此不允许第一应用变更为第一状态。
在一种可能实现方式中,第一状态是指启动状态,第一服务器响应于状态变更请求,在状态信息指示第二应用处于启动状态的情况下,返回验证成功消息。
状态协同条件规定了第一应用处于启动状态时,第二应用也需要处于启动状态。则第一服务器基于状态信息判断第二应用是否处于启动状态,如果第二应用处于启动状态,则可以确定满足状态协同条件,因此返回验证成功消息,允许第一应用变更为启动状态。如果第二应用未处于启动状态,则可以确定不满足状态协同条件,因此返回验证失败消息,不允许第一应用变更为启动状态。
在另一种可能实现方式中,第一状态是指登录状态,第一服务器响应于状态变更请求,在状态信息指示第二应用处于登录状态的情况下,返回验证成功消息。
状态协同条件规定了第一应用处于登录状态时,第二应用也需要处于登录状态。则第一服务器基于状态信息判断第二应用是否处于登录状态,如果第二应用处于登录状态,则可以确定满足状态协同条件,因此返回验证成功消息,允许第一应用变更为登录状态。如果第二应用未处于登录状态,则可以确定不满足状态协同条件,因此返回验证失败消息,不允许第一应用变更为登录状态。
需要说明的是,上述两种实现方式中,状态协同条件规定第一应用处于启动状态时,第二应用也需要处于启动状态,以及第一应用处于登录状态时,第二应用也需要处于登录状态。但这仅仅是对状态协同条件的两种示例性说明,除此之外,该状态协同条件还可以为其他规定,例如状态协同条件还可以规定第一应用处于启动状态时,第二应用需要处于登录状态等,本申请实施例对此不做限定。
505、第一服务器将验证成功消息发送给终端。
第一服务器接收到验证成功消息后,将验证成功消息转发给终端。
506、终端在接收到第一服务器返回的验证成功消息的情况下,控制第一应用变更为第一状态。
终端在通过第一应用接收到验证成功消息的情况下,说明第二应用当前的状态正是第一应用处于第一状态时第二应用所需处于的状态,因此可以将第一应用变更为第一状态,则终端控制第一应用变更为第一状态,从而实现第一应用与第二应用之间的状态协同。
在一种可能实现方式中,第一状态是指启动状态,则终端在接收到验证成功消息的情况下,启动第一应用。
在另一种可能实现方式中,第一状态是指登录状态,则终端在接收到验证成功消息的情况下,控制第一应用进行登录。
需要说明的是,本申请实施例中以服务器包括第一服务器和第二服务器为例进行说明。在另一实施例中,该第一服务器和第二服务器为同一个服务器,则终端通过第一应用,向服务器发送状态变更请求,服务器响应于状态变更请求,在第二应用的状态信息满足状态协同条件的情况下,向终端发送验证成功消息。
本申请实施例提供的方法,在第一应用和第二应用之间具有依赖关系的情况下,如果第一应用想要进行状态变更,则需要查询第二应用当前的状态。第一应用通过调用第二应用提供的状态查询程序,获取第二应用的状态信息,并将第二应用的状态信息提供给服务器,由服务器验证是否满足状态协同条件,在验证通过的情况下允许第一应用进行状态变更。首先通过调用状态查询程序获取状态信息,使得状态信息的获取过程不易被干涉和破坏,保证了状态信息的准确性。并且通过服务器对状态信息进行验证,使得状态信息的验证过程不易被干涉和破坏,保证了验证过程的可靠性,因此本申请提供的方案能够提高应用之间进行状态协同的安全性。
需要说明的是,上述实施例以终端接收到验证成功消息为例进行说明。在另一实施例中,终端通过第一应用,向服务器发送状态变更请求之后,在发送状态变更请求后的时长达到目标时长,但还未收到验证成功消息或者验证失败消息的情况下,控制第一应用变更为第一状态。在控制第一应用变更为第一状态后,在接收到服务器返回的验证失败消息的情况下,将第一应用从第一状态恢复至状态变更前。
本申请实施例中,如果在发送状态变更请求后达到一定时长还没有接收到服务器返回的消息,说明存在响应延时,这种情况下可以先控制第一应用进行状态变更,并继续等待服务器的消息。与此同时,服务器进行异步重试操作,直至终端接收到验证成功消息或验证失败消息,如果终端接收到了验证成功消息,则继续保持第一应用处于第一状态即可,如果终端接收到了验证失败消息,则需要将第一应用从第一状态恢复至状态变更前。
上述实施例说明了第一应用在需要进行状态变更时,主动获取第二应用的状态信息进行验证的过程。除此之外,还可以基于第二应用的状态信息,来对第一应用进行状态变更,以保证状态协同,详细过程参见下述图6所示的实施例。
图6是本申请实施例提供的另一种状态协同方法的流程图,本申请实施例由终端和服务器执行,参见图6,该方法包括:
601、服务器在第二应用的变化后的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态,第二状态为第二应用处于变化后的状态信息指示的状态时,第一应用所需处于的状态。
服务器在获取到第二应用的状态信息后,判断第二应用的状态信息是否满足状态协同条件,如果不满足状态协同条件,则需要基于状态协同条件,确定第二应用处于变化后的状态信息指示的状态时,第一应用所需处于的第二状态。
在一种可能实现方式中,服务器周期性获取第二应用的状态信息,在获取到的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态。在另一种可能实现方式中,服务器在第二应用进行状态变更后,获取第二应用的变化后的状态信息,在变化后的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态。以上两种实现方式的详细过程可分别参见下述图7和图8所示的实施例。
602、服务器向终端发送状态变更指令,状态变更指令用于指示将第一应用变更为第二状态。
服务器生成状态变更指令,该状态变更指令用于指示将第一应用变更为第二状态。服务器向终端中的第一应用发送该状态变更指令。
603、终端接收服务器发送的状态变更指令,控制第一应用变更为第二状态。
终端接收到状态变更指令后,按照该状态变更指令的指示,控制第一应用变更为第二状态。第一应用变更为第二状态后,该第一应用的状态和第二应用的状态满足状态协同条件,从而实现了第一应用与第二应用之间的状态协同。
本申请实施例提供的方法,在第一应用和第二应用之间具有依赖关系的情况下,如果服务器检测到第一应用的状态和第二应用的状态不满足状态协同条件了,则可以发送状态变更指令指示第一应用进行状态变更,以使第一应用的状态和第二应用的状态满足状态协同条件,保证第一应用和第二应用之间的状态协同,避免由于第一应用的状态未及时按照第二应用的状态进行变更,导致第一应用的业务处理过程出错的情况。
图7是本申请实施例提供的另一种状态协同方法的流程图,本申请实施例由终端、第一服务器和第二服务器执行,参见图7,该方法包括:
701、第二服务器在第二应用进行状态变更后,获取第二应用的变化后的状态信息。
第二应用的状态包括启动状态、未启动状态、登录状态、未登录状态、安装状态以及卸载状态等。第二应用的状态变更包括两种情况,一种情况通过第二服务器对第二应用执行状态变更,例如管理员通过第二服务器将终端上的第二应用执行退出登录操作等。另一种情况是第二应用主动发起状态变更,例如用户在终端中执行对第二应用的退出登录操作等。
针对第一种情况,由于是通过第二服务器对第二应用执行状态变更,因此第二服务器可感知到第二应用的状态变更。针对第二种情况,第二应用发送状态变更后,会将变更后的状态信息同步至第二服务器,因此第二服务器也可以感知到第二应用的状态变更。每当服务器确定第二应用的状态发送变化,则获取第二应用的变化后的状态信息。
702、第二服务器向第一服务器发送第二应用的变化后的状态信息。
703、第一服务器接收第二应用的变化后的状态信息,在变化后的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态。
第一服务器在接收到第二应用的状态信息后,判断第二应用的状态信息是否满足状态协同条件,如果不满足状态协同条件,则需要基于状态协同条件,确定第二应用处于变化后的状态信息指示的状态时,第一应用所需处于的第二状态。也即是,当检测到第一应用的状态与第二应用的状态不满足状态协同条件时,需要确定第一应用需要处于何种状态。
第一服务器按照状态协同条件,可知当第二应用进行状态变更后,第一应用是否需要进行状态变更以及进行何种状态变更。例如,在第一应用处于登录状态的情况下,当第二应用的状态变更为卸载状态时,第一应用需要退出登录状态。
704、第一服务器向终端发送状态变更指令,状态变更指令用于指示将第一应用变更为第二状态。
第一服务器生成状态变更指令,该状态变更指令用于指示将第一应用变更为第二状态。服务器向终端中的第一应用发送该状态变更指令。
705、终端接收服务器发送的状态变更指令,控制第一应用变更为第二状态。
终端接收到状态变更指令后,按照该状态变更指令的指示,控制第一应用变更为第二状态。第一应用变更为第二状态后,该第一应用的状态和第二应用的状态满足状态协同条件,从而实现了第一应用与第二应用之间的状态协同。
本申请实施例提供的方法,,在第一应用和第二应用之间具有依赖关系的情况下,如果服务器检测到第一应用的状态和第二应用的状态不满足状态协同条件了,则可以发送状态变更指令指示第一应用进行状态变更,以使第一应用的状态和第二应用的状态满足状态协同条件,保证第一应用和第二应用之间的状态协同,避免由于第一应用的状态未及时按照第二应用的状态进行变更,导致第一应用的业务处理过程出错的情况。
图8是本申请实施例提供的另一种状态协同方法的流程图,本申请实施例由终端和服务器执行,参见图8,该方法包括:
801、第一服务器周期性向第二服务器发送状态查询请求,状态查询请求用于请求查询第二应用的状态信息。
第二应用在进行状态变更时,会将变更后的状态信息同步至第二服务器,但是存在同步失败的情况,导致第二服务器无法感知到第二应用的状态变更。或者,由于非预设的方式改变第二应用的状态时(例如攻击者非正常执行卸载第二应用的操作),第二服务器也无法感知到第二应用的状态变更。基于此,考虑到存在第二服务器无法感知到第二应用的状态变更的情况,因此第一服务器可以周期性向第二服务器发送状态查询请求,来查询第二应用的状态信息,并判断是否满足状态协同条件。
802、第二服务器响应于状态查询请求,获取第二应用的状态信息。
第二服务器响应于第一服务器发送的状态查询请求,获取第二应用当前的状态信息。
803、第二服务器向第一服务器发送第二应用的状态信息。
804、第一服务器接收第二应用的状态信息,在第二应用的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态。
第一服务器在接收到第二应用的状态信息后,判断第二应用的状态信息是否满足状态协同条件,如果不满足状态协同条件,则需要基于状态协同条件,确定第二应用处于变化后的状态信息指示的状态时,第一应用所需处于的第二状态。也即是,当检测到第一应用的状态与第二应用的状态不满足状态协同条件时,需要确定第一应用需要处于何种状态。
第一服务器按照状态协同条件,可知当第二应用进行状态变更后,第一应用是否需要进行状态变更以及进行何种状态变更。例如,在第一应用处于登录状态的情况下,当第二应用的状态变更为卸载状态时,第一应用需要退出登录状态。
805、第一服务器向终端发送状态变更指令,状态变更指令用于指示将第一应用变更为第二状态。
第一服务器生成状态变更指令,该状态变更指令用于指示将第一应用变更为第二状态。服务器向终端中的第一应用发送该状态变更指令。
806、终端接收服务器发送的状态变更指令,控制第一应用变更为第二状态。
终端接收到状态变更指令后,按照该状态变更指令的指示,控制第一应用变更为第二状态。第一应用变更为第二状态后,该第一应用的状态和第二应用的状态满足状态协同条件,从而实现了第一应用与第二应用之间的状态协同。
本申请实施例提供的方法,,在第一应用和第二应用之间具有依赖关系的情况下,如果服务器检测到第一应用的状态和第二应用的状态不满足状态协同条件了,则可以发送状态变更指令指示第一应用进行状态变更,以使第一应用的状态和第二应用的状态满足状态协同条件,保证第一应用和第二应用之间的状态协同,避免由于第一应用的状态未及时按照第二应用的状态进行变更,导致第一应用的业务处理过程出错的情况。
并且,考虑到存在第二服务器无法感知到第二应用的状态变更的情况,因此第一服务器可以周期性向第二服务器发送状态查询请求,来查询第二应用的状态信息,并判断是否满足状态协同条件,也即是提供了一种兜底措施,避免由于在第二服务器无法感知到第二应用的状态变更,导致难以对第一应用和第二应用进行状态协同的情况。
在相关技术中,在第一应用与第二应用之间存在依赖关系的情况下,第一应用需要在启动、登录或运行时与同一终端内的第二应用进行状态协同,在第二应用的状态发生变更后,同步地对第一应用执行包括强制退登、禁止运行或禁止登录等相应操作。第一应用与第二应用之间通过调用接口来查询状态,由应用直接根据查询到的状态进行状态协同。如果第一应用和第二应用之间的依赖关系发生变化,则需要对第一应用和第二应用同步进行版本更新,否则难以维护二者动态变化的依赖关系,不仅费时费力,而且接口调用的过程极容易被干涉和破坏,因此状态协同的安全性较低,易引起数据泄露。
而本申请实施例提供的状态协同方法是应用与服务器之间闭环完成的,通过应用与服务器之间的交互完成状态上报,通过服务器之间的交互完成状态查询与应用间的状态协同,应用之间的依赖关系由服务器进行配置,当应用之间的依赖关系发生变化时,调整成本较小。并且,通过调用状态查询程序和维护验证条件来实现状态信息的查询操作,可以将具有依赖关系的应用互相解耦,从而避免依赖关系发生变化时需要同步更新两个应用。另一方面,通过服务器进行状态同步,可以在一定程度上降低攻击者绕过应用间依赖关系的几率,从而降低数据泄露的风险。
图9是本申请实施例提供的另一种状态协同方法的流程图,如图9所示,终端安装有第一应用和第二应用,第一应用与第一服务器关联,第二应用与第二服务器关联,第一应用依赖于第二应用。该方法包括以下步骤:
901、第一应用调用状态查询程序采集第二应用的状态信息。当第一应用需要执行启动或登录等业务逻辑时,首先查询与第二应用之间的依赖关系,在依赖关系指示需要对第二应用的状态信息进行验证的情况下,第一应用调用第二应用提供的状态查询程序采集第二应用的状态信息。
902、第一应用执行状态变更的业务逻辑。第一应用获取到第二应用的状态信息后,生成携带该第二应用的状态信息的状态变更请求,该状态变更请求用于请求进行状态变更(例如变更为启动状态或登录状态等),第一应用将状态变更请求发送给第一服务器。
903、第一服务器向第二服务器发送状态变更请求。
904、第二服务器向第一服务器发送验证成功消息。第二服务器接收到状态变更请求后,验证第二应用的状态信息是否满足状态协同条件,如果满足,则返回验证成功消息。
905、第一服务器控制第一应用进行状态变更。第一服务器在接收到第二服务器的验证成功消息的情况下,控制第一应用进行状态变更。
图10是本申请实施例提供的另一种状态协同方法的流程图,如图10所示,该方法包括以下步骤:
1001、若第二应用发生状态变更,则通知第二服务器。第二应用发生状态变更后,会将变更后的状态信息同步给第二服务器。
1002、第二服务器主动发送状态信息。第二服务器接收到第二应用的状态信息后,主动将该状态信息发送给第一服务器。
1003、第一服务器控制第一应用进行状态变更。第一服务器在接收到第二应用的状态信息后,如果该状态信息不满足状态协同条件,则需要对第一应用进行状态变更。第一服务器通过与第一应用之间的指令交互,控制第一应用进行状态变更,从而实现第一应用与第二应用之间的状态协同。
1004、第一服务器周期性请求状态信息。为了适配第二服务器无法感知第二应用的状态变更的情况,第一服务器还向第二服务器周期性请求状态信息,并根据第二服务器提供的状态信息判断是否满足状态协同条件,如果满足,则无需对第一应用进行处理,如果不满足,则需要对第一应用进行状态变更,以实现第一应用与第二应用之间的状态协同。
需要说明的一点是,上述实施例仅以终端中的第一应用和第二应用具有依赖关系为例进行说明。在另一实施例中,终端还可以安装有多个应用,该多个应用之间具有多对依赖关系,因此可以形成多对一的依赖关系(多个应用依赖于同一应用)或者多对多的依赖关系(多个应用之间两两具有依赖关系)。针对每对具有依赖关系的应用,均执行上述实施例所提供的状态协同方法。
图11是本申请实施例提供的另一种状态协同方法的流程图,如图11所示,终端安装有第一应用、第二应用、第三应用和第四应用,第一应用和第二应用具有依赖关系,第三应用和第二应用具有依赖关系,第四应用和第二应用具有依赖关系,这三个依赖关系可以各不相同,在服务器的控制节点中进行配置。
另外,针对同时存在多对依赖关系的情况,终端还需要处理各个依赖关系是否存在冲突的问题。因此,可以对不同的依赖关系划分不同的优先级,在不同的依赖关系之间存在冲突的情况下,优先满足优先级最高的依赖关系对应的状态协同条件。
本申请实施例提供的状态协同方法,可应用于对于任意具有依赖关系的应用之间进行状态协同的场景中。
例如,本申请实施例可适用于属于C/S模式的应用之间的依赖关系处置场景下。C/S模式下分为应用端与服务器端。应用端可以访问自身的服务器端。由于安全合规制度的规定,部分应用在启动、登录或运行时需要依赖于设备内另一应用的状态。举例而言,包括以下场景:(1)第一应用在自身账号体系内验证用户发起的登录操作时,除了验证账号的凭证是否正确外,还需要检测设备内是否安装有第二应用,或者第二应用是否处于登录状态。(2)第一应用在处于登录状态的情况下,如果设备内的第二应用被卸载,或者第二应用的服务和进程完全退出,第一应用需要强制退登。
本申请实施例中,第一应用依赖于第二应用,第一应用为业务应用,例如邮箱应用或者企业应用等,第二应用为具有安全防护能力的安全防护应用,业务应用需要安全防护应用提供的安全防护能力,在业务应用的运行过程中需要安全防护应用对业务应用进行安全防护,因此业务应用和安全防护应用之间需要进行状态协同,以保证在业务应用运行时安全防护应用也在运行。其中,该第二应用可以为零信任访问控制***中的安全防护应用。以下结合图12-图16对零信任访问控制***中的安全防护应用进行介绍。
图12是本申请实施例提供的一种应用界面的示意图,如图12所示,安全防护应用具备零信任办公、病毒查杀、合规检测、漏洞修复以及电脑工具等多种功能,在安全实施防护方面,提供有实时防护策略、杀毒防护策略和安全加固策略,实时防护策略包括应用入口防护和***底层防护。图13是本申请实施例提供的另一种应用界面的示意图,如图13所示,安全防护应用在用户主动发起或后台发起检测操作后,周期地执行设备环境状态的检测,在业务模块层面,包括软件安全基线检测、违规进程检测和违规服务检测等。图14是本申请实施例提供的另一种应用界面的示意图,如图14所示,如果安全防护应用对设备环境状态的检测未通过,则安全防护应用自动执行包括强制退登、阻断企业内网资源访问、阻断业务模块的业务功能调用、将设备网络转入隔离网等处置措施。
图15是本申请实施例提供的一种资源访问方法的流程图,如图15所示,零信任访问控制***包括安全防护应用,访问主体为用户,访问主体向零信任访问控制***请求统一访问入口,零信任访问控制***基于访问控制策略为统一访问入口提供流量监测和鉴权,通过流量监测和鉴权的网络流量由零信任访问控制***转发至访问网关,通过访问网关将针对企业内部资源的访问请求转发至对应的业务服务器,完成访问过程。
图16是本申请实施例提供的另一种资源访问方法的流程图,如图16所示,零信任访问控制***包括安全防护应用、安全防护服务器、访问代理和智能网关。安全防护应用与访问代理均安装在终端上,并且访问代理是安全防护应用的组件,图16中仅是为了在逻辑流程上进行区分,将访问代理和安全防护应用进行了拆分。其中,访问代理通过TUN/TAP虚拟网卡拦截网络请求,通过安全防护应用鉴权后将网络请求转发给智能网关,如果没有通过鉴权则进行直连或中断连接。安全防护应用负责验证设备的身份,验证设备是否可信以及业务应用是否可信。安全防护服务器通过动态访问策略对网络请求进行安全调度,对用户身份、设备硬件信息和设备安全状态进行验证,以及检测应用进程是否安全等。安全防护服务器还定期向云查服务定期发起文件送检,在识别出恶意进程的情况下通知安全防护应用执行异步阻断操作。智能网关负责每一个网络请求的验证、授权和转发。
在图16所示的架构的基础上,资源访问流程包括:步骤1、业务应用发起针对访问客体的网络请求,安全防护应用通过访问代理拦截网络请求;步骤2、访问代理向安全防护应用发起鉴权请求,即安全防护应用申请网络请求的访问凭证;步骤3、安全防护应用获取业务应用的进程特征,进行流量鉴权的请求参数包括该业务应用的进程特征;步骤4、安全防护应用基于访问代理执行流量鉴权时的请求参数,向安全防护服务器申请访问票据;步骤5、安全防护服务器返回访问票据;步骤6、安全防护应用将访问票据、访问票据的最大使用次数及有效时间作为响应数据发送给访问代理;步骤7、访问代理向智能网关发起连接请求,连接请求携带访问票据;步骤8、智能网关收到连接请求后,解析出访问票据,向安全防护服务器发起访问票据的校验请求;步骤9、安全防护服务器对访问票据进行校验,在校验成功的情况下返回校验成功消息,智能网关在接收到校验成功消息后,建立访问代理与智能网关之间的连接,访问代理将网络请求转发给智能网关;步骤10、智能网关将网络请求转发至业务应用关联的业务服务器;步骤11、业务服务器将对网络请求的响应数据发送给智能网络;步骤12、智能网关将响应数据转发给访问代理。
图17是本申请实施例提供的一种状态协同装置的结构示意图,该状态协同装置设置于终端中,终端安装有第一应用和第二应用,第一应用和第二应用之间具有依赖关系。参见图17,该装置包括:
信息获取模块1701,用于响应于将第一应用变更为第一状态的状态变更操作,通过第一应用,调用第二应用的状态查询程序,获取第二应用的状态信息;
请求发送模块1702,用于通过第一应用,向服务器发送状态变更请求,状态变更请求用于请求将第一应用变更为第一状态,状态变更请求携带第二应用的状态信息,服务器用于响应于状态变更请求,在第二应用的状态信息满足状态协同条件的情况下,返回验证成功消息,状态协同条件包括将第一应用变更为第一状态时,第二应用的状态信息所需满足的条件;
状态变更模块1703,用于在接收到服务器返回的验证成功消息的情况下,控制第一应用变更为第一状态。
本申请实施例提供的状态协同装置,在第一应用和第二应用之间具有依赖关系的情况下,如果第一应用想要进行状态变更,则需要查询第二应用当前的状态。第一应用通过调用第二应用提供的状态查询程序,获取第二应用的状态信息,并将第二应用的状态信息提供给服务器,由服务器验证是否满足状态协同条件,在验证通过的情况下允许第一应用进行状态变更。首先通过调用状态查询程序获取状态信息,使得状态信息的获取过程不易被干涉和破坏,保证了状态信息的准确性。并且通过服务器对状态信息进行验证,使得状态信息的验证过程不易被干涉和破坏,保证了验证过程的可靠性,因此本申请提供的方案能够提高应用之间进行状态协同的安全性。
可选地,状态信息包括多种状态子信息,状态查询程序包括多个,每个状态查询程序用于获取至少一种状态子信息;信息获取模块1701,用于:
通过第一应用,分别调用第二应用的多个状态查询程序,获取每个状态查询程序对应的状态子信息。
可选地,信息获取模块1701,用于:
通过第一应用,调用第二应用的状态查询程序,获取第二应用的待处理信息;
按照预设算法,对待处理信息进行处理,得到状态信息。
可选地,状态信息包括登录信息,待处理信息包括路径信息和密码信息,预设算法为预设加密算法;
信息获取模块1701,用于:
在路径信息指示的存储路径中获取加密登录信息;
按照预设加密算法,采用密码信息对加密登录信息进行解密,得到登录信息。
可选地,状态信息包括设备标识,设备标识用于指示第二应用所在的终端,待处理信息包括第二应用所在的终端的硬盘信息、主板信息和设备属性信息中的至少一项,预设算法为预设转换算法;
信息获取模块1701,用于:
按照预设转换算法,对硬盘信息、主板信息和设备属性信息中的至少一项进行计算,得到设备标识。
可选地,信息获取模块1701,用于:
通过第一应用,调用第二应用的状态查询程序,以使状态查询程序在第一应用的应用信息满足第二应用的验证条件的情况下,返回第二应用的状态信息。
可选地,第一应用的应用信息满足第二应用的验证条件,包括以下至少一项:
第一应用的可执行文件位于目标目录下;
第一应用具备目标版权信息;
第一应用具备数字签名;
第一应用的哈希值命中预设列表中的哈希值。
可选地,第一状态是指启动状态,服务器用于响应于状态变更请求,在状态信息指示第二应用处于启动状态的情况下,返回验证成功消息;
状态变更模块1703,用于:
在接收到验证成功消息的情况下,启动第一应用。
可选地,第一状态是指登录状态,服务器用于响应于状态变更请求,在状态信息指示第二应用处于登录状态的情况下,返回验证成功消息;
状态变更模块1703,用于:
在接收到验证成功消息的情况下,控制第一应用进行登录。
可选地,状态变更模块1703,还用于:
在发送状态变更请求后的时长达到目标时长,但还未收到验证成功消息或者验证失败消息的情况下,控制第一应用变更为第一状态。
可选地,状态变更模块1703,还用于:
在接收到服务器返回的验证失败消息的情况下,将第一应用从第一状态恢复至状态变更前。
可选地,服务器包括第一服务器和第二服务器,第一服务器与第一应用关联,第二服务器与第二应用关联,请求发送模块1702,用于:
通过第一应用,向第一服务器发送状态变更请求,第一服务器用于将状态变更请求转发给第二服务器,第二服务器用于响应于状态变更请求,在第二应用的状态信息满足状态协同条件的情况下,向第一服务器发送验证成功消息,第一服务器还用于将验证成功消息发送给终端;
状态变更模块1703,用于:
在接收到第一服务器返回的验证成功消息的情况下,控制第一应用变更为第一状态。
可选地,状态变更模块1703,还用于:
接收服务器发送的状态变更指令,状态变更指令用于指示将第一应用变更为第二状态;其中,状态变更指令是服务器在第二应用的状态发生变化后,第二应用的变化后的状态信息不满足状态协同条件时发送的,第二状态为第二应用处于变化后的状态信息指示的状态时,第一应用所需处于的状态;
控制第一应用变更为第二状态。
需要说明的是:上述实施例提供的状态协同装置,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将终端的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的状态协同装置与状态协同方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
图18是本申请实施例提供的一种状态协同装置的结构示意图,该状态协同装置设置于服务器中。参见图18,该装置包括:
请求接收模块1801,用于接收终端通过第一应用发送的状态变更请求,状态变更请求用于请求将第一应用变更为第一状态,状态变更请求携带第二应用的状态信息;其中,终端安装有第一应用和第二应用,第一应用和第二应用之间具有依赖关系;
条件获取模块1802,用于获取第一应用和第二应用之间的状态协同条件,状态协同条件包括第一应用变更为第一状态时,第二应用的状态信息所需满足的条件;
消息发送模块1803,用于在第二应用的状态信息满足状态协同条件的情况下,向终端返回验证成功消息,终端用于在接收到验证成功消息的情况下,控制第一应用变更为第一状态。
本申请实施例提供的状态协同装置,在第一应用和第二应用之间具有依赖关系的情况下,如果第一应用想要进行状态变更,则需要查询第二应用当前的状态。第一应用通过调用第二应用提供的状态查询程序,获取第二应用的状态信息,并将第二应用的状态信息提供给服务器,由服务器验证是否满足状态协同条件,在验证通过的情况下允许第一应用进行状态变更。首先通过调用状态查询程序获取状态信息,使得状态信息的获取过程不易被干涉和破坏,保证了状态信息的准确性。并且通过服务器对状态信息进行验证,使得状态信息的验证过程不易被干涉和破坏,保证了验证过程的可靠性,因此本申请提供的方案能够提高应用之间进行状态协同的安全性。
可选地,参见图19,装置还包括指令发送模块1804,用于:
在第二应用的变化后的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态,第二状态为第二应用处于变化后的状态信息指示的状态时,第一应用所需处于的状态;
向终端发送状态变更指令,状态变更指令用于指示将第一应用变更为第二状态。
可选地,指令发送模块1804,用于:
周期性获取第二应用的状态信息,在获取到的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态;或者,
在第二应用进行状态变更后,获取第二应用的变化后的状态信息,在变化后的状态信息不满足状态协同条件的情况下,基于状态协同条件确定第二状态。
需要说明的是:上述实施例提供的状态协同装置,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将服务器的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的状态协同装置与状态协同方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
本申请实施例还提供了一种计算机设备,该计算机设备包括处理器和存储器,存储器中存储有至少一条计算机程序,该至少一条计算机程序由处理器加载并执行,以实现上述实施例的状态协同方法中所执行的操作。
可选地,该计算机设备提供为终端。图20示出了本申请一个示例性实施例提供的终端2000的结构示意图。终端2000包括有:处理器2001和存储器2002。
处理器2001可以包括一个或多个处理核心,比如4核心处理器、8核心处理器等。处理器2001可以采用DSP(Digital Signal Processing,数字信号处理)、FPGA(FieldProgrammable Gate Array,现场可编程门阵列)、PLA(Programmable Logic Array,可编程逻辑阵列)中的至少一种硬件形式来实现。处理器2001也可以包括主处理器和协处理器,主处理器是用于对在唤醒状态下的数据进行处理的处理器,也称CPU(Central ProcessingUnit,中央处理器);协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中,处理器2001可以集成有GPU(Graphics Processing Unit,图像处理的交互器),GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中,处理器2001还可以包括AI(Artificial Intelligence,人工智能)处理器,该AI处理器用于处理有关机器学习的计算操作。
存储器2002可以包括一个或多个计算机可读存储介质,该计算机可读存储介质可以是非暂态的。存储器2002还可包括高速随机存取存储器,以及非易失性存储器,比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中,存储器2002中的非暂态的计算机可读存储介质用于存储至少一条计算机程序,该至少一条计算机程序用于被处理器2001所具有以实现本申请中方法实施例提供的状态协同方法。
在一些实施例中,终端2000还可选包括有:***设备接口2003和至少一个***设备。处理器2001、存储器2002和***设备接口2003之间可以通过总线或信号线相连。各个***设备可以通过总线、信号线或电路板与***设备接口2003相连。可选地,***设备包括:射频电路2004、显示屏2005、摄像头组件2006、音频电路2007和电源2008中的至少一种。
***设备接口2003可被用于将I/O(Input/Output,输入/输出)相关的至少一个***设备连接到处理器2001和存储器2002。在一些实施例中,处理器2001、存储器2002和***设备接口2003被集成在同一芯片或电路板上;在一些其他实施例中,处理器2001、存储器2002和***设备接口2003中的任意一个或两个可以在单独的芯片或电路板上实现,本实施例对此不加以限定。
射频电路2004用于接收和发射RF(Radio Frequency,射频)信号,也称电磁信号。射频电路2004通过电磁信号与通信网络以及其他通信设备进行通信。射频电路2004将电信号转换为电磁信号进行发送,或者,将接收到的电磁信号转换为电信号。可选地,射频电路2004包括:天线***、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路2004可以通过至少一种无线通信协议来与其它设备进行通信。该无线通信协议包括但不限于:城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity,无线保真)网络。在一些实施例中,射频电路2004还可以包括NFC(Near Field Communication,近距离无线通信)有关的电路,本申请对此不加以限定。
显示屏2005用于显示UI(User Interface,用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏2005是触摸显示屏时,显示屏2005还具有采集在显示屏2005的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器2001进行处理。此时,显示屏2005还可以用于提供虚拟按钮和/或虚拟键盘,也称软按钮和/或软键盘。在一些实施例中,显示屏2005可以为一个,设置在终端2000的前面板;在另一些实施例中,显示屏2005可以为至少两个,分别设置在终端2000的不同表面或呈折叠设计;在另一些实施例中,显示屏2005可以是柔性显示屏,设置在终端2000的弯曲表面上或折叠面上。甚至,显示屏2005还可以设置成非矩形的不规则图形,也即异形屏。显示屏2005可以采用LCD(Liquid Crystal Display,液晶显示屏)、OLED(Organic Light-EmittingDiode,有机发光二极管)等材质制备。
摄像头组件2006用于采集图像或视频。可选地,摄像头组件2006包括前置摄像头和后置摄像头。前置摄像头设置在终端2000的前面板,后置摄像头设置在终端2000的背面。在一些实施例中,后置摄像头为至少两个,分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种,以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality,虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中,摄像头组件2006还可以包括闪光灯。闪光灯可以是单色温闪光灯,也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合,可以用于不同色温下的光线补偿。
音频电路2007可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波,并将声波转换为电信号输入至处理器2001进行处理,或者输入至射频电路2004以实现语音通信。出于立体声采集或降噪的目的,麦克风可以为多个,分别设置在终端2000的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器2001或射频电路2004的电信号转换为声波。扬声器可以是传统的薄膜扬声器,也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时,不仅可以将电信号转换为人类可听见的声波,也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中,音频电路2007还可以包括耳机插孔。
电源2008用于为终端2000中的各个组件进行供电。电源2008可以是交流电、直流电、一次性电池或可充电电池。当电源2008包括可充电电池时,该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。
本领域技术人员可以理解,图20中示出的结构并不构成对终端2000的限定,可以包括比图示更多或更少的组件,或者组合某些组件,或者采用不同的组件布置。
可选地,该计算机设备提供为服务器。图21是本申请实施例提供的一种服务器的结构示意图,该服务器2100可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上处理器(Central Processing Units,CPU)2101和一个或一个以上的存储器2102,其中,所述存储器2102中存储有至少一条计算机程序,所述至少一条计算机程序由所述处理器2101加载并执行以实现上述各个方法实施例提供的方法。当然,该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件,以便进行输入输出,该服务器还可以包括其他用于实现设备功能的部件,在此不做赘述。
本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有至少一条计算机程序,该至少一条计算机程序由处理器加载并执行,以实现上述实施例的状态协同方法所执行的操作。
本申请实施例还提供了一种计算机程序产品,包括计算机程序,所述计算机程序由处理器加载并执行,以实现如上述实施例的状态协同方法所执行的操作。在一些实施例中,本申请实施例所涉及的计算机程序可被部署在一个计算机设备上执行,或者在位于一个地点的多个计算机设备上执行,又或者,在分布在多个地点且通过通信网络互连的多个计算机设备上执行,分布在多个地点且通过通信网络互连的多个计算机设备可以组成区块链***。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本申请实施例的可选实施例,并不用以限制本申请实施例,凡在本申请实施例的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。

Claims (15)

1.一种状态协同方法,其特征在于,由终端执行,所述终端安装有第一应用和第二应用,所述第一应用和所述第二应用之间具有依赖关系;所述方法包括:
响应于将所述第一应用变更为第一状态的状态变更操作,通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的状态信息;
通过所述第一应用,向服务器发送状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带所述第二应用的状态信息,所述服务器用于响应于所述状态变更请求,在所述第二应用的状态信息满足状态协同条件的情况下,返回验证成功消息,所述状态协同条件包括将所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
2.根据权利要求1所述的方法,其特征在于,所述状态信息包括多种状态子信息,所述状态查询程序包括多个,每个状态查询程序用于获取至少一种状态子信息;所述通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的状态信息,包括:
通过所述第一应用,分别调用所述第二应用的多个状态查询程序,获取每个状态查询程序对应的状态子信息。
3.根据权利要求1所述的方法,其特征在于,所述通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的状态信息,包括:
通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的待处理信息;
按照预设算法,对所述待处理信息进行处理,得到所述状态信息。
4.根据权利要求3所述的方法,其特征在于,所述状态信息包括登录信息,所述待处理信息包括路径信息和密码信息,所述预设算法为预设加密算法;
所述按照预设算法,对所述待处理信息进行处理,得到所述状态信息,包括:
在所述路径信息指示的存储路径中获取加密登录信息;
按照所述预设加密算法,采用所述密码信息对所述加密登录信息进行解密,得到所述登录信息。
5.根据权利要求3所述的方法,其特征在于,所述状态信息包括设备标识,所述设备标识用于指示所述第二应用所在的终端,所述待处理信息包括所述第二应用所在的终端的硬盘信息、主板信息和设备属性信息中的至少一项,所述预设算法为预设转换算法;
所述按照预设算法,对所述待处理信息进行处理,得到所述状态信息,包括:
按照所述预设转换算法,对所述硬盘信息、所述主板信息和所述设备属性信息中的至少一项进行计算,得到所述设备标识。
6.根据权利要求1所述的方法,其特征在于,所述通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的状态信息,包括:
通过所述第一应用,调用所述第二应用的状态查询程序,以使所述状态查询程序在所述第一应用的应用信息满足所述第二应用的验证条件的情况下,返回所述第二应用的状态信息。
7.根据权利要求1所述的方法,其特征在于,所述通过所述第一应用,向服务器发送状态变更请求之后,所述方法还包括:
在发送所述状态变更请求后的时长达到目标时长,但还未收到所述验证成功消息或者验证失败消息的情况下,控制所述第一应用变更为所述第一状态。
8.根据权利要求1所述的方法,其特征在于,所述在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态之后,所述方法还包括:
接收所述服务器发送的状态变更指令,所述状态变更指令用于指示将所述第一应用变更为第二状态;其中,所述状态变更指令是所述服务器在所述第二应用的状态发生变化后,所述第二应用的变化后的状态信息不满足所述状态协同条件时发送的,所述第二状态为所述第二应用处于变化后的状态信息指示的状态时,所述第一应用所需处于的状态;
控制所述第一应用变更为所述第二状态。
9.一种状态协同方法,其特征在于,由服务器执行,所述方法包括:
接收终端通过第一应用发送的状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带第二应用的状态信息;其中,所述终端安装有所述第一应用和所述第二应用,所述第一应用和所述第二应用之间具有依赖关系;
获取所述第一应用和所述第二应用之间的状态协同条件,所述状态协同条件包括所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
在所述第二应用的状态信息满足所述状态协同条件的情况下,向所述终端返回验证成功消息,所述终端用于在接收到所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
10.根据权利要求9所述的方法,其特征在于,所述在所述第二应用的状态信息满足所述状态协同条件的情况下,向所述终端返回验证成功消息之后,所述方法还包括:
在所述第二应用的变化后的状态信息不满足所述状态协同条件的情况下,基于所述状态协同条件确定第二状态,所述第二状态为所述第二应用处于变化后的状态信息指示的状态时,所述第一应用所需处于的状态;
向所述终端发送状态变更指令,所述状态变更指令用于指示将所述第一应用变更为所述第二状态。
11.一种状态协同装置,其特征在于,设置于终端中,所述终端安装有第一应用和第二应用,所述第一应用和所述第二应用之间具有依赖关系;所述装置包括:
信息获取模块,用于响应于将所述第一应用变更为第一状态的状态变更操作,通过所述第一应用,调用所述第二应用的状态查询程序,获取所述第二应用的状态信息;
请求发送模块,用于通过所述第一应用,向服务器发送状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带所述第二应用的状态信息,所述服务器用于响应于所述状态变更请求,在所述第二应用的状态信息满足状态协同条件的情况下,返回验证成功消息,所述状态协同条件包括将所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
状态变更模块,用于在接收到所述服务器返回的所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
12.一种状态协同装置,其特征在于,设置于服务器中,所述装置包括:
请求接收模块,用于接收终端通过第一应用发送的状态变更请求,所述状态变更请求用于请求将所述第一应用变更为所述第一状态,所述状态变更请求携带第二应用的状态信息;其中,所述终端安装有所述第一应用和所述第二应用,所述第一应用和所述第二应用之间具有依赖关系;
条件获取模块,用于获取所述第一应用和所述第二应用之间的状态协同条件,所述状态协同条件包括所述第一应用变更为所述第一状态时,所述第二应用的状态信息所需满足的条件;
消息发送模块,用于在所述第二应用的状态信息满足所述状态协同条件的情况下,向所述终端返回验证成功消息,所述终端用于在接收到所述验证成功消息的情况下,控制所述第一应用变更为所述第一状态。
13.一种计算机设备,其特征在于,所述计算机设备包括处理器和存储器,所述存储器中存储有至少一条计算机程序,所述至少一条计算机程序由所述处理器加载并执行,以实现如权利要求1至8任一项所述的状态协同方法所执行的操作,或者实现如权利要求9至10任一项所述的状态协同方法所执行的操作。
14.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有至少一条计算机程序,所述至少一条计算机程序由处理器加载并执行,以实现如权利要求1至8任一项所述的状态协同方法所执行的操作,或者实现如权利要求9至10任一项所述的状态协同方法所执行的操作。
15.一种计算机程序产品,包括计算机程序,其特征在于,所述计算机程序由处理器加载并执行,以实现如权利要求1至8任一项所述的状态协同方法所执行的操作,或者实现如权利要求9至10任一项所述的状态协同方法所执行的操作。
CN202310765029.8A 2023-06-26 2023-06-26 状态协同方法、装置、计算机设备及存储介质 Pending CN116954693A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310765029.8A CN116954693A (zh) 2023-06-26 2023-06-26 状态协同方法、装置、计算机设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310765029.8A CN116954693A (zh) 2023-06-26 2023-06-26 状态协同方法、装置、计算机设备及存储介质

Publications (1)

Publication Number Publication Date
CN116954693A true CN116954693A (zh) 2023-10-27

Family

ID=88453929

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310765029.8A Pending CN116954693A (zh) 2023-06-26 2023-06-26 状态协同方法、装置、计算机设备及存储介质

Country Status (1)

Country Link
CN (1) CN116954693A (zh)

Similar Documents

Publication Publication Date Title
US11075955B2 (en) Methods and systems for use in authorizing access to a networked resource
US10083290B2 (en) Hardware-based device authentication
CN112422532B (zh) 业务通信方法、***、装置及电子设备
CN112073400B (zh) 一种访问控制方法、***、装置及计算设备
US9386045B2 (en) Device communication based on device trustworthiness
US9270674B2 (en) Validating the identity of a mobile application for mobile application management
CN108632253B (zh) 基于移动终端的客户数据安全访问方法及装置
US10762209B2 (en) Boot security
EP2486509B1 (en) Platform security
CN111737366B (zh) 区块链的隐私数据处理方法、装置、设备以及存储介质
WO2022193513A1 (zh) 一种基于容器引擎的数据处理方法以及相关设备
CN112765684B (zh) 区块链节点终端管理方法、装置、设备及存储介质
US11695650B2 (en) Secure count in cloud computing networks
EP2795522B1 (en) Techniques to store secret information for global data centers
EP3085007B1 (en) Push-based trust model for public cloud applications
CN116015695A (zh) 资源访问方法、***、装置、终端及存储介质
CN116954693A (zh) 状态协同方法、装置、计算机设备及存储介质
CN104717235B (zh) 一种虚拟机资源检测方法
CN115623013A (zh) 一种策略信息同步方法、***及相关产品
CN117278323B (zh) 第三方信息的获取方法、电子设备及可读存储介质
Rayapuri A Survey of Security and Privacy in Mobile Cloud Computing
WO2023022838A1 (en) Edge-based enterprise network security appliance and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication