一种基于应用容器引擎的应用授权验证方法和装置

技术领域

本申请涉及计算机技术领域，具体而言，尤其涉及一种基于应用容器引擎(Docker)的应用授权验证方法和装置。

背景技术

目前，传统的应用授权验证方法是借助于物理机的唯一性标识(例如，硬盘序列号、CPU标识、网口媒体存取控制地址(Media Access Control Address，MAC)等)或者虚拟机的唯一性标识(例如，网口MAC地址等)来实现的。

但是，上述传统的应用授权验证方法对Docker的应用的授权验证是不适用的。例如，由于Docker每次启动后，其对应的硬盘序列号、CPU标识、网口MAC地址等都是不一样的，即Docker能够动态变更虚拟硬件的配置，故无法通过CPU标识、网口MAC地址等虚拟硬件信息来实现Docker的应用的授权验证。

发明内容

本申请实施例的目的在于提供一种基于应用容器引擎的应用授权验证方法和装置，以实现对Docker中的应用的授权验证。

第一方面，本申请实施例提供了一种基于应用容器引擎的应用授权验证方法，应用容器引擎的镜像中存储有授权信息，授权信息包括指定标识信息和已授权的标识信息，指定标识信息用于指定与已授权的标识信息进行比对的待验证的标识信息的类别，已授权的标识信息包括镜像对应的容器的标识和应用容器引擎所在的宿主机的标识，应用授权验证方法包括：根据指定标识信息，获取待验证的标识信息；将待验证的标识信息和已授权的标识信息进行比对，获得比对结果；根据比对结果，确定待授权应用的授权结果。

因此，本申请实施例通过指定标识信息，获取当前Docker相关的待验证的标识信息。以及，由于已授权的标识信息包括镜像对应的容器的标识和Docker所在的宿主机的标识，且指定标识信息可用于指定与已授权的标识信息进行比对的待验证的标识信息的类别，则待验证的标识信息可以为当前Docker相关的待验证的容器的标识和/或待验证的宿主机的标识，从而后续可将待验证的标识信息和已授权的标识信息进行比对，并根据比对结果来确定待授权应用的授权结果，进而可根据容器的标识和/或宿主机的标识来实现对Docker的应用的授权验证。

在一个可能的实施例中，镜像中还存储有应用容器引擎所在的应用容器引擎集群中已授权应用的总数量；其中，根据比对结果，确定待授权应用的授权结果，包括：在对比结果不一致或者已授权应用的总数量等于最大授权数量的情况下，拒绝对待授权应用进行授权。

因此，本申请实施例可通过设置最大授权数量，从而能够实现对授权应用的管控。

在一个可能的实施例中，根据比对结果，确定待授权应用的授权结果，包括：在对比结果一致且已授权应用的总数量小于最大授权数量的情况下，对待授权应用进行授权。

在一个可能的实施例中，授权信息还包括有效时间信息，根据指定标识信息，获取待验证的标识信息，包括：在通过有效时间信息确定授权信息处于有效时间范围内的情况下，根据指定标识信息，获取待验证的标识信息。

因此，本申请实施例可通过设置有效时间信息来保证授权信息的时效性。

第二方面，本申请实施例提供了一种基于应用容器引擎的应用授权验证装置，应用容器引擎的镜像中存储有授权信息，授权信息包括指定标识信息和已授权的标识信息，指定标识信息用于指定与已授权的标识信息进行比对的待验证的标识信息的类别，已授权的标识信息包括镜像对应的容器的标识和应用容器引擎所在的宿主机的标识，应用授权验证装置包括：获取模块，用于根据指定标识信息，获取待验证的标识信息；比对模块，用于将待验证的标识信息和已授权的标识信息进行比对，获得比对结果；确定模块，用于根据比对结果，确定待授权应用的授权结果。

在一个可能的实施例中，镜像中还存储有应用容器引擎所在的应用容器引擎集群中已授权应用的总数量；其中，比对模块，具体用于在对比结果不一致或者已授权应用的总数量等于最大授权数量的情况下，拒绝对待授权应用进行授权。

