本申請涉及計算機軟件技術(shù)領(lǐng)域，尤其涉及插件權(quán)限控制方法及裝置、插件系統(tǒng)。

背景技術(shù)：

隨著應(yīng)用(application，app)功能的豐富，很多大型app都使用了大量插件，這些插件可以擴展或加強其所屬的app的功能，比如，瀏覽器功能、多媒體處理功能等。

在現(xiàn)有技術(shù)中，當app使用的插件中存在漏洞時，可導(dǎo)致整個app也存在該漏洞，則可能對該app造成安全威脅。另外，當插件本身有較大版本更新時，其所屬的app往往還很難快速的進行版本更新迭代，這也就導(dǎo)致了app所使用的插件中可能存在很多歷史遺留安全問題。

因此，急需一種有效方案來解決app使用插件而引入的安全威脅。

技術(shù)實現(xiàn)要素：

本申請實施例提供插件權(quán)限控制方法及裝置、插件系統(tǒng)，用以解決現(xiàn)有技術(shù)中app使用插件而引入安全威脅的問題。

為解決上述技術(shù)問題，本申請實施例是這樣實現(xiàn)的：

本申請實施例提供的一種插件權(quán)限控制方法，所述方法應(yīng)用于應(yīng)用app，所述app中包括插件權(quán)限控制器、一個或多個插件沙箱，所述方法包括：

所述插件權(quán)限控制器接收所述插件沙箱發(fā)送的應(yīng)用程序編程接口api調(diào)用請求，其中，所述api調(diào)用請求是所述插件沙箱中插件的api調(diào)用請求，由所述插件沙箱攔截得到；

所述插件權(quán)限控制器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

本申請實施例提供的一種插件權(quán)限控制裝置，所述裝置應(yīng)用于應(yīng)用app，所述app中包括插件權(quán)限控制器、一個或多個插件沙箱，所述裝置位于所述插件權(quán)限控制器，包括：

接收模塊，接收所述插件沙箱發(fā)送的應(yīng)用程序編程接口api調(diào)用請求，其中，所述api調(diào)用請求是所述插件沙箱中插件的api調(diào)用請求，由所述插件沙箱攔截得到；

控制模塊，確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

本申請實施例提供的另一種插件權(quán)限控制方法，所述方法應(yīng)用于應(yīng)用app，所述app中包括插件權(quán)限控制器、一個或多個插件沙箱，所述方法包括：

所述插件沙箱攔截所述插件沙箱中插件的應(yīng)用程序編程接口api調(diào)用請求；

所述插件沙箱將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器，以便于所述插件權(quán)限控制器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

本申請實施例提供的另一種插件權(quán)限控制裝置，所述裝置應(yīng)用于應(yīng)用app，所述app中包括插件權(quán)限控制器、一個或多個插件沙箱，所述裝置位于所述插件沙箱，包括：

攔截模塊，攔截所述插件沙箱中插件的應(yīng)用程序編程接口api調(diào)用請求；

發(fā)送模塊，將所述攔截模塊攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器，以便于所述插件權(quán)限控制器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

本申請實施例提供的一種插件系統(tǒng)，所述插件系統(tǒng)應(yīng)用于應(yīng)用app，包括插件權(quán)限控制器、一個或多個插件沙箱；

所述插件沙箱，攔截所述插件沙箱中插件的應(yīng)用程序編程接口api調(diào)用請求，并將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器；

所述插件權(quán)限控制器，確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

本申請實施例采用的上述至少一個技術(shù)方案能夠達到以下有益效果：可以實現(xiàn)app本身的權(quán)限與app的插件的權(quán)限相互隔離，即便app使用了存在漏洞的插件，也可以使插件無法獲取到整個app的權(quán)限，可以降低插件的漏洞對app本身的影響，可以減少app使用插件而引入的安全威脅，因此，可以部分或全部地解決現(xiàn)有技術(shù)中的問題。

附圖說明

為了更清楚地說明本申請實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請中記載的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為本申請實施例提供的一種插件系統(tǒng)的架構(gòu)示意圖；

