CN103973642B

CN103973642B - 实现js应用程序接口安全访问控制的方法与装置

Info

Publication number: CN103973642B
Application number: CN201310035012.3A
Authority: CN
Inventors: 李慧云; 陆钢; 杨新章; 何震苇; 张凌
Original assignee: China Telecom Corp Ltd
Current assignee: China Telecom Corp Ltd
Priority date: 2013-01-30
Filing date: 2013-01-30
Publication date: 2017-11-24
Anticipated expiration: 2033-01-30
Also published as: CN103973642A

Abstract

本公开涉及一种实现JS应用程序接口安全访问控制的方法与装置。该方法包括接收访问对象发起的对一应用程序接口API的调用请求；自访问对象的权限文件查询访问对象是否具有访问API的权限；响应于具有访问API的权限，查询终端能力；根据终端能力判断是否允许访问对象调用API；如果允许访问对象调用API，则向访问对象反馈允许调用API的信息，否则，拒绝访问对象对API的调用请求。本公开可保证访问对象对终端能力的安全调用。

Description

实现JS应用程序接口安全访问控制的方法与装置

技术领域

本公开涉及网络应用技术领域，特别地，涉及一种实现JS（JavaScript，Java脚本）API（Application Program Interface，应用程序接口）安全访问控制的方法与装置。

背景技术

智能终端应用形态主要分为Web（网络）应用和本地应用两类，Web应用是指运行在浏览器上的应用形态，本地应用是指直接运行在操作系统之上的应用形态。Web应用采用网页语言开发，具有开发简单、跨平台适配等优点，而本地应用一般采用Java、C等语言开发，具有开发能力强、交互性好、效率高等优点。同时这两种应用形态也在不断地融合，从而出现了Widget（微件）类应用形态，其可采用网页语言开发，同时具备本地应用的使用形式并且可以跨平台运行。虽然现阶段智能终端的应用形态仍以本地应用为主，但是Web应用和Widget应用随着HTML5标准的出现以及智能终端多平台的发展也正逐步展现出良好的发展势头。

HTML5标准的出现，使得Web应用或Widget应用可以像本地应用一样调用终端设备能力，显著增强了Web应用的表现能力和功能，同时也带来了安全风险：Web应用包由大量的Java Script、HTML文件以及CSS（Cascading Style Sheet，层叠样式表单）文件组成；从某种角度上看，Web应用的源码对用户几乎是透明的。因此，Web应用很容易被第三方恶意软件利用，对用户的设备和应用安全带来威胁。

发明内容

本公开鉴于以上问题中的至少一个提出了新的技术方案。

本公开在其一个方面提供了一种实现JS应用程序接口安全访问控制的方法，其可保证访问对象对终端能力的安全调用。

本公开在其另一方面提供了一种实现JS应用程序接口安全访问控制的装置，其可保证访问对象对终端能力的安全调用。

根据本公开，提供一种实现JS应用程序接口安全访问控制的方法，包括：

接收访问对象发起的对一应用程序接口API的调用请求；

自访问对象的权限文件查询访问对象是否具有访问API的权限；

响应于具有访问API的权限，查询终端能力；

根据终端能力判断是否允许访问对象调用API；

如果允许访问对象调用API，则向访问对象反馈允许调用API的信息，否则，拒绝访问对象对API的调用请求。

在本公开的一些实施例中，访问对象为Widget应用或Web应用。

在本公开的一些实施例中，终端能力包括终端设备能力、互联网能力与运营商能力。

在本公开的一些实施例中，该方法还包括：

如果终端设备能力、互联网能力与运营商能力中各API在进行调用时需检查环境状态，则将终端设备能力、互联网能力与运营商能力中各API与相应环境状态相关联。

在本公开的一些实施例中，该方法还包括：

响应于具有访问API的权限，根据终端设备能力、互联网能力与运营商能力中各API与相应环境状态的关联关系判断在调用API时是否需检查环境状态；

如需检查环境状态，则到终端的内存中查询终端的当前环境状态；

根据环境状态判断是否允许访问对象调用API。

在本公开的一些实施例中，该方法还包括：

响应于终端的当前环境状态的改变，将改变后的环境状态更新到终端的内存中。

在本公开的一些实施例中，该方法还包括：

判断在对API进行调用时是否需进行二次确认；