在一个可能的实施例中，比对模块，具体用于在对比结果一致且已授权应用的总数量小于最大授权数量的情况下，对待授权应用进行授权。

在一个可能的实施例中，授权信息还包括有效时间信息，获取模块，具体用于在通过有效时间信息确定授权信息处于有效时间范围内的情况下，根据指定标识信息，获取待验证的标识信息。

第三方面，本申请实施例提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行第一方面或第一方面的任一可选的实现方式所述的方法。

第四方面，本申请实施例提供了一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行第一方面或第一方面的任一可选的实现方式所述的方法。

第五方面，本申请提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行第一方面或第一方面的任意可能的实现方式中的方法。

为使本申请实施例所要实现的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种配置源镜像的方法的流程图；

图2示出了本申请实施例提供的一种基于应用容器引擎的应用授权验证方法的流程图；

图3示出了本申请实施例提供的一种基于应用容器引擎的应用授权验证装置的结构框图；

图4示出了本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

目前，随着Docker的应用越来越广泛，Docker的应用的授权验证显得越来越重要。

此外，Docker的特性是通过虚拟化使用宿主机的硬件，无法获取真实的硬件信息。以及，Docker虽然可以通过手动执行命令在启动镜像时挂载宿主机硬件，但是，绝大多数项目和正式业务环境是不支持手动执行的。

基于此，本申请实施例提供了一种基于Docker的应用授权验证方法和装置，通过根据镜像中存储的授权信息内的指定标识信息，获取当前Docker相关的待验证的标识信息，随后将待验证的标识信息和已授权的标识信息进行比对，获得比对结果，且已授权的标识信息包括镜像对应的容器的标识和应用容器引擎所在的宿主机的标识，最后根据比对结果，确定待授权应用的授权结果。

因此，本申请实施例通过指定标识信息，获取当前Docker相关的待验证的标识信息。以及，由于已授权的标识信息包括镜像对应的容器的标识和Docker所在的宿主机的标识，且指定标识信息可用于指定与已授权的标识信息进行比对的待验证的标识信息的类别，则待验证的标识信息可以为当前Docker相关的待验证的容器的标识和/或待验证的宿主机的标识，从而后续可将待验证的标识信息和已授权的标识信息进行比对，并根据比对结果来确定待授权应用的授权结果，进而可根据容器的标识和/或宿主机的标识来实现对Docker的应用的授权验证。

为了便于理解本申请实施例，首先在此对本申请实施例的一些术语进行解释如下：

“单Docker镜像验证模式”：它是利用当前镜像对应的容器的标识来进行验证的模式。

例如，在多宿主机环境中进行镜像漂移或者镜像迁移，只要Docker镜像的容器的标识不变，则应用的授权验证就可通过。

再例如，重新创建的Docker镜像(或者说利用服务器中的源镜像复制处的新镜像)因容器的标识变更，即其新建的容器的标识与对应的Docker镜像(或者新镜像)中存储的授权信息内的已授权的容器的标识不一致，则该重新创建的Docker镜像中的应用的授权验证就无法通过。

“单宿主机验证模式”：它是利用当前镜像所在的宿主机的标识来进行验证的模式。

例如，在对当前宿主机进行授权且当前宿主机支持使用同源的多个镜像(即多个镜像可以是由一个源镜像复制出的)的情况下，对当前宿主机中的多个镜像进行升级切换，由于当前宿主机的标识没有发生变化，则应用的授权验证就可通过。

再例如，在切换宿主机后，由于镜像所在的宿主机的标识发生改变，则新宿主机中的应用的授权验证就无法通过。

“完全绑定验证模式”：它是利用容器的标识和宿主机的标识来进行验证的模式。

例如，在切换宿主机后，由于镜像所在的宿主机的标识发生改变，则新宿主机中的应用的授权验证就无法通过。

再例如，重新创建的Docker镜像因容器的标识变更，即其新建的容器的标识与对应的Docker镜像中存储的授权信息内的已授权的容器的标识不一致，则该重新创建的Docker镜像中的应用的授权验证就无法通过。