圖2為本申請實施例提供的圖1中的插件系統(tǒng)的一種詳細架構(gòu)示意圖；

圖3為本申請實施例提供的一種插件權(quán)限控制方法的流程示意圖；

圖4為本申請實施例提供的另一種插件權(quán)限控制方法的流程示意圖；

圖5為本申請實施例提供的對應(yīng)于圖3的一種插件權(quán)限控制裝置的結(jié)構(gòu)示意圖；

圖6為本申請實施例提供的對應(yīng)于圖3的一種插件權(quán)限控制裝置的結(jié)構(gòu)示意圖。

具體實施方式

本申請實施例提供插件權(quán)限控制方法及裝置、插件系統(tǒng)。

為了使本技術(shù)領(lǐng)域的人員更好地理解本申請中的技術(shù)方案，下面將結(jié)合本申請實施例中的附圖，對本申請實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應(yīng)當屬于本申請保護的范圍。

圖1為本申請實施例提供的一種插件系統(tǒng)的架構(gòu)示意圖，所述插件系統(tǒng)應(yīng)用于應(yīng)用app，包括插件權(quán)限控制器101、一個或多個插件沙箱102；

所述插件沙箱101，攔截所述插件沙箱中插件的應(yīng)用程序編程接口(applicationprogramminginterface，api)調(diào)用，并將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器；

所述插件權(quán)限控制器102，確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

簡明起見，以下可以省略插件沙箱101和插件權(quán)限控制器102的數(shù)字標號。

在本申請實施例中，每個插件沙箱可以對應(yīng)于app的一個或多個插件，為了減少插件之間的相互影響，每個插件沙箱優(yōu)選地可以對應(yīng)于app的一個插件。

以電子支付app為例，電子支付app可以有諸如商品推薦插件、社交評論插件、比價插件等。在現(xiàn)有技術(shù)中，這些插件的權(quán)限即為電子支付app本身的權(quán)限，插件針對app本身可以不受限制地進行api調(diào)用，插件針對app所在系統(tǒng)可以僅在app的權(quán)限的限制下進行api調(diào)用，比如，商品推薦插件的正常功能是進行商品推薦；但是，也有可能具有竊取用戶支付相關(guān)敏感數(shù)據(jù)的惡意功能(這些功能都是通過插件進行的api調(diào)用實現(xiàn)的)，或者，雖然商品推薦插件本身不具有惡意功能，但若商品推薦插件存在漏洞，也可能使得第三方惡意程序通過該漏洞竊取用戶支付相關(guān)敏感數(shù)據(jù)，由此導(dǎo)致背景技術(shù)中提到的問題。

在本申請實施例中，插件可以在其對應(yīng)的插件沙箱中安全運行，而且基于插件權(quán)限控制器的權(quán)限控制，插件可以在符合一定安全策略的前提下，針對app本身或?qū)pp所在系統(tǒng)的進行api調(diào)用(某些api調(diào)用請求可能被拒絕)，在這種情況下，插件的權(quán)限與app本身的權(quán)限是相互隔離的，因此，可以有針對性地對插件的權(quán)限進行控制，而又不至于影響app本身的權(quán)限，從而使得app既能使用插件的正常功能，又能阻止插件可能帶來安全威脅的敏感api調(diào)用。

通過圖1的插件系統(tǒng)，可以實現(xiàn)app本身的權(quán)限與app的插件的權(quán)限相互隔離，即便app使用了存在漏洞的插件，也可以使插件無法獲取到整個app的權(quán)限，可以降低插件的漏洞對app本身的影響，可以減少app使用插件而引入的安全威脅，因此，可以部分或全部地解決現(xiàn)有技術(shù)中的問題。

基于圖1的插件系統(tǒng)，本申請實施例還提供了該插件系統(tǒng)的一些具體實施方案，以及擴展方案，下面進行說明。