如需进行二次确认，则接收终端设备使用者反馈的信息，并根据反馈的信息确定是否允许访问对象调用API。

在本公开的一些实施例中，该方法还包括：

判断API是否需进行接入认证；

如需进行接入认证，则根据访问对象的权限文件对API进行认证，以确定是否允许访问对象调用API，其中，访问对象的权限文件包括访问权限和认证信息。

根据本公开，还提供了一种实现JS应用程序接口安全访问控制的装置，包括：

API调用请求接收单元，用于接收访问对象发起的对一应用程序接口API的调用请求；

API访问权限查询单元，用于自访问对象的权限文件查询访问对象是否具有访问API的权限；

终端能力查询单元，用于响应于具有访问API的权限，查询终端能力；

调用判断单元，用于根据终端能力判断是否允许访问对象调用API；

判断结果反馈单元，用于如果允许访问对象调用API，则向访问对象反馈允许调用API的信息，否则，拒绝访问对象对API的调用请求。

在本公开的一些实施例中，访问对象为Widget应用或Web应用。

在本公开的一些实施例中，该装置还包括：

能力状态关联单元，用于如果终端设备能力、互联网能力与运营商能力中各API在进行调用时需检查环境状态，则将终端设备能力、互联网能力与运营商能力中各API与相应环境状态相关联。

在本公开的一些实施例中，该装置还包括：

环境状态查询单元，用于响应于具有访问API的权限，根据终端设备能力、互联网能力与运营商能力中各API与相应环境状态的关联关系判断在调用API时是否需检查环境状态，如需检查环境状态，则到终端的内存中查询终端的当前环境状态；

调用判断单元还根据环境状态判断是否允许访问对象调用API。

在本公开的一些实施例中，该装置还包括：

环境状态更新单元，用于响应于终端的当前环境状态的改变，将改变后的环境状态更新到终端的内存中。

在本公开的一些实施例中，调用判断单元还判断在对API进行调用时是否需进行二次确认，如需进行二次确认，则接收终端设备使用者反馈的信息，并根据反馈的信息确定是否允许访问对象调用API。

在本公开的一些实施例中，调用判断单元还判断API是否需进行接入认证，如需进行接入认证，则根据访问对象的权限文件对API进行认证，以确定是否允许访问对象调用API，其中，访问对象的权限文件包括访问权限和认证信息。

通过本公开的技术方案，由于在访问对象具有访问权限并在终端具备相应能力的情况下访问对象才能实现对API的调用，因此在很大程度上保证了API访问的安全性。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分。在附图中：

图1是本公开一个实施例的实现JS应用程序接口安全访问控制的方法的流程示意图。

图2是本公开Web应用运行环境的系统架构示意图。

图3是本公开安全访问控制机制的判断模型示意图。

图4是本公开一个实施例的实现JS应用程序接口安全访问控制的装置的结构示意图。

图5是本公开另一实施例的实现JS应用程序接口安全访问控制的装置的结构示意图。

图6是本公开又一实施例的实现JS应用程序接口安全访问控制的装置的结构示意图。

图7是本公开再一实施例的实现JS应用程序接口安全访问控制的装置的结构示意图。

具体实施方式

下面将参照附图描述本公开。要注意的是，以下的描述在本质上仅是解释性和示例性的，决不作为对本公开及其应用或使用的任何限制。除非另外特别说明，否则，在实施例中阐述的部件和步骤的相对布置以及数字表达式和数值并不限制本公开的范围。另外，本领域技术人员已知的技术、方法和装置可能不被详细讨论，但在适当的情况下意在成为说明书的一部分。

Web应用与Widget应用对设备能力的调用是通过Widget引擎或浏览器将底层API接口转换成JS API来实现的，Widget引擎和浏览器对设备API的调用可通过操作系统的安全机制来保证，但Widget引擎或浏览器也需要对Web应用的合法性以及是否安全进行验证。总的来说，Web应用与Widget应用的安全验证需求包括以下两个部分：

（1）应用合法性验证：应用合法性验证是指Web应用与Widget应用在下载和运行过程中是否被篡改的验证。

（2）API访问安全性验证：API访问安全性验证是指对Web应用与Widget应用对JSAPI访问的合法性、权限等进行验证。

本公开下述实施例主要针对上述第（2）种安全性进行验证。本公开提供装置可作为Widget引擎或浏览器的一部分。