再例如，在当前宿主机内重新创建Docker镜像的情况下，由于新建的Docker镜像对应的容器的标识和授权信息中已授权的容器的标识相同，且当前宿主机的标识和授权信息中的宿主机的标识相同，则该重新创建的Docker镜像中的应用的授权验证就可通过。

请参见图1，图1示出了本申请实施例提供的一种配置源镜像的方法的流程图。如图1所示的方法包括：

步骤S110，通过源镜像在Docker内获取当前容器的标识和宿主机的标识。

应理解，源镜像可以是指可复制出的镜像。

还应理解，宿主机可以为服务器。

还应理解，当前容器的标识可以是通过cpuset或cgroup等不可变更的内容获取的。

还应理解，宿主机的标识可以是通过product_uuid等不可变更的内容获取的。

这里需要说明的是，cpuset、cgroup和product_uuid等不可变更的内容均属于系统设备信息，其为系统级别不可修改项，可防止篡改。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

具体地，可通过源镜像判断应用(还可称为应用服务，也可称为应用产品服务)是否安装在Docker内。在确定应用安装在Docker内的情况下，可获取当前容器的标识和硬件服务器的标识，可利用当前容器的标识和/或硬件服务器的标识来进行应用授权的验证；在确定应用安装在硬件服务器中的情况下，可获取硬件服务器的硬盘序列号、CPU标识、网口MAC地址等，可利用硬盘序列号、CPU标识、网口MAC地址等来进行应用授权的验证，后续不再详细描述。其中，应用可以为Docker中的应用。

应理解，通过源镜像判断应用是否安装在Docker内的具体过程可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，通过源镜像确定应用的安装路径，并可根据安装路径可确定应用是否安装在Docker内。

这里需要说明的是，之前是基于硬件服务器的授权(例如，通过获取MAC地址来授权等)，本申请实施例是在原有基础上增加对Docker的支持，所以需要区别是原有硬件服务器的授权还是Docker的授权。也就是整个授权功能同时支持硬件服务器和Docker授权。

步骤S120，通过源镜像根据当前容器的标识和宿主机的标识，生成授权请求信息。

具体地，通过源镜像可对当前容器的标识和宿主机的标识进行组合，以生成组合信息。随后，通过源镜像可对组合信息进行签名，以获得签名信息。随后，通过源镜像可对当前容器的标识、宿主机的标识和签名信息进行加密，以获得加密信息，并可将加密信息作为授权请求信息。

也就是说，授权请求信息中可携带有加密信息。其中，加密信息是对原始的容器的标识、原始的宿主机的标识和签名信息进行加密后获得的。

应理解，当前容器的标识和宿主机的标识的组合方式可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，当前容器的标识和宿主机的标识的组合方式可以是在当前容器的标识和宿主机的标识中间设置一个间隔符。

还应理解，对组合信息进行签名的具体签名算法以及对当前容器的标识、宿主机的标识和签名信息进行加密的具体加密算法等均可根据实际需求来进行设置，本申请实施例并不局限于此。

步骤S130，通过源镜像根据授权请求信息，获得授权信息。

具体地，源镜像中除了安装有可授权的应用之外，还可安装有能够对可授权的应用进行授权的授权软件，从而可通过授权软件对授权请求信息进行处理，以获得授权信息。

应理解，通过授权软件对授权请求信息进行处理，以获得授权信息的具体过程可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，可将授权请求信息返回给客户端，随后客户端可将授权请求信息发送给产生授权信息的服务器。随后，该产生授权信息的服务器可对授权请求信息进行解密和解签，并对解签后的信息进行验证。在验证通过的情况下，可生成授权信息。

还应理解，授权信息携带的信息可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，授权信息可携带有指定标识信息、有效时间信息和已授权的标识信息等。其中，指定标识信息是用于指定与已授权的标识信息进行比对的待验证的标识信息的类别，即指定标识信息可以是用于指定验证模式的信息，验证模式可以为单Docker镜像验证模式，也可以为单宿主机验证模式，也可以为完全绑定验证模式；有效时间信息可以用于表示授权信息的有效时间，从而可根据有效时间信息判断授权信息是否有效；已授权的标识信息可以包括已授权的容器的标识和已授权的宿主机的标识，且已授权的标识信息可以是签名加密后的信息。