在本申請實施例中，插件沙箱具有可模擬的進程級別的粒度，則每個插件被沙箱化后，是在一個獨立的模擬進程中運行的，如此有利于實現(xiàn)插件與app間的權(quán)限隔離，以及插件與插件間的權(quán)限隔離。在這種情況下，插件沙箱與插件權(quán)限控制器之間是通過進程間通信的方式進行通信交互的?；诖耍梢詫Σ寮诚?、插件權(quán)限控制器進一步地細分模塊。

具體地，所述插件沙箱可以包括攔截控制器、進程間通信第一端；所述插件權(quán)限控制器可以包括調(diào)用攔截管理器、進程間通信第二端。

所述插件沙箱攔截所述插件沙箱中插件的api調(diào)用請求，并將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器，具體可以包括：所述攔截控制器攔截所述插件沙箱中插件的api調(diào)用請求，并通過所述進程間通信第一端，將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器。

所述插件權(quán)限控制器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用，具體可以包括：所述進程間通信第二端接收所述插件沙箱發(fā)送的所述api調(diào)用請求；所述調(diào)用攔截管理器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

在實際應(yīng)用中，進程間通信第一端與進程間通信第二端可以是具有從屬關(guān)系的通信端，也可以是對等的通信端。以前一種情況為例，進程間通信第一端具體可以是進程間通信客戶端，進程間通信第二端具體可以是進程間通信服務(wù)端。

在本申請實施例中，插件的權(quán)限并非直接是app的權(quán)限，而是需要插件權(quán)限控制器按照一定的策略分別對各插件的權(quán)限進行控制，比如，策略中可以指定：某插件具有進行哪些api調(diào)用的權(quán)限、某插件不具有進行哪些api調(diào)用的權(quán)限等。

基于此，插件權(quán)限控制器中可以有負責管理所要使用的策略的模塊。

例如，所述插件權(quán)限控制器還可以包括：策略引擎管理器，設(shè)定所述調(diào)用攔截管理器確定所述插件沙箱中插件的權(quán)限時所根據(jù)的策略；在這種情況下，所述調(diào)用攔截管理器確定所述插件的權(quán)限，具體可以包括：所述調(diào)用攔截管理器根據(jù)所述策略引擎管理器設(shè)定的策略，確定所述插件的權(quán)限；其中，所述策略引擎管理器是根據(jù)所述策略引擎管理器預(yù)先接收的策略設(shè)定第一指令而設(shè)定策略的。

為了便于理解，對“策略設(shè)定第一指令”進行說明。策略設(shè)定第一指令是直接針對策略引擎管理器下達的指令。

策略設(shè)定第一指令的具體下達方式可以有多種，列舉兩種：

第一種，用戶可以通過在app所提供的策略引擎管理器的可視界面中進行操作，以下達策略設(shè)定第一指令，比如，該可視界面中可以提供若干可選的策略，用戶可以通過進行在這些可選的策略中選定一項或多項策略并確認的操作，下達策略設(shè)定第一指令，相應(yīng)地，策略引擎管理器會把用戶選定確認的這些策略設(shè)定為要使用的策略。這種方式的優(yōu)點是：用戶自主控制性較好。

第二種，可以由app對應(yīng)的服務(wù)器側(cè)向用戶側(cè)的策略引擎管理器下達策略設(shè)定第一指令。這種方式的優(yōu)點是：無需用戶干預(yù)，而是由服務(wù)器側(cè)的專業(yè)人員把控，有利于及時有效地阻止插件引入的安全威脅。

在本申請實施例中，所述插件權(quán)限控制器還可以包括：策略中心，包含預(yù)定的各策略；所述策略引擎管理器是根據(jù)所述策略中心包含的各策略而設(shè)定策略的，所述策略引擎管理器設(shè)定的策略包括所述各策略中的一項或多項。在實際應(yīng)用中，策略中心也可以內(nèi)置于策略引擎管理器中。

策略中心的存在使得各種可能使用的策略可以預(yù)先被整理，以備不時之需，而不是只要策略有變，就需要更新app或者從服務(wù)端獲取變更的策略，因此，有利于減輕app的處理負擔。