如图1所示，该实施例可以包括以下步骤：

S102，接收访问对象发起的对一应用程序接口API的调用请求；

其中，该访问对象可以为Widget应用或Web应用。

以Web应用为例，其运行依赖于Widget引擎或浏览器，Widget引擎或浏览器可以统称为Web应用运行环境。该实施例中Web应用运行环境的总体架构如图2所示，其中，包括JS引擎、渲染引擎、CSS引擎、DOM（Document Object Model，文件物件模型）、XML（eXtensibleMarkup Language，可扩展标记语言）/WML（Wireless Markup Language，无线标记语言）、WebGL（(Web Graphics Library）、设备能力、本地存储、通讯/通知、API扩展机制、插件扩展机制的Web核心部分和包括图形/字体、音视频编解码、功能接口、窗口组件/事件与网络的操作系统适配部分是目前所有浏览器与Widget引擎都具备的，但可能不具备包括运营商能力、互联网能力与终端能力的能力模块和包括安全机制、生命周期管理、应用下载与应用间通信的管理模块，也可能只实现了能力模块和管理模块中的部分能力。

在此架构中，具体地，终端能力可以包括但不限于终端设备能力、互联网能力与运营商能力。

S104，自访问对象的权限文件查询访问对象是否具有访问API的权限。

S106，响应于具有访问API的权限，查询终端能力；

在访问对象的权限文件允许该访问对象访问某一API的情况下，才能进行后续的查询与判断，这样可以确保各API的安全性。在访问对象被允许访问的情况下再查询终端是否具备该API能力。

S108，根据终端能力判断是否允许访问对象调用API；

如果终端不支持访问对象所调用的API，则确定终端不支持被调用的API，否则，则确定终端支持被调用的API。

S110，如果允许访问对象调用API，则向访问对象反馈允许调用API的信息，否则，拒绝访问对象对API的调用请求。

在该实施例中，由于在访问对象具有访问权限并在终端具备相应能力的情况下访问对象才能实现对API的调用，因此在很大程度上保证了API访问的安全性。

可选地，如果终端设备能力、互联网能力与运营商能力中各API在进行调用时需检查环境状态，则将终端设备能力、互联网能力与运营商能力中各API与相应环境状态相关联。

在一个实例中，在步骤S110之前，还可以包括以下步骤：

根据环境状态判断是否允许访问对象调用API。

进一步地，响应于终端的当前环境状态的改变，将改变后的环境状态更新到终端的内存中，使得在需要检验环境状态时能够及时获得最新的环境状态信息。

在另一实例中，在步骤S110之前，还可以包括以下步骤：

判断在对API进行调用时是否需进行二次确认；

在又一实例中，在步骤S110之前，还可以包括以下步骤：

判断API是否需进行接入认证；

在再一实例中，在步骤S110之前，还可以包括以下步骤：

判断在对API进行调用时是否需进行二次确认；

如需进行二次确认，则接收终端设备使用者反馈的信息，并根据反馈的信息和查询到的当前环境状态共同确定是否允许访问对象调用API。

在再一实例中，在步骤S110之前，还可以包括以下步骤：

判断API是否需进行接入认证；

如需进行接入认证，则根据访问对象的权限文件对API进行认证，以根据权限认证情况和查询到的当前环境状态共同确定是否允许访问对象调用API，其中，访问对象的权限文件包括访问权限和认证信息。

在再一实例中，在步骤S110之前，还可以包括以下步骤：

判断在对API进行调用时是否需进行二次确认；

如需进行二次确认，则接收终端设备使用者反馈的信息；

判断API是否需进行接入认证；

如需进行接入认证，则根据访问对象的权限文件对API进行认证，以根据权限认证情况和反馈的信息共同确定是否允许访问对象调用API，其中，访问对象的权限文件包括访问权限和认证信息。

在再一实例中，在步骤S110之前，还可以包括以下步骤：

判断在对API进行调用时是否需进行二次确认；

如需进行二次确认，则接收终端设备使用者反馈的信息；

判断API是否需进行接入认证；

如需进行接入认证，则根据访问对象的权限文件对API进行认证，以根据权限认证情况、查询到的当前环境状态与反馈的信息共同确定是否允许访问对象调用API，其中，访问对象的权限文件包括访问权限和认证信息。

本公开上述实施例采用的机制是基于BONDI（是标准组织OMTP（Open MobileTerminal Platform，开放移动终端平台组织）推出的一种终端标准）的安全体系架构与W3C（World Wide Web Consortium，万维网联盟）的Widget相关安全控制规范进行的扩展和改进。在此安全机制中包括以下几个实体概念：

（1）访问对象（subject）：指Widget应用或Web应用，即发起API调用的业务实体，其属性和API访问需求（通过<Feature>字段标注）通过Widget/Web应用配置文件表述。

（2）资源（Resource）：即设备向上提供的能力调用接口，即API调用接口，其由APIFeature列表和设备能力列表（Device Capability）组成。一个API对应一种设备能力，APIFeature包括调用接口和参数。举例说明，设备能力可以包括但不限于短信、电话与文件等，不同的终端和系统可以提供给上层应用调用的能力可能不同。有了设备能力列表后上层应用就明确了可以使用哪些能力，实现什么样的功能。

（3）环境（Environment）：设备目前的状态，例如，是否插入SIM（SubscriberIdentity Module，用户识别模块）卡、SD（Secure Digital，安全数码）卡，电量，当前运行的应用程序，是否处于联网状态，接入因特网的方式，例如，WIFI（Wireless Fidelity）、GPRS（General Packet Radio Service，通用分组无线业务）、CDMA1X（CDMA2000的第一阶段）、EVDO（CDMA20001X演进的一条路径的一个阶段），设备是否被占用等。

具体地，JS API安全访问控制机制就是在subject发起API访问需求时，根据subject的权限文件、查询资源，判断此API是否被允许。

以Web应用或Widget应用要调用打电话的API为例进行以下说明：

首先判断此应用的权限文件是否被授予了调用电话API的权限，如果没有，则直接拒绝该调用请求，如果有，则判断允许调用的方式，包括直接允许、需要用户确认等；其次，查询终端是否支持打电话的功能并查询终端的环境状态，例如，此时用户是否在打电话，如果是，则此资源处于占用状态，直接拒绝，否则判断是否需要用户进行二次确认，如果需要用户进行二次确认，则系统会弹出提示“是否允许应用＊＊调用电话功能”，如果用户选择是，则允许应用调用，否则，拒绝该调用请求。

接下来，结合图3所示的安全访问控制机制判断模型进一步详细地对安全调用API的机制进行说明。

在该模型中包括以下几个部件：

（1）PAP（Policy Administration Point，策略管理点）：可以是管理员和用户，可以为下述PDP（Policy Decision Point，策略判断点）配置权限文件；

具体地，权限文件可以配置Web应用与Widget应用的访问权限和认证信息。权限文件公用配置文件Config.xml可参考W3C Widget Packaging and XML Configuration标准。本公开基于该标准所做的扩展包括：

（a）增加API访问许可字段：访问许可由<permit>字段表示，其包括一个属性rule，rule的取值可以包括以下5种：

“Allowed”：Web应用可以直接访问函数，无须任何用户交互；

“One Show”：每一次访问函数，都要提示用户并得到确认才能访问；

“Session”：用户一次确认或拒绝Web应用访问函数以后，直到引擎结束前都有效；

“Blanket”：如果一个Web应用启动一个“Blanket”许可，用户一次确认或拒绝Web应用访问函数，以后都有效；

“Unrestricted”：与“Allowed”行为相同，但<feature>或<access>不需要在Config.xml中定义；

“Disallowed”：如果Web应用访问一个Disallowed API函数，Widget引擎必须抛出一个JavaScript安全异常，API不被调用；

（b）feature的属性扩展（即，终端能力）：扩展的feature属性包括：

network:网络

localfs:本地文件系统

plugin:插件

config:配置信息

phone:电话

videoplayer:视频播放器

camera:照相机

bt:蓝牙

calendar:日历

powerinfo:电源

irda:红外

audioplayer:音频播放器

radioinfo:无线网络信息

address:地址本

pim:PIM（Personal Information Management，个人信息管理）

positioninfo:位置信息

sms:SMS（Short Message System，短消息系统）

callrecord:呼叫记录

thirdparty：第三方互联网能力

CTC：中国电信运营商能力

消息定义如下：

feature元素包括属性required（可选，默认为true），子元素url（可选）、子元素auth（可选）。url只有在调用互联网能力或运营商能力时才有用，url表示接口的访问地址，auth里面包含了互联网能力或运营商能力的认证信息。

以前面Web应用A需要调用互联网网站提供的服务能力为例，其权限文件配置部分示例如下：

（2）PDP：此部件根据当前的策略判断web应用是否能调用某个设备的API；

PDP是JS API能否被调用的策略决定部件，在此部件中，有下面两个特点：

（a）UA（User Authentication，用户认证）的结合：策略判断点除了对终端本身的API进行判断外，还需要对终端外部的API（即，互联网服务API和运营商服务API）进行判断。在传统的处理方式中，通常将用户认证交给widget应用来处理，增加了widget应用的复杂性，同时，必须将帐号与密码等认证信息暴露给应用开发者或者是用户，这样不利于对帐号与密码的安全性进行管控。在本公开中将用户认证信息通过权限文件的方式进行下发，对用户或开发者都是不可见的。

（b）认证信息和签名机制的结合：签名机制是用来保证权限文件和web应用的资源文件不被随意篡改，此机制可同时应用在认证信息的加密上，可增强认证信息的安全性。

PDP的判断顺序为：

（i）通过权限文件判断此web应用是否具有访问此API的权限；

（ii）根据从PIP获取到的JS API信息判断是否需要用户认证，如果需要，则将认证信息发送给UA，并从UA获取认证结果；

（iii）综合各种信息，包括API权限、认证结果（如果有）、JS API信息、环境状态，判断web应用是否可访问此API，例如，允许，需要用户确认、拒绝等。

（3）PEP（Policy Execution Point，策略执行点）：此部件接收用户的访问请求和返回判断结果。

（4）PIP（Policy Information Point，策略信息点）：此部件负责收集资源（Resource）文件和环境（Environment）文件；

其中，资源文件保存设备可支持的JS API列表，由于JS API采用分级架构，例如，widget.device、widget.device.camera等，在系统实现中采用树结构来存取JS API列表。

环境文件记录了设备的状态、设备的占用情况等。不同的JS API对环境的查询需求不一样，因此，环境文件的生成也由API的需求导入。例如，打电话的JS API，它的需求是要查询是否有UIM卡和用户是否在打电话，因此在环境文件，如下列条件时才能调用此API：UIMEnable=TRUE，IsBusy=FALSE。此外，环境文件可以采用key-value的结构来组织和存储，例如，GPSEnable＝TRUE，UIMEnable＝TRUE，IsBusy＝FALSE。

PIP为加快信息的查询速度采用以下的处理方式：

（i）PIP启动后，将环境文件读取到内存中，并注册环境的更新通知，同时将JS API的资源文件映射到内存树结构中；

（ii）当环境发生改变时，根据PIP注册的回调事件通知到PIP部件，PIP修改内存中的环境文件，其中，可以通过轮询和捕获设备的系统通知的方式获知环境的改变；

（iii）当Context Handler（上下文处理器）请求JS API的信息时，PIP在资源树中查询此JS API是否支持等，并在内存JS API访问列表中增加一条记录，记录此JS API的状态以及指向此JS API结构体的指针，以提高查询效率。

经过上述处理后，每当一个请求到来时，PIP的处理流程为：

（i）查询内存中的JS API访问列表；

（ii）如果访问列表中存在此记录，则直接根据记录中的指针找到JS API结构体，获得此JS API是否被支持、参数以及是否需要查询环境状态等信息，如果需要查询环境条件，则执行第（iv）步，如果不需要，则直接返回JS API的信息；

（iii）如果访问列表中不存在此记录，则在资源树中查询此JS API，获得此JS API的信息，并在JS API访问列表中增加一条记录，如果此JS API需要查询环境条件，则执行第（iv）步，否则，直接返回JS API的信息；

（iv）查询内存中的环境key-value对，查询环境状态，将JS API信息和环境状态一并返回，其中，环境文件中的key-value是公用的，和JS API是多对多的关系，例如，打电话的JS API和发短信的JS API都是要询问设备是否插有UIM卡。

（5）UAP（User Authentication Point，用户认证点）：此部件负责第三方服务器（包括互联网服务提供平台和运营商平台）需要对用户认证时的用户认证流程。

下面再参见图3通过一个具体实例说明访问权限判断流程。

例如，运行在移动设备上的Web应用A需要调用某互联网网站提供的服务能力，目的是获取新闻信息。判断流程如下：

（1）可以由PAP将权限文件下发到Widget引擎/web应用运行环境，即图3中的PDP，其中的权限为：web应用A可以访问新闻信息接口API，但需提示用户；

（2）Web应用A作为访问请求者（Access Requester）发起API调用请求；

（3）PEP向上下文处理器询问web应用A是否具有访问权限；

（4）上下文处理器询问PDP web应用A是否可访问此API；

（5）PDP接收到该询问后向上下文处理器请求获得移动设备能力和移动设备的环境状态；

（6）上下文处理器将该请求转发到PIP；

（7）PIP获取移动终端能力，包括设备是否支持此互联网能力API，参数等并查询设备的环境状态，例如，目前是否联网等；

（8）PIP将搜集到的信息返回上下文处理器；

（9）上下文处理器将信息提交到PDP，PDP判断此API是否为互联网能力API并且判断第三方服务商是否需要进行接入认证；

（10）如是互联网能力API并需进行接入认证，则将自PAP获得的用户认证信息发送给UAP；

（11）UAP将认证结果反馈给PDP；

（12）PDP根据UAP反馈的认证结果、权限文件以及用户是否认证等信息共同确定是否允许访问该API并将结果返回给上下文处理器，其中，在进行用户认证时，提示用户是否允许Web应用A访问网络并接收用户输入的认证信息，在UAP反馈认证通过、权限文件允许以及用户认证通过的情况下才允许访问移动设备上的该API；

（13）上下文处理器将是否允许访问该API的信息反馈给PEP。

本领域普通技术人员可以理解，实现上述方法实施例的全部和部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算设备可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤，而前述的存储介质可以包括ROM、RAM、磁碟和光盘等各种可以存储程序代码的介质。

如图4所示，该实施例中的装置40可以包括API调用请求接收单元402、API访问权限查询单元404、终端能力查询单元406、调用判断单元408和判断结果反馈单元410。其中，

API调用请求接收单元402，用于接收访问对象发起的对一应用程序接口API的调用请求，其中，访问对象为Widget应用或Web应用；

API访问权限查询单元404，用于自访问对象的权限文件查询访问对象是否具有访问API的权限；

终端能力查询单元406，用于响应于具有访问API的权限，查询终端能力，其中，终端能力可以包括但不限于终端设备能力、互联网能力与运营商能力；

调用判断单元408，用于根据终端能力判断是否允许访问对象调用API；

判断结果反馈单元410，用于如果允许访问对象调用API，则向访问对象反馈允许调用API的信息，否则，拒绝访问对象对API的调用请求。

如图5所示，与图4中的实施例相比，该实施例中的装置50还可以包括：

能力状态关联单元502，用于如果终端设备能力、互联网能力与运营商能力中各API在进行调用时需检查环境状态，则将终端设备能力、互联网能力与运营商能力中各API与相应环境状态相关联。

如图6所示，与图5中的实施例相比，该实施例中的装置60还可以包括：

环境状态查询单元602，用于响应于具有访问API的权限，根据终端设备能力、互联网能力与运营商能力中各API与相应环境状态的关联关系判断在调用API时是否需检查环境状态，如需检查环境状态，则到终端的内存中查询终端的当前环境状态；

如图7所示，与图6中的实施例相比，该实施例中的装置70还可以包括：

环境状态更新单元702，用于响应于终端的当前环境状态的改变，将改变后的环境状态更新到终端的内存中。

进一步地，调用判断单元还判断在对API进行调用时是否需进行二次确认，如需进行二次确认，则接收终端设备使用者反馈的信息，并根据反馈的信息确定是否允许访问对象调用API。

进一步地，调用判断单元还判断API是否需进行接入认证，如需进行接入认证，则根据访问对象的权限文件对API进行认证，以确定是否允许访问对象调用API，其中，访问对象的权限文件包括访问权限和认证信息。

需要指出的是，可以将上述实施例的功能设置在图2所示的管理模块中的安全机制中，可以集成到Widget引擎中或其他基于本地浏览器核心扩展的Web运行环境中。

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

虽然已参照示例性实施例描述了本公开，但应理解，本公开不限于上述的示例性实施例。对于本领域技术人员显然的是，可以在不背离本公开的范围和精神的条件下修改上述的示例性实施例。所附的权利要求的范围应被赋予最宽的解释，以包含所有这样的修改以及等同的结构和功能。

Claims

1.一种实现JS应用程序接口安全访问控制的方法，其特征在于，包括：

接收访问对象发起的对一应用程序接口API的调用请求；

自所述访问对象的权限文件查询所述访问对象是否具有访问所述API的权限；

响应于具有访问所述API的权限，查询终端能力，其中，所述终端能力包括终端设备能力、互联网能力与运营商能力，如果所述终端设备能力、所述互联网能力与所述运营商能力中各API在进行调用时需检查环境状态，则将所述终端设备能力、所述互联网能力与所述运营商能力中各API与相应环境状态相关联；

判断在对所述API进行调用时是否需进行二次确认；

如需进行二次确认，则接收终端设备使用者反馈的信息，并根据反馈的信息和所述终端能力判断是否允许所述访问对象调用所述API；

如果允许所述访问对象调用所述API，则向所述访问对象反馈允许调用所述API的信息，否则，拒绝所述访问对象对所述API的调用请求。

2.根据权利要求1所述的实现JS应用程序接口安全访问控制的方法，其特征在于，所述访问对象为Widget应用或Web应用。

3.根据权利要求1所述的实现JS应用程序接口安全访问控制的方法，其特征在于，所述方法还包括：

响应于具有访问所述API的权限，根据所述终端设备能力、所述互联网能力与所述运营商能力中各API与相应环境状态的关联关系判断在调用所述API时是否需检查环境状态；

根据所述环境状态判断是否允许所述访问对象调用所述API。

4.根据权利要求3所述的实现JS应用程序接口安全访问控制的方法，其特征在于，所述方法还包括：

响应于终端的当前环境状态的改变，将改变后的环境状态更新到所述终端的内存中。

5.根据权利要求1所述的实现JS应用程序接口安全访问控制的方法，其特征在于，所述方法还包括：

判断所述API是否需进行接入认证；

如需进行接入认证，则根据所述访问对象的权限文件对所述API进行认证，以确定是否允许所述访问对象调用所述API，其中，所述访问对象的权限文件包括访问权限和认证信息。

6.一种实现JS应用程序接口安全访问控制的装置，其特征在于，包括：

API访问权限查询单元，用于自所述访问对象的权限文件查询所述访问对象是否具有访问所述API的权限；

终端能力查询单元，用于响应于具有访问所述API的权限，查询终端能力，其中，所述终端能力包括终端设备能力、互联网能力与运营商能力；

调用判断单元，用于判断在对所述API进行调用时是否需进行二次确认，如需进行二次确认，则接收终端设备使用者反馈的信息，并根据反馈的信息和所述终端能力判断是否允许所述访问对象调用所述API；

判断结果反馈单元，用于如果允许所述访问对象调用所述API，则向所述访问对象反馈允许调用所述API的信息，否则，拒绝所述访问对象对所述API的调用请求；

其中，所述装置还包括：

能力状态关联单元，用于如果所述终端设备能力、所述互联网能力与所述运营商能力中各API在进行调用时需检查环境状态，则将所述终端设备能力、所述互联网能力与所述运营商能力中各API与相应环境状态相关联。

7.根据权利要求6所述的实现JS应用程序接口安全访问控制的装置，其特征在于，所述访问对象为Widget应用或Web应用。

8.根据权利要求6所述的实现JS应用程序接口安全访问控制的装置，其特征在于，所述装置还包括：

环境状态查询单元，用于响应于具有访问所述API的权限，根据所述终端设备能力、所述互联网能力与所述运营商能力中各API与相应环境状态的关联关系判断在调用所述API时是否需检查环境状态，如需检查环境状态，则到终端的内存中查询终端的当前环境状态；

所述调用判断单元还根据所述环境状态判断是否允许所述访问对象调用所述API。

9.根据权利要求8所述的实现JS应用程序接口安全访问控制的装置，其特征在于，所述装置还包括：

环境状态更新单元，用于响应于终端的当前环境状态的改变，将改变后的环境状态更新到所述终端的内存中。

10.根据权利要求6所述的实现JS应用程序接口安全访问控制的装置，其特征在于，所述调用判断单元还判断所述API是否需进行接入认证，如需进行接入认证，则根据所述访问对象的权限文件对所述API进行认证，以确定是否允许所述访问对象调用所述API，其中，所述访问对象的权限文件包括访问权限和认证信息。