这里需要说明的是，虽然上面对授权信息所包含的信息进行了举例，但本领域的技术人员应当理解，授权信息所包含的具体信息可根据实际需求来进行设置，本申请实施例并不局限于此。

步骤S140，将授权信息导入到源镜像中，并可对授权信息进行解析。

应理解，解析后的授权信息可以包括指定标识信息、有效时间信息和已授权的标识信息等。

这里需要说明的是，在源镜像包含有指定标识信息、有效时间信息和已授权的标识信息等信息的情况下，后续通过对源镜像进行复制后，复制后的镜像和源镜像是一摸一样的，从而复制后的镜像也包含有授权信息和应用的。从而，可通过获取新创建的Docker的待验证的标识信息，并将待验证的标识信息和复制后的镜像中的已授权标识信息进行比对来确定复制后的镜像中的待授权的应用是否能够授权。

为了便于理解本申请实施例，下面通过应用授权验证方法的具体过程来进行描述。也就是说，图2所示的方法可以是在图1所示的方法之后执行的。

请参见图2，图2示出了本申请实施例提供的一种基于应用容器引擎的应用授权验证方法的流程图。应理解，图2所示的应用授权验证方法可以由基于应用容器引擎的应用授权验证装置执行，该应用授权验证装置可以与下文中的图3所示的基于应用容器引擎的应用授权验证装置对应，该应用授权验证装置可以是能够执行该方法的各种设备，本申请实施例并不限于此。具体地，应用容器引擎的镜像中存储有授权信息，授权信息包括指定标识信息和已授权的标识信息，指定标识信息用于指定与已授权的标识信息进行比对的待验证的标识信息的类别，已授权的标识信息包括镜像对应的容器的标识和应用容器引擎所在的宿主机的标识，如图2所示的应用授权验证方法包括：

步骤S210，根据指定标识信息，获取待验证的标识信息。

应理解，待验证的标识信息可以是待验证的容器的标识(或者ID)，也可以是待验证的宿主机的标识，也可以是待验证的容器的标识和待验证的宿主机的标识。

还应理解，待验证的标识信息对应的镜像可以是源镜像，也可以是通过源镜像复制的镜像。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

可选地，通过当前镜像获取待验证的容器的标识和待验证的宿主机的标识。随后，可通过查询当前镜像的相关信息获取授权信息，且由于授权信息中包含能够指示验证模式的指定标识信息，从而可获得待验证的标识信息。

也就是说，可先获取到待验证的容器的标识和待验证的宿主机的标识，随后再根据指定标识信息对待验证的标识信息进行筛选。

例如，通过当前镜像获取待验证的容器的标识和待验证的宿主机的标识。以及，指定标识信息指示的验证模式为单宿主机验证模式的情况下，可将待验证的宿主机的标识作为待验证的标识信息。

可选地，可通过查询当前镜像的相关信息获取授权信息，且由于授权信息中包含能够指示验证模式的指定标识信息，从而可获得待验证的标识信息。

也就是说，可根据指定标识信息来直接获取对应的待验证的标识信息。

例如，指定标识信息指示的验证模式为单Docker镜像验证模式的情况下，可直接获取待验证的容器的标识。

这里需要说明的是，在执行步骤S210之前，需要通过授权信息中的有效时间信息来确定授权信息是否有效。若授权信息处于有效时间范围内，则执行步骤S210；若授权信息没有处于有效时间内的情况下，则可等待授权信息的更新。

步骤S220，将待验证的标识信息和已授权的标识信息进行比对，获得比对结果。

应理解，由于待验证的标识信息可以是三种，对应地，已授权的标识信息也可以是已授权的容器的标识，也可以是已授权的宿主机的标识，也可以是已授权的容器的标识和已授权的宿主机的标识。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