在本申請實施例中，不同的插件可能對應(yīng)于不同的權(quán)限策略，為了便于對不同的插件差異化地設(shè)定(初次設(shè)定、或后續(xù)設(shè)定變更)，也可以從插件沙箱向插件權(quán)限控制器發(fā)送請求，以請求對該插件對應(yīng)的策略進行設(shè)定。

例如，插件沙箱可以包括策略引擎客戶端，且可以將插件權(quán)限控制器的策略引擎管理器作為策略引擎客戶端的服務(wù)端。進一步地，所述策略引擎客戶端當接收到策略設(shè)定第二指令時，根據(jù)所述策略設(shè)定第二指令，向所述策略引擎管理器發(fā)送策略設(shè)定請求，以使策略引擎管理器根據(jù)所述策略設(shè)定請求設(shè)定策略。

策略設(shè)定第二指令類似于上述的策略設(shè)定第一指令，主要區(qū)別在于：策略設(shè)定第一指令是直接針對插件權(quán)限控制器的，而策略設(shè)定第二指令是直接針對插件沙箱的?；谶@兩種指令中任一種指令對應(yīng)的策略設(shè)定方式，可以便利地進行策略定制以及策略變更，而且對于線下或線上都是適用的。

在本申請實施例中，所述調(diào)用攔截管理器當確定執(zhí)行所述api調(diào)用時，根據(jù)所述插件的權(quán)限對應(yīng)的預(yù)定執(zhí)行方式，執(zhí)行所述api調(diào)用以及返回執(zhí)行結(jié)果，否則，拒絕所述api調(diào)用請求。

對于某些可能威脅app安全的敏感api調(diào)用的請求，可以通過相應(yīng)的策略限制權(quán)限，以使這些敏感api調(diào)用不會被執(zhí)行，從而有利于阻止插件引入的安全威脅。

進一步地，對于被確定為可以執(zhí)行的api調(diào)用，也可以根據(jù)具體情況差異化地執(zhí)行，以實現(xiàn)“安全執(zhí)行”。比如，對于可信(比如，權(quán)限相對較高的)的api調(diào)用，可以直接執(zhí)行；對于部分可信(比如，權(quán)限相對較低的)的api調(diào)用，可以針對其執(zhí)行一些限制措施(比如，可以通過修改api調(diào)用參數(shù)，使得該api調(diào)用涉及的app資源被重定向等)后再執(zhí)行。

進一步地，為了避免插件的某些敏感api調(diào)用未被執(zhí)行而導(dǎo)致插件或app異常，插件沙箱還可以包括異常處理器，異常處理器可以對所述api調(diào)用未被執(zhí)行而引發(fā)的異常進行處理，如此，有利于減少app運行受到的影響。

根據(jù)上面的說明，更直觀地，本申請實施例提供了圖1中的插件系統(tǒng)的一種詳細架構(gòu)示意圖，如圖2所示。

在圖2中，插件權(quán)限控制器101可以包括：進程間通信第一端1011、調(diào)用攔截管理器1012、策略引擎管理器1013、策略中心1014；插件沙箱102可以包括進程間通信第二端1021、攔截控制器1022、策略引擎客戶端1023、異常處理器1024。

需要說明的是，圖2中的插件權(quán)限控制器101、插件沙箱102中各模塊之間的連接僅是一種示例，并非限定，采用其他連接方式也可以，只要能實現(xiàn)模塊之間直接或間接的通信即可。

圖1、圖2中各模塊的劃分也是示例，也可以采用其他模塊劃分方法，能夠?qū)崿F(xiàn)這些模塊的功能即可。基于同樣的發(fā)明思路，本申請實施例還提供了對應(yīng)的插件權(quán)限控制方法，方法主要描述上述功能，而不限定模塊的劃分，由于上面對上述功能已經(jīng)進行詳細說明，簡明起見，下面結(jié)合圖3、圖4僅對插件權(quán)限控制方法進行簡單說明。

