System and method for application plug-in distribution

A new approach is proposed that contemplates systems and methods to support a sandboxed application plug-in distribution framework. An installation package containing a monitoring plug-in, a display plug-in, and/or third part components is received by a first application running on a first computing device. The first application installs the display plug-in and saves the monitoring plug-in to a centralized database. The first application sends an instruction to a second application running on a second computing device to retrieve the monitoring plug-in from the database and install the monitoring plug-in on the second computing device. Upon receiving a user request, the display plug-in of the first application sends a query to the monitor plug-in of the second application. In response to the query, the monitoring plug-in sends the requested monitored data collected by the second application to the display plug-in, which then formats and presents the monitored data to the user.

BACKGROUND

Application plug-ins (also referred to as plug-ins or extensions) are software components that can be integrated into an application running on a computing device, wherein the application plug-ins provide a convenient way to include additional capabilities to the application or to modify existing capabilities of the application. Installation of an application plug-in to the application, however, may often require an update to the application, or may require a restart of the application or the computing device the application is running on. Additionally, installing an application plug-in may affect the security performance of the application. For a non-limiting example, an application plug-in may be provided by a third party and delivered to the computing device over a network. As a result, the application plug-in may be a malicious due to either a malicious intent by the third party or a cyber attack that compromised the application plug-in with malicious content. Since the application running on the computing device has been trusted by the user, the user may unwittingly assume the plug-in is not malicious and install it with the application, causing security risk to the application and/or the computing device the application is running on. A secure way to distribute application plug-ins is thus desired.

The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent upon a reading of the specification and a study of the drawings.

DETAILED DESCRIPTION OF EMBODIMENTS

The following disclosure provides many different embodiments, or examples, for implementing different features of the subject matter. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed. The approach is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” or “some” embodiment(s) in this disclosure are not necessarily to the same embodiment, and such references mean at least one.

A new approach is proposed that contemplates systems and methods to support a sandboxed application plug-in framework for distributed applications. First, an installation package containing a monitoring plug-in, a display plug-in, and/or third part components is received by a first application running on a first computing device. The first application installs the display plug-in and saves the monitoring plug-in and other files of the installation package to a centralized database. The first application then sends an instruction/command to a second application running on a second computing device to retrieve the monitoring plug-in from the database and install the monitoring plug-in in the second application running on the second computing device. When a user request is received by the first application, the display plug-in of the first application sends a query to the monitor plug-in of the second application to request monitored data of the second computing device. In response to the query, the monitoring plug-in of the second application sends the requested monitored data collected by the second application to the display plug-in of the first application, which then formats and presents the monitored data to the user.

By distributing and deploying the monitoring plug-in to a remote computing device, the proposed approach supports remote monitoring management (RMM) of the remote computing device. Here, the monitoring plug-in can be delivered from the cloud as part of the installation package, extracted and installed on the remote computing device at runtime. As such, the monitoring plug-in can be deployed dynamically over a network to any client device/endpoint to be monitored remotely for security and other purposes. Compared to manual installation of monitoring agents, such an approach ensures that the monitoring plug-in is always secure, up-to-date, and can be selectively deployed to any remote computing device needs to be monitored at any time.

FIG. 1depicts an example of a system diagram100of an operating environment for a system that supports application plug-ins for distributed applications. Although the diagrams depict components as functionally separate, such depiction is merely for illustrative purposes. It will be apparent that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firmware, and/or hardware components. Furthermore, it will also be apparent that such components, regardless of how they are combined or divided, can execute on the same host or multiple hosts, and wherein the multiple hosts can be connected by one or more networks.