可选地，将待验证的容器的标识和已授权的容器的标识进行比对，获得比对结果。其中，比对结果可以是待验证的容器的标识和已授权的容器的标识一致，也可以是待验证的容器的标识和已授权的容器的标识不一致。

可选地，将待验证的宿主机的标识和已授权的宿主机的标识进行比对，获得比对结果。其中，比对结果可以是待验证的宿主机的标识和已授权的宿主机的标识一致，也可以是待验证的宿主机的标识和已授权的宿主机的标识不一致。

可选地，可将待验证的容器的标识和已授权的容器的标识进行第一次比对，以及还将待验证的宿主机的标识和已授权的宿主机的标识进行第二次比对。其中，比对结果可以是第一比对结果和第二比对结果均一致，也可以是第一比对结果和第二比对结果中的一个比对结果一致，也可以是第一比对结果和第二比对结果均不一致。

步骤S230，根据比对结果，确定待授权应用的授权结果。

应理解，待授权应用是指当前镜像中的待授权应用，从而在当前镜像所在的当前宿主机启动的过程中，Docker镜像中的待授权应用可随着启动，从而可需要验证待授权应用是否被授权。

还应理解，根据比对结果，确定待授权应用的授权结果的具体过程可根据实际需求来进行设置，本申请实施例并不局限于此。

可选地，在确定待验证的标识信息和已授权的标识信息一致(在需要对容器的标识和宿主机的标识这两个标识进行验证的情况下，这里的一致是指两种标识的比对结果均一致)的情况下，则可对待授权应用进行授权，即允许待授权应用对外提供服务器。

可选地，在确定待验证的标识信息和已授权的标识信息不一致(在需要对容器的标识和宿主机的标识这两个标识进行验证的情况下，这里的不一致是指两种标识的比对结果均不一致或者一个比对结果一致)的情况下，则拒绝对待授权应用进行授权，即待授权应用无法对外提供服务。

可选地，在多个Docker构成Docker集群的情况下，可为Docker集群设置可授权应用的最大授权数量，且Docker集群中每个Docker内的镜像中均存储有Docker集群中已授权应用的总数量。

在确定待验证的标识信息和已授权的标识信息一致的情况下，则可继续判断Docker集群中已授权应用的总数量是否等于最大授权数量。在对比结果一致且已授权应用的总数量小于最大授权数量的情况下，则对待授权应用进行授权，并且在对待授权应用进行授权之后，当前镜像可向Docker集群中的其他Docker发送授权同步信息(即可将已授权应用的总数量加1)；在对比结果一致且已授权应用的总数量等于最大授权数量的情况下，则拒绝对待授权应用进行授权。

也就是说，Docker集群中授权应用的总个数是不能超过最大授权数量的，否则新启动的Docker镜像的应用是不可用的。

应理解，最大授权数量的具体数量可根据实际需求来进行设置，本申请实施例并不局限于此。

这里需要说明的是，容器管理平台可以进行启动容器的操作和关闭容器的操作，当启动新容器后，新容器中的待授权应用通过网络扫描，发现其它容器中的同类应用后(每个容器均可以存有容器列表，通过UPD(User Datagram Protocol，用户数据报协议)方式定时同步，且每个容器列表均可用于确定集群中同类应用的启动情况)。从而，新容器可获取自身存储的容器列表，并可根据容器列表来确定当前已经授权的同类应用的具体数量，以及可根据该具体数量来判断自身的待授权应用是否可以正常提供服务。

其中，容器列表可以包括多个列表项，每个列表项可记录有已启动的应用的容器的标识，或者每个列表项可记录有所有容器的标识以及对应的应用的启动情况(例如，已经启动的应用标识可以为Y，没有启动的应用标识可以为N)。