圖3為本申請實施例提供的一種插件權(quán)限控制方法的流程示意圖。圖3的方法應(yīng)用于app，app中包括插件權(quán)限控制器、一個或多個插件沙箱。

圖3中的流程的執(zhí)行主體是插件權(quán)限控制器，主要包括以下步驟：

s301：所述插件權(quán)限控制器接收所述插件沙箱發(fā)送的api調(diào)用請求，其中，所述api調(diào)用請求是所述插件沙箱中插件的api調(diào)用請求，由所述插件沙箱攔截得到。

s302：所述插件權(quán)限控制器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

基于圖3的方法，本申請實施例還提供了該方法的一些具體實施方案，以及擴展方案，下面進行說明。

在本申請實施例中，對于步驟s301，所述插件權(quán)限控制器接收所述插件沙箱發(fā)送的api調(diào)用請求，具體可以包括：所述插件權(quán)限控制器通過進程間通信，接收所述插件沙箱發(fā)送的api調(diào)用請求。

在本申請實施例中，對于步驟s302，所述插件權(quán)限控制器確定所述插件的權(quán)限，具體可以包括：所述插件權(quán)限控制器根據(jù)設(shè)定的策略，確定所述插件的權(quán)限；其中，所述設(shè)定的策略由所述插件權(quán)限控制器根據(jù)預(yù)先接收的策略設(shè)定第一指令而設(shè)定。

在本申請實施例中，所述插件權(quán)限控制器內(nèi)有包含預(yù)定的各策略的策略中心，所述插件權(quán)限控制器是根據(jù)所述策略中心包含的各策略而設(shè)定策略的，所述策略引擎管理器設(shè)定的策略包括所述各策略中的一項或多項。

在本申請實施例中，對于圖3中的流程，還可以執(zhí)行：所述插件權(quán)限控制器接收所述插件沙箱發(fā)送的策略設(shè)定請求，所述策略設(shè)定請求是所述插件沙箱根據(jù)接收到的策略設(shè)定第二指令發(fā)送的；所述插件權(quán)限控制器根據(jù)所述策略設(shè)定請求設(shè)定策略。

在本申請實施例中，對于步驟s302，若所述插件權(quán)限控制器確定執(zhí)行所述api調(diào)用后，可以執(zhí)行：所述插件權(quán)限控制器根據(jù)所述插件的權(quán)限對應(yīng)的預(yù)定執(zhí)行方式，執(zhí)行所述api調(diào)用；

若所述插件權(quán)限控制器確定不執(zhí)行所述api調(diào)用，可以執(zhí)行：所述插件權(quán)限控制器拒絕所述api調(diào)用請求。

圖4為本申請實施例提供的另一種插件權(quán)限控制方法的流程示意圖。圖4的方法應(yīng)用于app，app中包括插件權(quán)限控制器、一個或多個插件沙箱。

圖4中的流程的執(zhí)行主體是插件沙箱，主要包括以下步驟：

s401：所述插件沙箱攔截所述插件沙箱中插件的api調(diào)用請求。

s402：所述插件沙箱將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器，以便于所述插件權(quán)限控制器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

基于圖4的方法，本申請實施例還提供了該方法的一些具體實施方案，以及擴展方案，下面進行說明。

在本申請實施例中，對于步驟s402，所述插件沙箱將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器，具體可以包括：所述插件沙箱通過進程間通信，將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器。

在本申請實施例中，對于圖4中的流程，還可以執(zhí)行：所述插件沙箱接收到策略設(shè)定第二指令；所述插件沙箱根據(jù)所述策略設(shè)定第二指令向所述插件權(quán)限控制器發(fā)送策略設(shè)定請求，以使所述插件權(quán)限控制器根據(jù)所述策略設(shè)定請求設(shè)定策略，以用于確定所述插件沙箱中插件的權(quán)限。需要說明的是，該步驟可以是預(yù)先執(zhí)行的，若不是預(yù)先則執(zhí)行的，則通過執(zhí)行該步驟所設(shè)定的策略只能用于確定以后插件沙箱再發(fā)送的api調(diào)用請求對應(yīng)的插件權(quán)限。