In the example ofFIG. 1, the system100includes a server102, a plug-in source computer104and a client device116communicably coupled to the server102and/or the plug-in source server104via a network120. Each of the servers and/or devices is a host, which includes one or more processors with software instructions stored in a storage unit such as a non-volatile memory (also referred to as secondary memory) of the host for practicing one or more processes. When the software instructions are executed by the one or more processors of the host, at least a subset of the software instructions is loaded into a memory unit (also referred to as primary memory) by the host, which becomes a special purposed one for practicing the processes. The processes may also be at least partially embodied in the host into which computer program code is loaded and/or executed, such that, the host becomes a special purpose computing unit for practicing the processes. When implemented on a general-purpose computing unit, the computer program code segments configure the computing unit to create specific logic circuits. In some embodiments, each host can be a computing device, a communication device, a storage device, or any computing device capable of running a software component. For non-limiting examples, a computing device can be but is not limited to a server computer, a laptop computer, a desktop computer, a tablet, a Google Android device, an iPhone, an iPad, a set-top box, a video game console, an Internet of Things (IoT) device, and a voice-controlled speaker or controller. Each host has a communication interface (not shown), which enables the engines to communicate with each other, the user, and other devices over one or more communication networks following certain communication protocols, such as TCP/IP, http, https, ftp, and sftp protocols. Here, the communication networks can be but are not limited to, internet, intranet, wide area network (WAN), local area network (LAN), wireless network, Bluetooth, WiFi, mobile communication network, corporate network, enterprise network, campus network etc. The physical connections of the network and the communication protocols are well known to those of skill in the art.

In the example ofFIG. 1, the server102is configured to host a main application108configured to interface with an application plug-in (or plug-in)114installed using a plug-in/installation package106as described in detail below. Here, the main application108can be any type of application or service that controls and interacts with one or more application plug-ins (e.g., plug-in114) via an interface112. The plug-in114is a software component that can also be referred to as an extension. The plug-in114can be an application, an applet, or other program that, once installed, adds functionality, extends existing functionality, or modifies functionality provided by the main application108or another application running on the client device116. For non-limiting examples, the plug-in114can be implemented for virtualized machine software, backup software, antivirus software and office productivity software such as email, word processing etc. Although the main application108and the plug-in114as described above as executing on the server102, it should be noted that the embodiments are not so limited. In alternative embodiments, the main application108and the plug-in114can execute on any type of computing device, including desktop computers, laptop computers, tablet computers, smart phones etc.

In some embodiments, the interface112between the main application108and the plug-in114can be provided via a service that the plug-in114implements, wherein the plug-in114is provided with a service contract that contains a method (e.g., a “get page” method), which provides a response to a request when the method invoked. As such, the interface112is basically an Application Programming Interface (API) that the plug-in114implements. For a non-limiting example, in some embodiments, Windows Communication Framework (WCF), which is part of C #.NET, is used as the service contract to implement the interface112, wherein the WCF provides a way to host a service in a process and send messages to and from the service via a separate process. Although WCF is used here as a non-limiting example, those of ordinary skill in the art will appreciate that many other programming languages besides C #.NET also offer similar frameworks for inter-process communication and are within the scope of the inventive subject matter.

In the example ofFIG. 1, the plug-in source server104is configured to package one or more plug-ins into the form of the plug-in package106and provide the plug-in package106to the server102, which is configured to accept the plug-in package106from the plug-in source server104for use by the main application108as well as other applications. Here, the plug-in source server104can be managed by a plug-in developer and/or provides a library of plug-ins available for download. In some embodiments, the plug-in source server104is configured to compress the plug-in package106into a smaller package, e.g., a single “.zip” file, to make distribution of the plug-in package106over the network120easier and/or more efficient.

FIG. 2is a block diagram illustrating an example of a structure of the plug-in package106. As shown by the example ofFIG. 2, the plug-in package106may include one or more of a display plug-in204, and a monitoring plug-in206, and a manifest212. Here, the manifest212contains a description of contents of the plug-in package106. In some embodiments, the manifest212can be in an XML (eXtensible Markup Language) format. In some embodiments, the plug-in package106may optionally include a common component208and/or one or more external libraries210. The common component208, when present, can be an assembly of code and data to be shared by the display plug-in204and the monitoring plug-in206. Each external library210, when present, can be a third party assembly of code and data to be referenced by any of the display plug-in204, monitoring plug-in206, and/or the common component208.

In the example ofFIG. 2, the display plug-in204can be an assembly of code and data that generates one or more customized (web) pages to be displayed within the main application108to a user, wherein the customized pages can provide additional display functionalities to the main application108or can extend currently existing display functionalities provided by the main application108. The display plug-in204is deployed to the server102and installed/implemented/integrated with the main application108.