因此，本申请实施例通过指定标识信息，获取当前Docker相关的待验证的标识信息。以及，由于已授权的标识信息包括镜像对应的容器的标识和Docker所在的宿主机的标识，且指定标识信息可用于指定与已授权的标识信息进行比对的待验证的标识信息的类别，则待验证的标识信息可以为当前Docker相关的待验证的容器的标识和/或待验证的宿主机的标识，从而后续可将待验证的标识信息和已授权的标识信息进行比对，并根据比对结果来确定待授权应用的授权结果，进而可根据容器的标识和/或宿主机的标识来实现对Docker的应用的授权验证。

此外，本申请实施例通过在镜像中设置已授权的标识信息，避免了应用的验证都需要执行图1相关的过程，进而能够提高验证效率。

应理解，上述基于应用容器引擎的应用授权验证方法仅是示例性的，本领域技术人员根据上述的方法可以进行各种变形，修改或变形之后的内容也在本申请保护范围内。

请参见图3，图3示出了本申请实施例提供的一种基于应用容器引擎的应用授权验证装置300的结构框图，应理解，该应用授权验证装置300与上述方法实施例对应，能够执行上述方法实施例涉及的各个步骤，该应用授权验证装置300具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。该应用授权验证装置300包括至少一个能以软件或固件(firmware)的形式存储于存储器中或固化在应用授权验证装置300的操作系统(operating system，OS)中的软件功能模块。具体地，该应用授权验证装置300包括：

获取模块310，用于根据指定标识信息，获取待验证的标识信息；比对模块320，用于将待验证的标识信息和已授权的标识信息进行比对，获得比对结果；确定模块330，用于根据比对结果，确定待授权应用的授权结果。

在一个可能的实施例中，镜像中还存储有应用容器引擎所在的应用容器引擎集群中已授权应用的总数量；比对模块320，具体用于在对比结果不一致或者已授权应用的总数量等于最大授权数量的情况下，拒绝对待授权应用进行授权。

在一个可能的实施例中，比对模块320，具体用于在对比结果一致且已授权应用的总数量小于最大授权数量的情况下，对待授权应用进行授权。

在一个可能的实施例中，授权信息还包括有效时间信息，获取模块310，具体用于在通过有效时间信息确定授权信息处于有效时间范围内的情况下，根据指定标识信息，获取待验证的标识信息。

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

请参见图4，图4示出了本申请实施例提供的一种电子设备400的结构框图。电子设备400可以包括处理器410、通信接口420、存储器430和至少一个通信总线440。其中，通信总线440用于实现这些组件直接的连接通信。其中，本申请实施例中的通信接口420用于与其他设备进行信令或数据的通信。处理器410可以是一种集成电路芯片，具有信号的处理能力。上述的处理器410可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器410也可以是任何常规的处理器等。

存储器430可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。存储器430中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器410执行时，电子设备400可以执行上述方法实施例中的各个步骤。

电子设备400还可以包括存储控制器、输入输出单元、音频单元、显示单元。

所述存储器430、存储控制器、处理器410、外设接口、输入输出单元、音频单元、显示单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线440实现电性连接。所述处理器410用于执行存储器430中存储的可执行模块。并且，电子设备400用于执行下述方法：根据所述指定标识信息，获取所述待验证的标识信息；将所述待验证的标识信息和所述已授权的标识信息进行比对，获得比对结果；根据所述比对结果，确定待授权应用的授权结果。

输入输出单元用于提供给用户输入数据实现用户与所述服务器(或本地终端)的交互。所述输入输出单元可以是，但不限于，鼠标和键盘等。

音频单元向用户提供音频接口，其可包括一个或多个麦克风、一个或者多个扬声器以及音频电路。

显示单元在所述电子设备与用户之间提供一个交互界面(例如用户操作界面)或用于显示图像数据给用户参考。在本实施例中，所述显示单元可以是液晶显示器或触控显示器。若为触控显示器，其可为支持单点和多点触控操作的电容式触控屏或电阻式触控屏等。支持单点和多点触控操作是指触控显示器能感应到来自该触控显示器上一个或多个位置处同时产生的触控操作，并将该感应到的触控操作交由处理器进行计算和处理。

可以理解，图4所示的结构仅为示意，所述电子设备400还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。

本申请还提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行方法实施例所述的方法。

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

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

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。