在本申請實施例中，對于步驟s402，所述插件沙箱將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器后，若確定所述api調(diào)用不被執(zhí)行，還可以執(zhí)行：所述插件沙箱對所述api調(diào)用未被執(zhí)行而引發(fā)的異常進行處理。

進一步地，基于同樣的發(fā)明思路，本申請實施例還提供了上述插件權(quán)限控制方法對應(yīng)的裝置，結(jié)合圖5、圖6進行說明。

圖5為本申請實施例提供的對應(yīng)于圖3的一種插件權(quán)限控制裝置的結(jié)構(gòu)示意圖。該裝置應(yīng)用于應(yīng)用app，所述app中包括插件權(quán)限控制器、一個或多個插件沙箱，該裝置位于所述插件權(quán)限控制器，包括：

接收模塊501，接收所述插件沙箱發(fā)送的應(yīng)用程序編程接口api調(diào)用請求，其中，所述api調(diào)用請求是所述插件沙箱中插件的api調(diào)用請求，由所述插件沙箱攔截得到；

控制模塊502，確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

可選地，所述接收模塊501接收所述插件沙箱發(fā)送的api調(diào)用請求，具體包括：

所述接收模塊501通過進程間通信，接收所述插件沙箱發(fā)送的api調(diào)用請求。

可選地，所述控制模塊502確定所述插件的權(quán)限，具體包括：

所述控制模塊502根據(jù)設(shè)定的策略，確定所述插件的權(quán)限；

其中，所述設(shè)定的策略由所述插件權(quán)限控制器根據(jù)預(yù)先接收的策略設(shè)定第一指令而設(shè)定。

可選地，所述插件權(quán)限控制器內(nèi)有包含預(yù)定的各策略的策略中心，所述插件權(quán)限控制器是根據(jù)所述策略中心包含的各策略而設(shè)定策略的，所述策略引擎管理器設(shè)定的策略包括所述各策略中的一項或多項。

可選地，所述裝置還包括：

設(shè)定模塊503，接收所述插件沙箱發(fā)送的策略設(shè)定請求，所述策略設(shè)定請求是所述插件沙箱根據(jù)接收到的策略設(shè)定第二指令發(fā)送的，根據(jù)所述策略設(shè)定請求設(shè)定策略。

可選地，所述控制模塊502若確定執(zhí)行所述api調(diào)用，根據(jù)所述插件的權(quán)限對應(yīng)的預(yù)定執(zhí)行方式，執(zhí)行所述api調(diào)用；

所述控制模塊502若確定不執(zhí)行所述api調(diào)用，拒絕所述api調(diào)用請求。

圖6為本申請實施例提供的對應(yīng)于圖4的一種插件權(quán)限控制裝置的結(jié)構(gòu)示意圖。該裝置應(yīng)用于應(yīng)用app，所述app中包括插件權(quán)限控制器、一個或多個插件沙箱，該裝置位于所述插件沙箱，包括：

攔截模塊601，攔截所述插件沙箱中插件的應(yīng)用程序編程接口api調(diào)用請求；

發(fā)送模塊602，將所述攔截模塊601攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器，以便于所述插件權(quán)限控制器確定所述插件的權(quán)限，并根據(jù)所述插件的權(quán)限，確定是否執(zhí)行所述api調(diào)用。

可選地，所述攔截模塊601攔截其對應(yīng)的插件的應(yīng)用程序編程接口api調(diào)用請求，具體包括：

所述攔截模塊601通過進程間通信，將攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器。

可選地，所述裝置還包括：

設(shè)定模塊603，所述設(shè)定模塊到策略設(shè)定第二指令，根據(jù)所述策略設(shè)定第二指令向所述插件權(quán)限控制器發(fā)送策略設(shè)定請求，以使所述插件權(quán)限控制器根據(jù)所述策略設(shè)定請求設(shè)定策略，以用于確定所述插件沙箱中插件的權(quán)限。