In the example ofFIG. 2, the monitoring plug-in206can be an assembly of code and data that collects data from the main application108and/or the server102the main application108runs on. For a non-limiting example, the data collected by the monitoring plug-in206includes but is not limited to security risk to the main application108and/or the server102. In some embodiments, the data collected by the monitoring plug-in206can be used to populate, e.g., tables and charts, of the customized pages generated by the display plug-in204. In some embodiments, instead of being installed in the main application108running on the server102, the monitoring plug-in206can be deployed to the client device116, wherein the data collected by the monitoring plug-in206on the client device116can be provided to the main application108on the server102. Once received by the main application108on the server102, the data collected and sent by the monitoring plug-in206on the client device116can be queried upon a user request and presented to the user via the display plug-in204.

FIG. 3is a block diagram illustrating an example of an operating environment for a system that supports distribution of application plug-ins among various devices over a network. As indicated by circled numbers inFIG. 3, the main application108running on the server102is configured to conduct an initial installation of the plug-in114in multiple stages. At stage #1, the main application108running receives the plug-in package106and extracts various types of package files discussed above from the plug-in package106. In some embodiments, the main application108utilizes the manifest file212extracted from the plug-in package106to assist in navigating the contents of the plug-in package106. At stage #2, the individual files extracted from the plug-in package are saved to a centralized database306running on a database server304so that the files can be made available to one or more agent programs/distributed applications310running on a computing device308. At stage #3, the main application108is configured to retrieve the display plug-in204, the monitoring plug-in206, the common component208and/or the external libraries210from the centralized database304. At stage #4, the components retrieved from the centralized database304are copied to the local file system302in a folder structure and are loaded into memory of the server102for execution.

In some embodiments, the main application108is configured to defer loading of the components retrieved from the centralized database304into the file system302. For a non-limiting example, when a first request is made by a user to view a custom page, the main application108can ensure that the appropriate the display plug-in204and necessary references have been retrieved from the centralized database306and placed into the file system302of the server102that is handling the request by the user so that the display plug-in204and necessary references can be loaded into memory of the server102and executed by the main application108.

In some embodiments, the main application108can be a distributed application where functionalities of the main application108can be distributed across multiple servers102and/or computing devices308, e.g., the client device116shown inFIG. 1. Here, the computing device308can be any type of device having a processor, memory and network interface to communicably couple the computing device308to a network (e.g., network120ofFIG. 1). For non-limiting examples, the computing device308can be but is not limited to a desktop computer, a server computer, a laptop computer, a tablet computer, a smart phone, a set-top box, a video game console, an Internet of Things (IoT) device, and a voice-controlled speaker or controller. In some embodiments, the computing device308is located remotely from the server102and accessible over a network (e.g., network120). In some embodiments, an agent program310can execute on the computing device308to collect/monitor data from the computing device308, wherein the data collected include data on the operating environment, the applications and/or security environment of the computing device308. In some embodiments, the agent program310can be part of the distributed application having functionalities distributed from the main application108. In such embodiments, the main application108is configured to create/issue and send a command to the agent programs310of the distributed application to instruct the agent programs310to retrieve the monitoring plug-in206from the centralized database306. Upon receiving such command, the agent program310is configured to process the command and to retrieve the monitoring plug-in206and its necessary references (i.e., references to common components208and/or external libraries210) from the centralized database306as part of stage #3. The agent program310is further configured to copy the retrieved monitoring plug-in206and its necessary references to a local file system/file folder312on the computing device308as part of stage #4, and load/install the monitoring plug-in206and its necessary references into memory of the computing device308for execution by the agent program310.

In some embodiments, the monitoring plug-in206running on the computing device308is configured to implement a polling method, e.g. as part of an API, wherein the polling method is called periodically by the main application108running on the server102to obtain monitoring data collected by the agent program310. In response to the polling, the monitoring plug-in206is configured to send the data collected by the agent program310to the main application108for consumption by the display plug-in204running on the server102.

