插件權限控制方法及裝置、插件系統與流程
2023-04-27 08:32:46 1
本申請涉及計算機軟體技術領域，尤其涉及插件權限控制方法及裝置、插件系統。
背景技術：
隨著應用(application，app)功能的豐富，很多大型app都使用了大量插件，這些插件可以擴展或加強其所屬的app的功能，比如，瀏覽器功能、多媒體處理功能等。
在現有技術中，當app使用的插件中存在漏洞時，可導致整個app也存在該漏洞，則可能對該app造成安全威脅。另外，當插件本身有較大版本更新時，其所屬的app往往還很難快速的進行版本更新迭代，這也就導致了app所使用的插件中可能存在很多歷史遺留安全問題。
因此，急需一種有效方案來解決app使用插件而引入的安全威脅。
技術實現要素：
本申請實施例提供插件權限控制方法及裝置、插件系統，用以解決現有技術中app使用插件而引入安全威脅的問題。
為解決上述技術問題，本申請實施例是這樣實現的：
本申請實施例提供的一種插件權限控制方法，所述方法應用於應用app，所述app中包括插件權限控制器、一個或多個插件沙箱，所述方法包括：
所述插件權限控制器接收所述插件沙箱發送的應用程式編程接口api調用請求，其中，所述api調用請求是所述插件沙箱中插件的api調用請求，由所述插件沙箱攔截得到；
所述插件權限控制器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
本申請實施例提供的一種插件權限控制裝置，所述裝置應用於應用app，所述app中包括插件權限控制器、一個或多個插件沙箱，所述裝置位於所述插件權限控制器，包括：
接收模塊，接收所述插件沙箱發送的應用程式編程接口api調用請求，其中，所述api調用請求是所述插件沙箱中插件的api調用請求，由所述插件沙箱攔截得到；
控制模塊，確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
本申請實施例提供的另一種插件權限控制方法，所述方法應用於應用app，所述app中包括插件權限控制器、一個或多個插件沙箱，所述方法包括：
所述插件沙箱攔截所述插件沙箱中插件的應用程式編程接口api調用請求；
所述插件沙箱將攔截的所述api調用請求發送給所述插件權限控制器，以便於所述插件權限控制器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
本申請實施例提供的另一種插件權限控制裝置，所述裝置應用於應用app，所述app中包括插件權限控制器、一個或多個插件沙箱，所述裝置位於所述插件沙箱，包括：
攔截模塊，攔截所述插件沙箱中插件的應用程式編程接口api調用請求；
發送模塊，將所述攔截模塊攔截的所述api調用請求發送給所述插件權限控制器，以便於所述插件權限控制器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
本申請實施例提供的一種插件系統，所述插件系統應用於應用app，包括插件權限控制器、一個或多個插件沙箱；
所述插件沙箱，攔截所述插件沙箱中插件的應用程式編程接口api調用請求，並將攔截的所述api調用請求發送給所述插件權限控制器；
所述插件權限控制器，確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
本申請實施例採用的上述至少一個技術方案能夠達到以下有益效果：可以實現app本身的權限與app的插件的權限相互隔離，即便app使用了存在漏洞的插件，也可以使插件無法獲取到整個app的權限，可以降低插件的漏洞對app本身的影響，可以減少app使用插件而引入的安全威脅，因此，可以部分或全部地解決現有技術中的問題。
附圖說明
為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請中記載的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動性的前提下，還可以根據這些附圖獲得其他的附圖。
圖1為本申請實施例提供的一種插件系統的架構示意圖；
圖2為本申請實施例提供的圖1中的插件系統的一種詳細架構示意圖；
圖3為本申請實施例提供的一種插件權限控制方法的流程示意圖；
圖4為本申請實施例提供的另一種插件權限控制方法的流程示意圖；
圖5為本申請實施例提供的對應於圖3的一種插件權限控制裝置的結構示意圖；
圖6為本申請實施例提供的對應於圖3的一種插件權限控制裝置的結構示意圖。
具體實施方式
本申請實施例提供插件權限控制方法及裝置、插件系統。
為了使本技術領域的人員更好地理解本申請中的技術方案，下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基於本申請中的實施例，本領域普通技術人員在沒有作出創造性勞動前提下所獲得的所有其他實施例，都應當屬於本申請保護的範圍。
圖1為本申請實施例提供的一種插件系統的架構示意圖，所述插件系統應用於應用app，包括插件權限控制器101、一個或多個插件沙箱102；
所述插件沙箱101，攔截所述插件沙箱中插件的應用程式編程接口(applicationprogramminginterface，api)調用，並將攔截的所述api調用請求發送給所述插件權限控制器；
所述插件權限控制器102，確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
簡明起見，以下可以省略插件沙箱101和插件權限控制器102的數字標號。
在本申請實施例中，每個插件沙箱可以對應於app的一個或多個插件，為了減少插件之間的相互影響，每個插件沙箱優選地可以對應於app的一個插件。
以電子支付app為例，電子支付app可以有諸如商品推薦插件、社交評論插件、比價插件等。在現有技術中，這些插件的權限即為電子支付app本身的權限，插件針對app本身可以不受限制地進行api調用，插件針對app所在系統可以僅在app的權限的限制下進行api調用，比如，商品推薦插件的正常功能是進行商品推薦；但是，也有可能具有竊取用戶支付相關敏感數據的惡意功能(這些功能都是通過插件進行的api調用實現的)，或者，雖然商品推薦插件本身不具有惡意功能，但若商品推薦插件存在漏洞，也可能使得第三方惡意程序通過該漏洞竊取用戶支付相關敏感數據，由此導致背景技術中提到的問題。
在本申請實施例中，插件可以在其對應的插件沙箱中安全運行，而且基於插件權限控制器的權限控制，插件可以在符合一定安全策略的前提下，針對app本身或對app所在系統的進行api調用(某些api調用請求可能被拒絕)，在這種情況下，插件的權限與app本身的權限是相互隔離的，因此，可以有針對性地對插件的權限進行控制，而又不至於影響app本身的權限，從而使得app既能使用插件的正常功能，又能阻止插件可能帶來安全威脅的敏感api調用。
通過圖1的插件系統，可以實現app本身的權限與app的插件的權限相互隔離，即便app使用了存在漏洞的插件，也可以使插件無法獲取到整個app的權限，可以降低插件的漏洞對app本身的影響，可以減少app使用插件而引入的安全威脅，因此，可以部分或全部地解決現有技術中的問題。
基於圖1的插件系統，本申請實施例還提供了該插件系統的一些具體實施方案，以及擴展方案，下面進行說明。
在本申請實施例中，插件沙箱具有可模擬的進程級別的粒度，則每個插件被沙箱化後，是在一個獨立的模擬進程中運行的，如此有利於實現插件與app間的權限隔離，以及插件與插件間的權限隔離。在這種情況下，插件沙箱與插件權限控制器之間是通過進程間通信的方式進行通信交互的。基於此，可以對插件沙箱、插件權限控制器進一步地細分模塊。
具體地，所述插件沙箱可以包括攔截控制器、進程間通信第一端；所述插件權限控制器可以包括調用攔截管理器、進程間通信第二端。
所述插件沙箱攔截所述插件沙箱中插件的api調用請求，並將攔截的所述api調用請求發送給所述插件權限控制器，具體可以包括：所述攔截控制器攔截所述插件沙箱中插件的api調用請求，並通過所述進程間通信第一端，將攔截的所述api調用請求發送給所述插件權限控制器。
所述插件權限控制器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用，具體可以包括：所述進程間通信第二端接收所述插件沙箱發送的所述api調用請求；所述調用攔截管理器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
在實際應用中，進程間通信第一端與進程間通信第二端可以是具有從屬關係的通信端，也可以是對等的通信端。以前一種情況為例，進程間通信第一端具體可以是進程間通信客戶端，進程間通信第二端具體可以是進程間通信服務端。
在本申請實施例中，插件的權限並非直接是app的權限，而是需要插件權限控制器按照一定的策略分別對各插件的權限進行控制，比如，策略中可以指定：某插件具有進行哪些api調用的權限、某插件不具有進行哪些api調用的權限等。
基於此，插件權限控制器中可以有負責管理所要使用的策略的模塊。
例如，所述插件權限控制器還可以包括：策略引擎管理器，設定所述調用攔截管理器確定所述插件沙箱中插件的權限時所根據的策略；在這種情況下，所述調用攔截管理器確定所述插件的權限，具體可以包括：所述調用攔截管理器根據所述策略引擎管理器設定的策略，確定所述插件的權限；其中，所述策略引擎管理器是根據所述策略引擎管理器預先接收的策略設定第一指令而設定策略的。
為了便於理解，對「策略設定第一指令」進行說明。策略設定第一指令是直接針對策略引擎管理器下達的指令。
策略設定第一指令的具體下達方式可以有多種，列舉兩種：
第一種，用戶可以通過在app所提供的策略引擎管理器的可視界面中進行操作，以下達策略設定第一指令，比如，該可視界面中可以提供若干可選的策略，用戶可以通過進行在這些可選的策略中選定一項或多項策略並確認的操作，下達策略設定第一指令，相應地，策略引擎管理器會把用戶選定確認的這些策略設定為要使用的策略。這種方式的優點是：用戶自主控制性較好。
第二種，可以由app對應的伺服器側向用戶側的策略引擎管理器下達策略設定第一指令。這種方式的優點是：無需用戶幹預，而是由伺服器側的專業人員把控，有利於及時有效地阻止插件引入的安全威脅。
在本申請實施例中，所述插件權限控制器還可以包括：策略中心，包含預定的各策略；所述策略引擎管理器是根據所述策略中心包含的各策略而設定策略的，所述策略引擎管理器設定的策略包括所述各策略中的一項或多項。在實際應用中，策略中心也可以內置於策略引擎管理器中。
策略中心的存在使得各種可能使用的策略可以預先被整理，以備不時之需，而不是只要策略有變，就需要更新app或者從服務端獲取變更的策略，因此，有利於減輕app的處理負擔。
在本申請實施例中，不同的插件可能對應於不同的權限策略，為了便於對不同的插件差異化地設定(初次設定、或後續設定變更)，也可以從插件沙箱向插件權限控制器發送請求，以請求對該插件對應的策略進行設定。
例如，插件沙箱可以包括策略引擎客戶端，且可以將插件權限控制器的策略引擎管理器作為策略引擎客戶端的服務端。進一步地，所述策略引擎客戶端當接收到策略設定第二指令時，根據所述策略設定第二指令，向所述策略引擎管理器發送策略設定請求，以使策略引擎管理器根據所述策略設定請求設定策略。
策略設定第二指令類似於上述的策略設定第一指令，主要區別在於：策略設定第一指令是直接針對插件權限控制器的，而策略設定第二指令是直接針對插件沙箱的。基於這兩種指令中任一種指令對應的策略設定方式，可以便利地進行策略定製以及策略變更，而且對於線下或線上都是適用的。
在本申請實施例中，所述調用攔截管理器當確定執行所述api調用時，根據所述插件的權限對應的預定執行方式，執行所述api調用以及返回執行結果，否則，拒絕所述api調用請求。
對於某些可能威脅app安全的敏感api調用的請求，可以通過相應的策略限制權限，以使這些敏感api調用不會被執行，從而有利於阻止插件引入的安全威脅。
進一步地，對於被確定為可以執行的api調用，也可以根據具體情況差異化地執行，以實現「安全執行」。比如，對於可信(比如，權限相對較高的)的api調用，可以直接執行；對於部分可信(比如，權限相對較低的)的api調用，可以針對其執行一些限制措施(比如，可以通過修改api調用參數，使得該api調用涉及的app資源被重定向等)後再執行。
進一步地，為了避免插件的某些敏感api調用未被執行而導致插件或app異常，插件沙箱還可以包括異常處理器，異常處理器可以對所述api調用未被執行而引發的異常進行處理，如此，有利於減少app運行受到的影響。
根據上面的說明，更直觀地，本申請實施例提供了圖1中的插件系統的一種詳細架構示意圖，如圖2所示。
在圖2中，插件權限控制器101可以包括：進程間通信第一端1011、調用攔截管理器1012、策略引擎管理器1013、策略中心1014；插件沙箱102可以包括進程間通信第二端1021、攔截控制器1022、策略引擎客戶端1023、異常處理器1024。
需要說明的是，圖2中的插件權限控制器101、插件沙箱102中各模塊之間的連接僅是一種示例，並非限定，採用其他連接方式也可以，只要能實現模塊之間直接或間接的通信即可。
圖1、圖2中各模塊的劃分也是示例，也可以採用其他模塊劃分方法，能夠實現這些模塊的功能即可。基於同樣的發明思路，本申請實施例還提供了對應的插件權限控制方法，方法主要描述上述功能，而不限定模塊的劃分，由於上面對上述功能已經進行詳細說明，簡明起見，下面結合圖3、圖4僅對插件權限控制方法進行簡單說明。
圖3為本申請實施例提供的一種插件權限控制方法的流程示意圖。圖3的方法應用於app，app中包括插件權限控制器、一個或多個插件沙箱。
圖3中的流程的執行主體是插件權限控制器，主要包括以下步驟：
s301：所述插件權限控制器接收所述插件沙箱發送的api調用請求，其中，所述api調用請求是所述插件沙箱中插件的api調用請求，由所述插件沙箱攔截得到。
s302：所述插件權限控制器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
基於圖3的方法，本申請實施例還提供了該方法的一些具體實施方案，以及擴展方案，下面進行說明。
在本申請實施例中，對於步驟s301，所述插件權限控制器接收所述插件沙箱發送的api調用請求，具體可以包括：所述插件權限控制器通過進程間通信，接收所述插件沙箱發送的api調用請求。
在本申請實施例中，對於步驟s302，所述插件權限控制器確定所述插件的權限，具體可以包括：所述插件權限控制器根據設定的策略，確定所述插件的權限；其中，所述設定的策略由所述插件權限控制器根據預先接收的策略設定第一指令而設定。
在本申請實施例中，所述插件權限控制器內有包含預定的各策略的策略中心，所述插件權限控制器是根據所述策略中心包含的各策略而設定策略的，所述策略引擎管理器設定的策略包括所述各策略中的一項或多項。
在本申請實施例中，對於圖3中的流程，還可以執行：所述插件權限控制器接收所述插件沙箱發送的策略設定請求，所述策略設定請求是所述插件沙箱根據接收到的策略設定第二指令發送的；所述插件權限控制器根據所述策略設定請求設定策略。
在本申請實施例中，對於步驟s302，若所述插件權限控制器確定執行所述api調用後，可以執行：所述插件權限控制器根據所述插件的權限對應的預定執行方式，執行所述api調用；
若所述插件權限控制器確定不執行所述api調用，可以執行：所述插件權限控制器拒絕所述api調用請求。
圖4為本申請實施例提供的另一種插件權限控制方法的流程示意圖。圖4的方法應用於app，app中包括插件權限控制器、一個或多個插件沙箱。
圖4中的流程的執行主體是插件沙箱，主要包括以下步驟：
s401：所述插件沙箱攔截所述插件沙箱中插件的api調用請求。
s402：所述插件沙箱將攔截的所述api調用請求發送給所述插件權限控制器，以便於所述插件權限控制器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
基於圖4的方法，本申請實施例還提供了該方法的一些具體實施方案，以及擴展方案，下面進行說明。
在本申請實施例中，對於步驟s402，所述插件沙箱將攔截的所述api調用請求發送給所述插件權限控制器，具體可以包括：所述插件沙箱通過進程間通信，將攔截的所述api調用請求發送給所述插件權限控制器。
在本申請實施例中，對於圖4中的流程，還可以執行：所述插件沙箱接收到策略設定第二指令；所述插件沙箱根據所述策略設定第二指令向所述插件權限控制器發送策略設定請求，以使所述插件權限控制器根據所述策略設定請求設定策略，以用於確定所述插件沙箱中插件的權限。需要說明的是，該步驟可以是預先執行的，若不是預先則執行的，則通過執行該步驟所設定的策略只能用於確定以後插件沙箱再發送的api調用請求對應的插件權限。
在本申請實施例中，對於步驟s402，所述插件沙箱將攔截的所述api調用請求發送給所述插件權限控制器後，若確定所述api調用不被執行，還可以執行：所述插件沙箱對所述api調用未被執行而引發的異常進行處理。
進一步地，基於同樣的發明思路，本申請實施例還提供了上述插件權限控制方法對應的裝置，結合圖5、圖6進行說明。
圖5為本申請實施例提供的對應於圖3的一種插件權限控制裝置的結構示意圖。該裝置應用於應用app，所述app中包括插件權限控制器、一個或多個插件沙箱，該裝置位於所述插件權限控制器，包括：
接收模塊501，接收所述插件沙箱發送的應用程式編程接口api調用請求，其中，所述api調用請求是所述插件沙箱中插件的api調用請求，由所述插件沙箱攔截得到；
控制模塊502，確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
可選地，所述接收模塊501接收所述插件沙箱發送的api調用請求，具體包括：
所述接收模塊501通過進程間通信，接收所述插件沙箱發送的api調用請求。
可選地，所述控制模塊502確定所述插件的權限，具體包括：
所述控制模塊502根據設定的策略，確定所述插件的權限；
其中，所述設定的策略由所述插件權限控制器根據預先接收的策略設定第一指令而設定。
可選地，所述插件權限控制器內有包含預定的各策略的策略中心，所述插件權限控制器是根據所述策略中心包含的各策略而設定策略的，所述策略引擎管理器設定的策略包括所述各策略中的一項或多項。
可選地，所述裝置還包括：
設定模塊503，接收所述插件沙箱發送的策略設定請求，所述策略設定請求是所述插件沙箱根據接收到的策略設定第二指令發送的，根據所述策略設定請求設定策略。
可選地，所述控制模塊502若確定執行所述api調用，根據所述插件的權限對應的預定執行方式，執行所述api調用；
所述控制模塊502若確定不執行所述api調用，拒絕所述api調用請求。
圖6為本申請實施例提供的對應於圖4的一種插件權限控制裝置的結構示意圖。該裝置應用於應用app，所述app中包括插件權限控制器、一個或多個插件沙箱，該裝置位於所述插件沙箱，包括：
攔截模塊601，攔截所述插件沙箱中插件的應用程式編程接口api調用請求；
發送模塊602，將所述攔截模塊601攔截的所述api調用請求發送給所述插件權限控制器，以便於所述插件權限控制器確定所述插件的權限，並根據所述插件的權限，確定是否執行所述api調用。
可選地，所述攔截模塊601攔截其對應的插件的應用程式編程接口api調用請求，具體包括：
所述攔截模塊601通過進程間通信，將攔截的所述api調用請求發送給所述插件權限控制器。
可選地，所述裝置還包括：
設定模塊603，所述設定模塊到策略設定第二指令，根據所述策略設定第二指令向所述插件權限控制器發送策略設定請求，以使所述插件權限控制器根據所述策略設定請求設定策略，以用於確定所述插件沙箱中插件的權限。
可選地，所述裝置還包括：
異常處理模塊604，在所述發送模塊將所述攔截模塊攔截的所述api調用請求發送給所述插件權限控制器後，若確定所述api調用不被執行，對所述api調用未被執行而引發的異常進行處理。
本申請實施例提供的系統、方法與裝置是一一對應的，因此，方法、裝置也具有與其對應的系統類似的有益技術效果，由於上面已經對系統的有益技術效果進行了詳細說明，因此，這裡不再贅述對應方法、裝置的有益技術效果。
本申請實施例中所述支付涉及的技術載體，例如可以包括近場通信(nearfieldcommunication，nfc)、wifi、3g/4g/5g、pos機刷卡技術、二維碼掃碼技術、條形碼掃碼技術、藍牙、紅外、短消息(shortmessageservice，sms)、多媒體消息(multimediamessageservice，mms)等。
在20世紀90年代，對於一個技術的改進可以很明顯地區分是硬體上的改進(例如，對二極體、電晶體、開關等電路結構的改進)還是軟體上的改進(對於方法流程的改進)。然而，隨著技術的發展，當今的很多方法流程的改進已經可以視為硬體電路結構的直接改進。設計人員幾乎都通過將改進的方法流程編程到硬體電路中來得到相應的硬體電路結構。因此，不能說一個方法流程的改進就不能用硬體實體模塊來實現。例如，可編程邏輯器件(programmablelogicdevice,pld)(例如現場可編程門陣列(fieldprogrammablegatearray，fpga))就是這樣一種集成電路，其邏輯功能由用戶對器件編程來確定。由設計人員自行編程來把一個數字系統「集成」在一片pld上，而不需要請晶片製造廠商來設計和製作專用的集成電路晶片。而且，如今，取代手工地製作集成電路晶片，這種編程也多半改用「邏輯編譯器(logiccompiler)」軟體來實現，它與程序開發撰寫時所用的軟體編譯器相類似，而要編譯之前的原始代碼也得用特定的程式語言來撰寫，此稱之為硬體描述語言(hardwaredescriptionlanguage，hdl)，而hdl也並非僅有一種，而是有許多種，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)與verilog。本領域技術人員也應該清楚，只需要將方法流程用上述幾種硬體描述語言稍作邏輯編程並編程到集成電路中，就可以很容易得到實現該邏輯方法流程的硬體電路。
控制器可以按任何適當的方式實現，例如，控制器可以採取例如微處理器或處理器以及存儲可由該(微)處理器執行的計算機可讀程序代碼(例如軟體或固件)的計算機可讀介質、邏輯門、開關、專用集成電路(applicationspecificintegratedcircuit，asic)、可編程邏輯控制器和嵌入微控制器的形式，控制器的例子包括但不限於以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存儲器控制器還可以被實現為存儲器的控制邏輯的一部分。本領域技術人員也知道，除了以純計算機可讀程序代碼方式實現控制器以外，完全可以通過將方法步驟進行邏輯編程來使得控制器以邏輯門、開關、專用集成電路、可編程邏輯控制器和嵌入微控制器等的形式來實現相同功能。因此這種控制器可以被認為是一種硬體部件，而對其內包括的用於實現各種功能的裝置也可以視為硬體部件內的結構。或者甚至，可以將用於實現各種功能的裝置視為既可以是實現方法的軟體模塊又可以是硬體部件內的結構。
上述實施例闡明的系統、裝置、模塊或單元，具體可以由計算機晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為計算機。具體的，計算機例如可以為個人計算機、膝上型計算機、蜂窩電話、相機電話、智慧型電話、個人數字助理、媒體播放器、導航設備、電子郵件設備、遊戲控制臺、平板計算機、可穿戴設備或者這些設備中的任何設備的組合。
為了描述的方便，描述以上裝置時以功能分為各種單元分別描述。當然，在實施本申請時可以把各單元的功能在同一個或多個軟體和/或硬體中實現。
本領域內的技術人員應明白，本發明的實施例可提供為方法、系統、或電腦程式產品。因此，本發明可採用完全硬體實施例、完全軟體實施例、或結合軟體和硬體方面的實施例的形式。而且，本發明可採用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限於磁碟存儲器、cd-rom、光學存儲器等)上實施的電腦程式產品的形式。
本發明是參照根據本發明實施例的方法、設備(系統)、和電腦程式產品的流程圖和/或方框圖來描述的。應理解可由電腦程式指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合。可提供這些電腦程式指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數據處理設備的處理器以產生一個機器，使得通過計算機或其他可編程數據處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。
這些電腦程式指令也可存儲在能引導計算機或其他可編程數據處理設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的製造品，該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。
這些電腦程式指令也可裝載到計算機或其他可編程數據處理設備上，使得在計算機或其他可編程設備上執行一系列操作步驟以產生計算機實現的處理，從而在計算機或其他可編程設備上執行的指令提供用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。
在一個典型的配置中，計算設備包括一個或多個處理器(cpu)、輸入/輸出接口、網絡接口和內存。
內存可能包括計算機可讀介質中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內存等形式，如只讀存儲器(rom)或快閃記憶體(flashram)。內存是計算機可讀介質的示例。
計算機可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現信息存儲。信息可以是計算機可讀指令、數據結構、程序的模塊或其他數據。計算機的存儲介質的例子包括，但不限於相變內存(pram)、靜態隨機存取存儲器(sram)、動態隨機存取存儲器(dram)、其他類型的隨機存取存儲器(ram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、快閃記憶體或其他內存技術、只讀光碟只讀存儲器(cd-rom)、數字多功能光碟(dvd)或其他光學存儲、磁盒式磁帶，磁帶磁磁碟存儲或其他磁性存儲設備或任何其他非傳輸介質，可用於存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質不包括暫存電腦可讀媒體(transitorymedia)，如調製的數據信號和載波。
還需要說明的是，術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句「包括一個……」限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
本領域技術人員應明白，本申請的實施例可提供為方法、系統或電腦程式產品。因此，本申請可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體方面的實施例的形式。而且，本申請可採用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限於磁碟存儲器、cd-rom、光學存儲器等)上實施的電腦程式產品的形式。
本申請可以在由計算機執行的計算機可執行指令的一般上下文中描述，例如程序模塊。一般地，程序模塊包括執行特定任務或實現特定抽象數據類型的例程、程序、對象、組件、數據結構等等。也可以在分布式計算環境中實踐本申請，在這些分布式計算環境中，由通過通信網絡而被連接的遠程處理設備來執行任務。在分布式計算環境中，程序模塊可以位於包括存儲設備在內的本地和遠程計算機存儲介質中。
本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於系統實施例而言，由於其基本相似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。
以上所述僅為本申請的實施例而已，並不用於限制本申請。對於本領域技術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本申請的權利要求範圍之內。