可選地，所述裝置還包括：

異常處理模塊604，在所述發(fā)送模塊將所述攔截模塊攔截的所述api調(diào)用請求發(fā)送給所述插件權(quán)限控制器后，若確定所述api調(diào)用不被執(zhí)行，對所述api調(diào)用未被執(zhí)行而引發(fā)的異常進行處理。

本申請實施例提供的系統(tǒng)、方法與裝置是一一對應(yīng)的，因此，方法、裝置也具有與其對應(yīng)的系統(tǒng)類似的有益技術(shù)效果，由于上面已經(jīng)對系統(tǒng)的有益技術(shù)效果進行了詳細說明，因此，這里不再贅述對應(yīng)方法、裝置的有益技術(shù)效果。

本申請實施例中所述支付涉及的技術(shù)載體，例如可以包括近場通信(nearfieldcommunication，nfc)、wifi、3g/4g/5g、pos機刷卡技術(shù)、二維碼掃碼技術(shù)、條形碼掃碼技術(shù)、藍牙、紅外、短消息(shortmessageservice，sms)、多媒體消息(multimediamessageservice，mms)等。

在20世紀90年代，對于一個技術(shù)的改進可以很明顯地區(qū)分是硬件上的改進(例如，對二極管、晶體管、開關(guān)等電路結(jié)構(gòu)的改進)還是軟件上的改進(對于方法流程的改進)。然而，隨著技術(shù)的發(fā)展，當今的很多方法流程的改進已經(jīng)可以視為硬件電路結(jié)構(gòu)的直接改進。設(shè)計人員幾乎都通過將改進的方法流程編程到硬件電路中來得到相應(yīng)的硬件電路結(jié)構(gòu)。因此，不能說一個方法流程的改進就不能用硬件實體模塊來實現(xiàn)。例如，可編程邏輯器件(programmablelogicdevice,pld)(例如現(xiàn)場可編程門陣列(fieldprogrammablegatearray，fpga))就是這樣一種集成電路，其邏輯功能由用戶對器件編程來確定。由設(shè)計人員自行編程來把一個數(shù)字系統(tǒng)“集成”在一片pld上，而不需要請芯片制造廠商來設(shè)計和制作專用的集成電路芯片。而且，如今，取代手工地制作集成電路芯片，這種編程也多半改用“邏輯編譯器(logiccompiler)”軟件來實現(xiàn)，它與程序開發(fā)撰寫時所用的軟件編譯器相類似，而要編譯之前的原始代碼也得用特定的編程語言來撰寫，此稱之為硬件描述語言(hardwaredescriptionlanguage，hdl)，而hdl也并非僅有一種，而是有許多種，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)與verilog。本領(lǐng)域技術(shù)人員也應(yīng)該清楚，只需要將方法流程用上述幾種硬件描述語言稍作邏輯編程并編程到集成電路中，就可以很容易得到實現(xiàn)該邏輯方法流程的硬件電路。

控制器可以按任何適當?shù)姆绞綄崿F(xiàn)，例如，控制器可以采取例如微處理器或處理器以及存儲可由該(微)處理器執(zhí)行的計算機可讀程序代碼(例如軟件或固件)的計算機可讀介質(zhì)、邏輯門、開關(guān)、專用集成電路(applicationspecificintegratedcircuit，asic)、可編程邏輯控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存儲器控制器還可以被實現(xiàn)為存儲器的控制邏輯的一部分。本領(lǐng)域技術(shù)人員也知道，除了以純計算機可讀程序代碼方式實現(xiàn)控制器以外，完全可以通過將方法步驟進行邏輯編程來使得控制器以邏輯門、開關(guān)、專用集成電路、可編程邏輯控制器和嵌入微控制器等的形式來實現(xiàn)相同功能。因此這種控制器可以被認為是一種硬件部件，而對其內(nèi)包括的用于實現(xiàn)各種功能的裝置也可以視為硬件部件內(nèi)的結(jié)構(gòu)。或者甚至，可以將用于實現(xiàn)各種功能的裝置視為既可以是實現(xiàn)方法的軟件模塊又可以是硬件部件內(nèi)的結(jié)構(gòu)。