In some embodiments, the display plug-in204running on the server102is configured to implement an interface, e.g., an API, which contains a “get page” method that can be invoked by the main application108in response to a user's action/request, e.g., by clicking on or otherwise selecting a user interface element, to cause the display plug-in204to be invoked by the main application108to display content, e.g., monitoring data collected by the monitoring plug-in206to the user.

As shown by the example ofFIG. 3, files on the servers102and/or computing devices308can be placed into various vendor and/or plug-in specific folder structures302and312, respectively. In some embodiments, as shown inFIG. 3, the files in the folder structures302and312can be versioned so that multiple plug-in versions can be supported at one time. This is desirable for implementations of the plug-in applications in a cloud environment, wherein version 1 of a plug-in application can be executed on a first server/computing device, e.g., server102, and version 2 of the same plug-in application can be executed on a second server/computing device, e.g., computing device308.

FIG. 4is a block diagram illustrating an example of application domain sandboxing for application plug-ins114, wherein the folder structures302and312described above are utilized to create isolation between the plug-ins114and the main application108. In some embodiments, each application plug-in is loaded into a separate plug-in domain408, e.g.,408A,408B, and408C, which is similar to a process and runs within the context of the associated folder structure302. In implementations using, e.g., C #.NET, the plug-in domains408can be application domains that isolate applications from one another. In alternative implementations, a plug-in114can be implemented as a process, thus the plug-in domains408would be the process domain. Further, in addition to being separate from other plug-in domains, a plug-in domain408is also separate from the main application domain404where the main application108is running. In some embodiments, each plug-in domain408is restricted to loading only the runtime assemblies that are present within its folder in the folder structure302. In the non-limiting example illustrated inFIG. 4, the plug-in “ABC” has a plug-in domain408A that is restricted to loading code, data, and files within the folder in the folder structure302having a path that matches its root or base directory (as provided by the runtime or operating system). In some embodiments, the restrictions can be implemented using access control list functionality provided by the host operating system of the server102. In some embodiments, the user identifier that the plug-in domain408executes can be granted read-only permission to its folder in the folder structure302, where the assemblies are located, e.g., “<Install Folder>\PLUGINS\COM.VENDORI.ABCW1.0.0.” for the plug-in domain408A. In some embodiments, the plug-in domain408has a minimal set of permissions which allow the corresponding plug-in114to interact with an API exposed by the main application108. In some embodiments, the permissions are read and execute and are enforced based on a user account that is associated with the specific plug-in114.

FIG. 5is a sequence diagram illustrating an example of operations for an application plug-in to serve a user request. Although the figure depicts functional steps in a particular order for purposes of illustration, the processes are not limited to any particular order or arrangement of steps. One skilled in the relevant art will appreciate that the various steps portrayed in this figure could be omitted, rearranged, combined and/or adapted in various ways.

In the example ofFIG. 5, a user at a client device116clicks on a user interface element for a plug-in application506at step510. The main application108initiates a “get page” request to the plug-in application506at step512. At step514, the plug-in application506invokes an API (e.g., “gate data”) in the main application108running on the server102to retrieve the custom data collected by, e.g., the monitoring plug-in206running on the same or a different computing device. At step516, the plug-in application506is configured to use the retrieved data to populate data tables and charts within a given page and provides the page to the main application108. The main application108then returns the page in response to the user at operation518. In some embodiments, the API being invoked may limit the amount of data returned to the plug-in application506to ensure that requests are fulfilled in a reasonable amount of time and do not create CPU or memory pressure on the server102.

One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.

The methods and system described herein may be at least partially embodied in the form of computer-implemented processes and apparatus for practicing those processes. The disclosed methods may also be at least partially embodied in the form of tangible, non-transitory machine readable storage media encoded with computer program code. The media may include, for a non-limiting example, RAMs, ROMs, CD-ROMs, DVD-ROMs, BD-ROMs, hard disk drives, flash memories, or any other non-transitory machine-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the method. The methods may also be at least partially embodied in the form of a computer into which computer program code is loaded and/or executed, such that, the computer becomes a special purpose computer for practicing the methods. When implemented on a general-purpose processor, the computer program code segments configure the processor to create specific logic circuits. The methods may alternatively be at least partially embodied in a digital signal processor formed of application specific integrated circuits for performing the methods.