上述實施例闡明的系統(tǒng)、裝置、模塊或單元，具體可以由計算機芯片或?qū)嶓w實現(xiàn)，或者由具有某種功能的產(chǎn)品來實現(xiàn)。一種典型的實現(xiàn)設(shè)備為計算機。具體的，計算機例如可以為個人計算機、膝上型計算機、蜂窩電話、相機電話、智能電話、個人數(shù)字助理、媒體播放器、導(dǎo)航設(shè)備、電子郵件設(shè)備、游戲控制臺、平板計算機、可穿戴設(shè)備或者這些設(shè)備中的任何設(shè)備的組合。

為了描述的方便，描述以上裝置時以功能分為各種單元分別描述。當然，在實施本申請時可以把各單元的功能在同一個或多個軟件和/或硬件中實現(xiàn)。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計算機程序產(chǎn)品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器、cd-rom、光學(xué)存儲器等)上實施的計算機程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備(系統(tǒng))、和計算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導(dǎo)計算機或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計算機或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

在一個典型的配置中，計算設(shè)備包括一個或多個處理器(cpu)、輸入/輸出接口、網(wǎng)絡(luò)接口和內(nèi)存。

內(nèi)存可能包括計算機可讀介質(zhì)中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內(nèi)存等形式，如只讀存儲器(rom)或閃存(flashram)。內(nèi)存是計算機可讀介質(zhì)的示例。

計算機可讀介質(zhì)包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術(shù)來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序的模塊或其他數(shù)據(jù)。計算機的存儲介質(zhì)的例子包括，但不限于相變內(nèi)存(pram)、靜態(tài)隨機存取存儲器(sram)、動態(tài)隨機存取存儲器(dram)、其他類型的隨機存取存儲器(ram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、快閃記憶體或其他內(nèi)存技術(shù)、只讀光盤只讀存儲器(cd-rom)、數(shù)字多功能光盤(dvd)或其他光學(xué)存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設(shè)備或任何其他非傳輸介質(zhì)，可用于存儲可以被計算設(shè)備訪問的信息。按照本文中的界定，計算機可讀介質(zhì)不包括暫存電腦可讀媒體(transitorymedia)，如調(diào)制的數(shù)據(jù)信號和載波。

還需要說明的是，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、商品或者設(shè)備中還存在另外的相同要素。

本領(lǐng)域技術(shù)人員應(yīng)明白，本申請的實施例可提供為方法、系統(tǒng)或計算機程序產(chǎn)品。因此，本申請可采用完全硬件實施例、完全軟件實施例或結(jié)合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器、cd-rom、光學(xué)存儲器等)上實施的計算機程序產(chǎn)品的形式。

本申請可以在由計算機執(zhí)行的計算機可執(zhí)行指令的一般上下文中描述，例如程序模塊。一般地，程序模塊包括執(zhí)行特定任務(wù)或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等等。也可以在分布式計算環(huán)境中實踐本申請，在這些分布式計算環(huán)境中，由通過通信網(wǎng)絡(luò)而被連接的遠程處理設(shè)備來執(zhí)行任務(wù)。在分布式計算環(huán)境中，程序模塊可以位于包括存儲設(shè)備在內(nèi)的本地和遠程計算機存儲介質(zhì)中。

本說明書中的各個實施例均采用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于系統(tǒng)實施例而言，由于其基本相似于方法實施例，所以描述的比較簡單，相關(guān)之處參見方法實施例的部分說明即可。

以上所述僅為本申請的實施例而已，并不用于限制本申請。對于本領(lǐng)域技術(shù)人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內(nèi)所作的任何修改、等同替換、改進等，均應(yīng)包含在本申請的權(quán)利要求范圍之內(nèi)。