Cross-sandbox secure communication method, system and device based on Electron framework

Abstract

The invention discloses a cross-sandbox secure communication method, a cross-sandbox secure communication system and a cross-sandbox secure communication device based on an Electron framework. The method comprises the following steps: receiving an Electron host process starting request; determining latest permission rule information and a local registration protocol for analysis; the Electron main process is started, and starting success information is returned to the user; the calling protocol layer receives a message which is sent by a user and carries a local resource access request; packaging the message, and calling a middleware layer to carry out authority verification and correctness verification on the packaged message; the middleware layer is called to distribute the verified message according to the message type, and the local resource is obtained and returned to the user, so that the development efficiency can be improved; the problem of contradiction between a browser sandbox environment and local resource access, the problem of complexity of local executable program calling and parameter transmission and the problem of compatibility caused by non-uniform cross-platform resource access interfaces are solved.

Description

Technical Field

[0001] This invention relates to the field of cross-platform desktop application development technology, and in particular to a cross-sandbox secure communication method, system and device based on the Electron framework. Background Technology

[0002] This section is intended to provide background or context for embodiments of the present invention. The description herein is not intended to imply that it is prior art simply because it is included in this section.

[0003] Cross-platform compatibility has always been a challenge in desktop application development. To achieve compatibility across different operating systems, developers must invest additional time and effort in specific development and optimization for each platform. This fragmented development approach undoubtedly increases workload and prolongs time to market.

[0004] With the rise of Electron technology, desktop application development has begun to trend towards using the Web (World Wide Web) technology stack for unified development, which has alleviated cross-platform compatibility issues to some extent. However, the Electron framework still has some design problems.

[0005] 1) The high coupling of Electron's inter-process communication (IPC) leads to low development efficiency:

[0006] In existing Electron applications, communication between the main process (Node.js) and the rendering process (Chromium) relies on predefined event channels. Developers need to repeatedly write IPC code for different functions, resulting in redundant logic and difficulty in maintenance. For example, passing complex parameters requires manual data serialization and handling of cross-process exceptions, increasing code complexity.

[0007] 2) The conflict between browser sandbox environment and local resource access:

[0008] Electron rendering processes are restricted by the Chromium sandbox by default, preventing direct calls to native Node.js modules (such as fs and child_process). Traditional solutions expose limited interfaces through preload scripts, but lack dynamic permission control and pose a risk of arbitrary file read / write operations.

[0009] 3) The complexity of native executable program calls and parameter passing:

[0010] Existing technologies require hard-coding paths in the main process or relying on environment variables when calling local programs via child_process, making dynamic path resolution and parameter validation impossible. For example, passing sensitive parameters (such as file paths) can easily lead to command-line injection attacks.

[0011] 4) Compatibility issues caused by inconsistent cross-platform resource access interfaces:

[0012] Although Electron provides basic system APIs (Application Programming Interfaces) (such as shell.openPath), the differences in implementation of local program calls and file permission management across different platforms (Windows / macOS / Linux) require developers to manually adapt, increasing the cost of cross-platform deployment.

[0013] Therefore, existing desktop application development technologies based on the Electron framework have the following technical problems: low development efficiency due to the high coupling of Electron inter-process communication (IPC); contradiction between browser sandbox environment and local resource access; complexity of local executable program calls and parameter passing; and compatibility issues caused by inconsistent cross-platform resource access interfaces. Summary of the Invention

[0014] This invention provides a cross-sandbox secure communication method based on the Electron framework to improve development efficiency and resolve the contradictions between browser sandbox environments and local resource access, the complexity of local executable program calls and parameter passing, and the compatibility issues caused by inconsistent cross-platform resource access interfaces. The method includes:

[0015] Receive a user's request to start the Electron main process;

[0016] Determine the latest permission rules and local registration agreement based on the request to start the Electron main process;

[0017] The latest permission rules and local registration agreement are parsed.

[0018] The Electron main process is started using the latest parsed permission rules and local registration protocol, and a startup success message is returned to the user.

[0019] After the Electron main process starts successfully, it calls the protocol layer to receive messages from users carrying local resource access requests. The protocol layer is used to provide a unified communication protocol, data structure, transmission rules and interface. The interface is obtained by encapsulating the interfaces of different platforms after hiding the interface differences.

[0020] The message is encapsulated, and the middleware layer is called to perform permission and correctness checks on the encapsulated message; the middleware layer is used to perform permission checks, correctness checks and / or encryption on the data, and to distribute the message using a message router.

[0021] The middleware layer is invoked to distribute the validated message according to the message type and retrieve local resources to return to the user.

[0022] This invention also provides a cross-sandbox secure communication system based on the Electron framework to improve development efficiency and solve the contradiction between browser sandbox environment and local resource access, the complexity of local executable program calls and parameter passing, and the compatibility problem caused by inconsistent cross-platform resource access interfaces. The system includes: a protocol layer, a middleware layer, and a service layer; the service layer includes a rendering process module, a main process module, a strategy server, and a local service integration module.

[0023] The protocol layer is used to unify the communication protocols, data structures, transmission rules, and interfaces between modules in the service layer; the interface is obtained by encapsulating the interfaces of different platforms after hiding the differences in the interfaces.

[0024] The middleware layer is used to perform permission verification, correctness verification and / or encryption on the data communicated between modules in the service layer, to isolate the rendering process module in a sandbox, and to distribute messages using a message router.

[0025] The rendering process module is used to receive messages from users carrying local resource access requests after the Electron main process starts successfully; encapsulate the messages; call the middleware layer to encrypt the parameters of the local resource access request in the encapsulated messages; call the protocol layer to send the encrypted messages to the main process module; and receive the local resources returned by the main process module and return them to the user.

[0026] The main process module is used to decrypt encrypted messages; call the middleware layer to perform permission and correctness checks on the decrypted messages; distribute the checked messages to the local service integration module according to the message type; receive local resources returned by the local service integration module and send them to the rendering process module.

[0027] The policy server is used to receive the request from the user to start the Electron main process through the main process module, and return the latest permission rule information and local registration protocol to the main process module so that the Electron main process can start successfully.

[0028] The local service integration module is used to receive verified messages and return local resources to the main process module.

[0029] This invention also provides a cross-sandbox secure communication device based on the Electron framework to improve development efficiency and resolve the contradictions between browser sandbox environments and local resource access, the complexity of local executable program calls and parameter passing, and the compatibility issues caused by inconsistent cross-platform resource access interfaces. The device includes:

[0030] The Electron main process start request receiving module is used to receive user requests to start the Electron main process;

[0031] The latest permission rule information determination module is used to determine the latest permission rule information and local registration agreement based on the request to start the Electron main process.

[0032] The parsing module is used to parse the latest permission rule information and local registration agreement;

[0033] The startup success message return module is used to start the Electron main process using the latest parsed permission rule information and local registration protocol, and return a startup success message to the user.

[0034] The message receiving module is used to receive messages from users carrying local resource access requests after the Electron main process starts successfully. The protocol layer is used to provide a unified communication protocol, data structure, transmission rules and interface. The interface is obtained by encapsulating the interfaces of different platforms after hiding the interface differences.

[0035] The verification module is used to encapsulate messages and call the middleware layer to perform permission verification and correctness verification on the encapsulated messages; the middleware layer is used to perform permission verification, correctness verification and / or encryption on data, and uses a message router to distribute messages.

[0036] The local resource return module is used to call the middleware layer to distribute the validated message according to the message type and retrieve the local resource to return to the user.

[0037] Compared with existing desktop application development technologies based on the Electron framework, this invention's embodiments involve: receiving a user's request to start the Electron main process; determining the latest permission rules and local registration protocol based on the request; parsing the latest permission rules and local registration protocol; starting the Electron main process using the parsed latest permission rules and local registration protocol; and returning a startup success message to the user. After the Electron main process starts successfully, the protocol layer is invoked to receive a message from the user carrying a local resource access request. The protocol layer provides a unified communication protocol. The system includes data structures, transmission rules, and interfaces. The interfaces are encapsulated from the hidden differences between different platforms. Messages are encapsulated, and the middleware layer is invoked to perform permission and correctness checks on the encapsulated messages. The middleware layer is used for permission checks, correctness checks, and / or encryption of data, and distributes messages using a message router. The middleware layer distributes the verified messages according to the message type, retrieves local resources, and returns them to the user. This improves development efficiency and resolves the contradictions between browser sandbox environments and local resource access, the complexity of local executable program calls and parameter passing, and compatibility issues caused by inconsistent cross-platform resource access interfaces. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0039] Figure 1 This is a structural diagram of a cross-sandbox secure communication system based on the Electron framework provided in an embodiment of the present invention;

[0040] Figure 2 This is a flowchart of a cross-sandbox secure communication system based on the Electron framework provided in an embodiment of the present invention;

[0041] Figure 3 A flowchart illustrating a specific example of a cross-sandbox secure communication system based on the Electron framework provided in this embodiment of the invention:

[0042] Figure 4 This is a flowchart illustrating a cross-sandbox secure communication method based on the Electron framework provided in an embodiment of the present invention;

[0043] Figure 5This is a schematic diagram of a cross-sandbox secure communication device based on the Electron framework provided in an embodiment of the present invention;

[0044] Figure 6 This is a schematic diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0046] The acquisition, storage, use, and processing of data in this application all comply with relevant regulations.

[0047] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0048] In the description of this specification, the terms "comprising," "including," "having," and "containing" are open-ended terms, meaning that they include but are not limited to. The terms "an embodiment," "a specific embodiment," "some embodiments," and "for example," etc., refer to specific features, structures, or characteristics described in connection with that embodiment or example that are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. The order of steps involved in the various embodiments is used to illustrate the implementation of this application, and the order of steps is not limited and can be adjusted appropriately as needed.

[0049] Based on the problems existing in the background technology described above, the embodiments of the present invention propose the following technical objectives:

[0050] 1) Construct a layered secure communication architecture:

[0051] Design a protocol-based communication layer between the main process and the rendering process, and achieve IPC logic decoupling through a unified interface definition (such as RPC protocol) to reduce redundant coding.

[0052] 2) Dynamic sandbox access control mechanism:

[0053] Establish a dynamic sandbox permission control mechanism by introducing a dynamic strategy engine into the preloaded script. Based on the request source (such as the rendering process URL) and operation type (file read / write / program call), a minimum permission whitelist is dynamically generated to block unauthorized resource access.

[0054] 3) Secure parameterization model for local program calls:

[0055] A secure parameterized model for local program calls is constructed, providing path isolation and parameter verification modules. The local program path is encapsulated as a controlled resource identifier (such as res: / / app / bin), and the integrity of the program is ensured by hash verification in the main process. At the same time, parameter templates (such as {path: string, hash: string}) are used to prevent injection attacks.

[0056] 4) Cross-platform resource access abstraction layer:

[0057] Abstracting system-level operations (such as file selectors and registry access) into platform-specific interfaces, they are automatically mapped to native implementations such as Windows COM, macOS, and Objective-C at the underlying level, automatically adapting to the native interfaces of different operating systems and reducing the cost of multi-platform adaptation.

[0058] Figure 1 This is a structural diagram of a cross-sandbox secure communication system based on the Electron framework provided in an embodiment of the present invention, as shown below. Figure 1 As shown, the system includes: a protocol layer, a middleware layer, and a service layer; the service layer includes a rendering process module, a main process module, a policy server, and a local service integration module.

[0059] The protocol layer is used to unify the communication protocols, data structures, transmission rules, and interfaces between modules in the service layer; the interface is obtained by encapsulating the interfaces of different platforms after hiding the differences in the interfaces.

[0060] The middleware layer is used to perform permission verification, correctness verification and / or encryption on the data communicated between modules in the service layer, to isolate the rendering process module in a sandbox, and to distribute messages using a message router.

[0061] The rendering process module is used to receive messages from users carrying local resource access requests after the Electron main process starts successfully; encapsulate the messages; call the middleware layer to encrypt the parameters of the local resource access request in the encapsulated messages; call the protocol layer to send the encrypted messages to the main process module; and receive the local resources returned by the main process module and return them to the user.

[0062] The main process module is used to decrypt encrypted messages; call the middleware layer to perform permission and correctness checks on the decrypted messages; distribute the checked messages to the local service integration module according to the message type; receive local resources returned by the local service integration module and send them to the rendering process module.

[0063] The policy server is used to receive the request from the user to start the Electron main process through the main process module, and return the latest permission rule information and local registration protocol to the main process module so that the Electron main process can start successfully.

[0064] The local service integration module is used to receive verified messages and return local resources to the main process module.

[0065] In this embodiment of the invention, the cross-sandbox secure communication system based on the Electron framework isolates the business logic of the service layer, which is divided into a rendering process module, a main process module, a policy server, and a local service integration module; or it layers the domain-driven design (DDD) framework, splitting the business logic into independent service modules (such as FileService and NetworkService), and decoupling them from the IPC layer through dependency injection (DI). It supports independent execution of unit tests, reducing debugging complexity.

[0066] Service layer IPC security model design: separation of main process and rendering process: a secure communication channel is established through Electron's ipcMain and ipcRenderer modules. All local resource access requests must be initiated by the rendering process and executed after being verified by the main process.

[0067] In one embodiment, the protocol layer is configured with a parameter verification mechanism to unify the data structure and transmission rules between the main process and the rendering process using a preset format, and to transmit path parameters using a preset format.

[0068] In one embodiment, the protocol layer provides decoupling between business logic and communication logic. A standardized communication protocol is defined within the protocol layer: a parameter validation mechanism based on JSON Schema is proposed, compatible with differences in Windows / Linux / macOS system calls, addressing platform limitations of traditional solutions (such as registry protocols). JSON (JavaScript Object Notation) Schema (a JSON-based format) is used to standardize message formats, unifying data structures and transmission rules between the main process and the rendering process; path parameters are passed in JSON format (e.g., {basePath: 'documents', fileName: 'test.txt'}), automatically converting Windows backslashes to Linux forward slashes through path parsing. Backward compatibility is achieved through protocol version control, avoiding communication interruptions due to protocol changes. The protocol layer abstracts the interface: encapsulates ipcMain (a module provided by Electron for the main process to receive messages) into a unified interface layer (e.g., the ChannelService class), exposing business-independent methods such as sendRequest and subscribeEvent, hiding the underlying IPC implementation details. Specifically, a unified API (Application Programming Interface) definition can be established, encapsulating file reading and writing, system dialog boxes, clipboard operations, etc., into the NativeService module, exposing common methods such as openFileDialog() and readFile(path) to the outside world, while hiding the differences in the underlying platform.

[0069] In one embodiment, the protocol layer is configured with a batch processing mechanism to aggregate high-frequency messages into batch requests; the protocol layer is also configured with a shared memory mechanism to provide a shared array buffer for the data stream; the protocol layer is also configured with a polymorphic invocation mechanism to create subclasses of adapters for different platforms, the subclasses inheriting from a base class, and polymorphically invoking the interfaces of different platforms based on the subclasses and the base class.

[0070] In addition, the protocol layer can be configured with mechanisms to optimize communication performance, such as batch processing: aggregating high-frequency small messages into batch requests (e.g., log reporting); shared memory: using SharedArrayBuffer for large data (e.g., image streams) to reduce serialization overhead; and compressed transmission: enabling the Brotli compression algorithm to reduce network load. Polymorphic Architecture: Creates subclasses WindowsAdapter, MacAdapter, and LinuxAdapter, inheriting from the PlatformAdapter base class, to implement polymorphic interface calls; Dynamic Loading Mechanism: When the main process starts, it detects the operating system via process.platform and dynamically loads the corresponding platform adaptation modules; Enhanced Electron Native API: Extends modules such as electron.dialog, for example, uniformly handling the differences in default directories across platforms in the file selector; Node.js Module Bridging: Encapsulates cross-platform file operations through the fs and path modules, and automatically handles path separator issues with path.join(); Secure IPC Channel Encapsulation: Exposes ipcRenderer.invoke('native: readFile', path) in the rendering process, and the main process calls the adaptation layer method through ipcMain.handle to achieve secure isolation; Efficient Binary Data Transmission: Uses electron.ipcRenderer.sendBuffer to transmit file stream data, avoiding the performance loss of JSON serialization.

[0071] In one embodiment, the middleware layer is configured with a preloaded script; the preloaded script includes a dynamic policy engine; the dynamic policy engine is used to perform permission verification on the data communicated between modules in the service layer based on the request source, operation type and dynamically generated minimum permission whitelist, and to block unauthorized data.

[0072] In this embodiment, the middleware layer enhances the `child_process` module (child process module) by employing the following strategies to improve security when using Node.js's `exec` / `spawn` methods: Whitelisting mechanism: A predefined list of allowed program paths is used to reject unauthorized execution requests. Permission isolation: The user identity for running the child process is set (e.g., the `runas` option in Windows). Resource limits: CPU / memory usage of the child process is limited using `ulimit` or third-party libraries.

[0073] In this embodiment, the middleware layer transmits dynamic parameters in encrypted form: sensitive parameters (such as file paths) are encrypted using AES (Advanced Encryption Standard), and the main process decrypts them before transmitting them to the local program to prevent man-in-the-middle attacks.

[0074] In this embodiment, the middleware layer uses regular expressions to restrict parameter format (such as allowing only alphanumeric characters and specific symbols) and escapes special characters to prevent command injection attacks.

[0075] In this embodiment, the middleware layer enables Electron's sandbox mode, restricting the rendering process's access to the Node.js API and exposing only whitelisted methods. The API is exported on demand via contextBridge in the preload script, thus achieving sandbox isolation of the rendering process module.

[0076] In one embodiment, the middleware layer is configured with a dynamic sandbox permission control mechanism. This mechanism includes a hierarchical permission policy, a permission update policy, a hash verification policy, and a parameter template policy. The hierarchical permission policy includes a pre-established permission hierarchy model. This model divides user permissions into two levels: users with basic permissions have the right to read basic configurations and / or the operating system version; users with restricted permissions require authorization via a pop-up window to access the user's document directory. The permission update policy updates permissions in real-time based on the monitoring results of the main process listening to the policy server. The hash verification policy verifies data integrity using a hash verification algorithm before local program calls. The parameter template policy uses a preset template to encapsulate parameters and then encrypts them for transmission.

[0077] In this embodiment, a dynamic sandbox permission control mechanism is also configured in the middleware layer:

[0078] A tiered permission strategy is implemented, establishing a hierarchical permission model that divides permissions into two levels:

[0079] Basic level: Reads basic configurations (such as operating system version);

[0080] Restricted level: Access to the user document directory (pop-up authorization required).

[0081] Dynamic policy updates are achieved by having the main process monitor the policy server to enable hot updates of permission rules.

[0082] Secure process communication architecture:

[0083] Rendering process isolation is achieved by enabling the `nodeIntegration:false` and `sandbox:true` configurations of BrowserWindow, which prevent the rendering process from directly accessing Node.js.

[0084] In proxy-based IPC communication, the rendering process sends resource requests to the main process through a preloaded script, and the main process executes the operation after verifying permissions.

[0085] Runtime dynamic authorization mechanism:

[0086] User interactive authorization triggers a system-level pop-up window (using the electron.dialog module) for sensitive operations, and the authorization result is recorded to encrypted local storage.

[0087] Behavioral baseline monitoring is implemented, a resource access whitelist is established, and automatic permission revocation is triggered for non-routine operations (such as frequent reading of system logs).

[0088] Security enhancement technologies:

[0089] Resource access is sandboxed, creating an independent file system view for each rendering process and restricting visible directories through the chroot mechanism.

[0090] Code integrity verification involves checking the digital signature when the main process loads a native module to prevent malicious code injection.

[0091] In one embodiment, the middleware layer can also be configured with mechanisms to decouple communication logic, such as: message routing mechanism: introducing a message router to automatically distribute messages to the corresponding processing modules based on message type, supporting dynamic registration / deregistration of processors, and avoiding global state pollution; security interceptor: inserting an interception layer into the communication link to implement: parameter validation: verifying message format and data range (such as file path validity); permission check: restricting sensitive operations based on user roles (such as system-level API calls); encrypted transmission: using AES-GCM encryption for sensitive data to prevent man-in-the-middle attacks; asynchronous task queue: introducing a queue system (such as BullMQ) for time-consuming operations (such as file transcoding), processed by worker processes to avoid blocking the main process, and combining progress event feedback (job.progress) to achieve real-time status updates.

[0092] In one embodiment, the main process module is further configured to receive a user's request to start the Electron main process; request the latest permission rule information and local registration protocol from the policy server based on the request; receive the latest permission rule information and local registration protocol returned by the policy server; parse the latest permission rule information and local registration protocol; update the permission rule information and local registration protocol already stored in the main process module using the parsed latest permission rule information and local registration protocol; encrypt and store the updated permission rule information and local registration protocol; and return a startup success message to the user.

[0093] In one embodiment, the rendering process module is also used to receive user configuration operations on permission rule information, send the configured permission rule information to the policy server, and receive the first update success information returned by the policy server and forward it to the user.

[0094] In one embodiment, after receiving permission rule information from the rendering process module, the policy server parses and stores the permission rule information, and returns a first update success message to the rendering process module.

[0095] In one embodiment, the rendering process module is also used to receive user configuration operations on the local registration protocol, send the configured local registration protocol to the policy server, and receive the second update success information returned by the policy server and forward it to the user.

[0096] In one embodiment, after receiving the local registration protocol from the rendering process module, the policy server parses and stores the local registration protocol, and returns a second update success message to the rendering process module.

[0097] Dynamic protocol binding enables runtime dynamic registration / deregistration of protocols, allowing the browser sandbox to trigger local program execution via URL (Uniform Resource Locator) parameters, and supports parameter encryption and verification mechanisms. This avoids the operational risks of manually modifying the registry required by traditional solutions, and improves deployment flexibility.

[0098] In one embodiment, a local resource access request includes a request to launch a local program and / or a request to access a local file.

[0099] In one embodiment, the system performs secondary encapsulation of Electron's IPC (Inter-Process Communication), file I / O, and window management modules to reduce development complexity and improve functional reusability. It supports bidirectional communication between the main process and the rendering process based on IPC, enabling asynchronous data transmission and event-driven interaction. It also incorporates the WebSocket protocol to achieve long-term communication between the browser and local backend services, expanding application scenarios. Digital signature verification is performed on local program calls, and sensitive operations are restricted through operating system permission management.

[0100] Figure 2 This is a flowchart of a cross-sandbox secure communication system based on the Electron framework provided in an embodiment of the present invention, such as... Figure 2 As shown, the logical flow of a cross-sandbox secure communication system based on the Electron framework is as follows:

[0101] (1) Configure permission rule information:

[0102] Users send configuration operations for permission rules to the rendering process module; the rendering process module can be the browser rendering process (Chromium sandbox environment);

[0103] The rendering process module receives user configuration operations for permission rules and sends the configured permission rules to the policy server.

[0104] After receiving the permission rule information from the rendering process module, the policy server parses and stores the permission rule information, and returns the first update success information to the rendering process module.

[0105] The rendering process module receives the first update success message returned by the policy server and forwards it to the user, indicating that the update was successful.

[0106] (2) Configure the local registration agreement:

[0107] The user sends configuration operations for the local registration protocol to the rendering process module;

[0108] The rendering process module receives the user's configuration operation for the local registration protocol and sends the configured local registration protocol to the policy server.

[0109] After receiving the local registration protocol from the rendering process module, the policy server parses and stores the local registration protocol, and returns a second update success message to the rendering process module.

[0110] The rendering process module receives the second update success message returned by the policy server and forwards it to the user, indicating that the update was successful.

[0111] (3) Start the Electron main process:

[0112] The user sends a request to the main process module to start the Electron main process; the main process module can be the Electron main process (in the native Node.js environment);

[0113] The main process module receives a request from the user to start the Electron main process; based on the request, it requests the latest permission rules information and local registration agreement from the policy server.

[0114] The policy server returns the latest permission rules information and local registration agreement based on the request;

[0115] The main process module receives the latest permission rule information and local registration protocol returned by the policy server; parses the latest permission rule information and local registration protocol; updates the permission rule information and local registration protocol already stored in the main process module using the parsed latest permission rule information and local registration protocol; encrypts the updated permission rule information and local registration protocol before storing them; and returns a startup success message to the user, indicating that the Electron main process has started successfully.

[0116] Figure 3 This is a flowchart illustrating a specific example of a cross-sandbox secure communication system based on the Electron framework provided in this embodiment of the invention. Figure 3 As shown, the logical flow of a cross-sandbox secure communication system based on the Electron framework also includes:

[0117] (4) Accessing local resources:

[0118] It is divided into launching local programs and / or accessing local files;

[0119] 1) Start the local program:

[0120] The user sends a message to the rendering process module carrying a request to start the local program (A.exe);

[0121] The rendering process module receives a message from the user carrying a request to start a local program; encapsulates the message; calls the middleware layer to encrypt the parameters of the request to start a local program in the encapsulated message; and calls the protocol layer to send the encrypted message to the main process module.

[0122] The main process module is used to decrypt encrypted messages; it calls the middleware layer to perform permission and correctness checks on the decrypted messages; and it distributes the verified messages to the local service integration module (local program startup service AService) according to the message type. The local service integration module can include local executable programs (A.exe) and local data files.

[0123] The local service integration module starts the local program (A) based on the message and returns a startup success message to the main process module;

[0124] The main process module will send a startup success message to the rendering process module;

[0125] The rendering process module receives a startup success message and returns it to the user, indicating that the local program has started successfully.

[0126] 2) Local file access:

[0127] The user sends a message carrying a local file access request to the rendering process module; the local file access request is used to retrieve file B in the local / app / data directory.

[0128] The rendering process module receives a message from the user carrying a local file access request; encapsulates the message; calls the middleware layer to encrypt the parameters of the local file access request in the encapsulated message; and calls the protocol layer to send the encrypted message to the main process module.

[0129] The main process module is used to decrypt encrypted messages; call the middleware layer to perform permission and correctness checks on the decrypted messages; and distribute the verified messages to the local service integration module (local program starts service BService) according to the message type.

[0130] The local service integration module returns a binary stream of file B to the main process module based on the message;

[0131] The main process module sends the binary stream of file B to the rendering process module;

[0132] The rendering process module receives the binary stream of file B, visualizes the binary stream of file B, and returns file B to the user so that the user can view file B.

[0133] The following is a specific implementation example:

[0134] 1) Users log in to the "Geophysical Data Management System" through a browser;

[0135] 2) From the browser software module, click the "software icon";

[0136] 3) The browser calls the local Electron-Agent to parse the startup parameters received from the browser;

[0137] 4) Electron-Agent calls the local executable program scheduling service to start the local software's executable program (.exe), thereby launching the software.

[0138] This invention also proposes a cross-sandbox secure communication method based on the Electron framework. Its principle is similar to that of the cross-sandbox secure communication system based on the Electron framework, and will not be described in detail here.

[0139] Figure 4 This is a flowchart illustrating a cross-sandbox secure communication method based on the Electron framework provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the method may include:

[0140] Step 401: Receive the user's request to start the Electron main process;

[0141] Step 402: Determine the latest permission rules and local registration agreement based on the request to start the Electron main process;

[0142] Step 403: Parse the latest permission rules information and local registration agreement;

[0143] Step 404: Start the Electron main process using the parsed latest permission rule information and local registration protocol, and return a startup success message to the user;

[0144] Step 405: After the Electron main process starts successfully, the protocol layer is called to receive the message sent by the user carrying a request for access to local resources. The protocol layer is used to provide a unified communication protocol, data structure, transmission rules and interface. The interface is obtained by encapsulating the interfaces of different platforms after hiding the interface differences.

[0145] Step 406: Encapsulate the message and call the middleware layer to perform permission verification and correctness verification on the encapsulated message; the middleware layer is used to perform permission verification, correctness verification and / or encryption on the data, and to distribute the message using the message router.

[0146] Step 407: The middleware layer is invoked to distribute the validated message according to the message type and retrieve local resources to return to the user.

[0147] The embodiments of the present invention can improve development efficiency through the above steps, and solve the contradiction between browser sandbox environment and local resource access, the complexity of local executable program calls and parameter passing, and the compatibility problem caused by inconsistent cross-platform resource access interfaces.

[0148] In one embodiment, the middleware layer is configured with a preloaded script; the preloaded script includes a dynamic policy engine; the dynamic policy engine is used to perform permission verification on data based on the request source, operation type, and dynamically generated minimum permission whitelist, and to block unauthorized data.

[0149] In one embodiment, the cross-sandbox secure communication method based on the Electron framework further includes:

[0150] Receive user configuration operations for permission rules;

[0151] The configured permission rules are parsed and then stored.

[0152] Return a message to the user indicating that the first update was successful.

[0153] In one embodiment, the cross-sandbox secure communication method based on the Electron framework further includes:

[0154] Receive user configuration operations for the local registration agreement;

[0155] The configured local registration protocol is parsed and stored.

[0156] Return a second update success message to the user.

[0157] In one embodiment, a local resource access request includes a request to launch a local program and / or a request to access a local file.

[0158] In one embodiment, the middleware layer is configured with a dynamic sandbox permission control mechanism; the dynamic sandbox permission control mechanism includes a hierarchical permission policy, a permission update policy, a hash verification policy, and a parameter template policy;

[0159] The hierarchical permission policy includes a pre-established permission hierarchy model; the permission hierarchy model is used to divide user permissions into two levels: in the permission hierarchy model, users with basic permissions have the permission to read basic configuration and / or operating system version; in the permission hierarchy model, users with restricted permissions need to grant authorization through a pop-up window to have the permission to access the user's document directory;

[0160] The permission update strategy involves the main process monitoring the policy server and updating permissions in real time based on the monitoring results.

[0161] Hash verification strategy is used to verify data integrity using hash verification algorithm before local program calls;

[0162] The parameter template strategy is used to encapsulate parameters using a preset template and then transmit them encrypted.

[0163] In one embodiment, the protocol layer is configured with a parameter verification mechanism to unify the data structure and transmission rules between the main process and the rendering process using a preset format, and to transmit path parameters using a preset format.

[0164] In one embodiment, the protocol layer is configured with a batch processing mechanism to aggregate high-frequency messages into batch requests;

[0165] The protocol layer is also configured with a shared memory mechanism to provide a shared array buffer for the data stream;

[0166] The protocol layer is also configured with a polymorphic invocation mechanism to create subclasses of adapters for different platforms. The subclasses inherit from a base class and polymorphically invoke the interfaces of different platforms based on the subclasses and the base class.

[0167] This invention also proposes a cross-sandbox secure communication device based on the Electron framework. Its principle is similar to the cross-sandbox secure communication method and system based on the Electron framework, and will not be described in detail here.

[0168] Figure 5 This is a schematic diagram of a cross-sandbox secure communication device based on the Electron framework provided in an embodiment of the present invention, as shown below. Figure 5 As shown, a cross-sandbox secure communication device based on the Electron framework may include:

[0169] The Electron main process start request receiving module 501 is used to receive the user's request to start the Electron main process;

[0170] The latest permission rule information determination module 502 is used to determine the latest permission rule information and local registration agreement based on the request to start the Electron main process;

[0171] Parsing module 503 is used to parse the latest permission rule information and local registration agreement;

[0172] The startup success message return module 504 is used to start the Electron main process using the latest parsed permission rule information and local registration protocol, and return a startup success message to the user.

[0173] The message receiving module 505 is used to receive messages carrying local resource access requests from users by calling the protocol layer after the Electron main process starts successfully. The protocol layer is used to provide a unified communication protocol, data structure, transmission rules and interface. The interface is obtained by encapsulating the interfaces of different platforms after hiding the interface differences.

[0174] The verification module 506 is used to encapsulate messages and call the middleware layer to perform permission verification and correctness verification on the encapsulated messages; the middleware layer is used to perform permission verification, correctness verification and / or encryption on data, and to distribute messages using a message router.

[0175] The local resource return module 507 is used to call the middleware layer to distribute the validated message according to the message type and retrieve the local resource to return to the user.

[0176] In one embodiment, the middleware layer is configured with a preloaded script; the preloaded script includes a dynamic policy engine; the dynamic policy engine is used to perform permission verification on data based on the request source, operation type, and dynamically generated minimum permission whitelist, and to block unauthorized data.

[0177] In one embodiment, the Electron-based cross-sandbox secure communication device further includes:

[0178] Receive user configuration operations for permission rules;

[0179] The configured permission rules are parsed and then stored.

[0180] Return a message to the user indicating that the first update was successful.

[0181] In one embodiment, the Electron-based cross-sandbox secure communication device further includes:

[0182] Receive user configuration operations for the local registration agreement;

[0183] The configured local registration protocol is parsed and stored.

[0184] Return a second update success message to the user.

[0185] In one embodiment, a local resource access request includes a request to launch a local program and / or a request to access a local file.

[0186] In one embodiment, the middleware layer is configured with a dynamic sandbox permission control mechanism; the dynamic sandbox permission control mechanism includes a hierarchical permission policy, a permission update policy, a hash verification policy, and a parameter template policy;

[0187] The hierarchical permission policy includes a pre-established permission hierarchy model; the permission hierarchy model is used to divide user permissions into two levels: in the permission hierarchy model, users with basic permissions have the permission to read basic configuration and / or operating system version; in the permission hierarchy model, users with restricted permissions need to grant authorization through a pop-up window to have the permission to access the user's document directory;

[0188] The permission update strategy involves the main process monitoring the policy server and updating permissions in real time based on the monitoring results.

[0189] Hash verification strategy is used to verify data integrity using hash verification algorithm before local program calls;

[0190] The parameter template strategy is used to encapsulate parameters using a preset template and then transmit them encrypted.

[0191] In one embodiment, the protocol layer is configured with a parameter verification mechanism to unify the data structure and transmission rules between the main process and the rendering process using a preset format, and to transmit path parameters using a preset format.

[0192] In one embodiment, the protocol layer is configured with a batch processing mechanism to aggregate high-frequency messages into batch requests;

[0193] The protocol layer is also configured with a shared memory mechanism to provide a shared array buffer for the data stream;

[0194] The protocol layer is also configured with a polymorphic invocation mechanism to create subclasses of adapters for different platforms. The subclasses inherit from a base class and polymorphically invoke the interfaces of different platforms based on the subclasses and the base class.

[0195] Compared with existing desktop application development technologies based on the Electron framework, this invention's embodiments involve: receiving a user's request to start the Electron main process; determining the latest permission rules and local registration protocol based on the request; parsing the latest permission rules and local registration protocol; starting the Electron main process using the parsed latest permission rules and local registration protocol; and returning a startup success message to the user. After the Electron main process starts successfully, the protocol layer is invoked to receive a message from the user carrying a local resource access request. The protocol layer provides a unified communication protocol. The system includes data structures, transmission rules, and interfaces. The interfaces are encapsulated from the hidden differences between different platforms. Messages are encapsulated, and the middleware layer is invoked to perform permission and correctness checks on the encapsulated messages. The middleware layer is used for permission checks, correctness checks, and / or encryption of data, and distributes messages using a message router. The middleware layer distributes the verified messages according to the message type, retrieves local resources, and returns them to the user. This improves development efficiency and resolves the contradictions between browser sandbox environments and local resource access, the complexity of local executable program calls and parameter passing, and compatibility issues caused by inconsistent cross-platform resource access interfaces.

[0196] The following effects can be achieved through the embodiments of the present invention:

[0197] By aggregating high-frequency messages through batch processing, Brotli compression reduces transmission load by more than 30%; it supports offline data storage and latency synchronization, adapting to network-constrained scenarios.

[0198] 1) Enhance protocol communication and local program invocation capabilities:

[0199] (1) Deep integration of custom protocols

[0200] Seamless interaction between the browser and the local Electron application can be achieved by registering a custom protocol (such as myapp: / / params). For example, clicking a webpage link can trigger the local application to start and pass parameters, supporting complex parameter parsing (such as action=open&file=test.txt).

[0201] (2) Secure Inter-Process Communication (IPC)

[0202] The main process (Node.js) and the rendering process (Chromium) exchange data via IPC, preserving the web development experience while allowing secure access to local resources. For example, the rendering process sends requests via ipcRenderer, and the main process performs file read / write operations and returns the results.

[0203] 2) Enhance local data persistence and manipulation capabilities:

[0204] (1) Flexible local storage solutions

[0205] It supports two modes: localStorage (browser-based) and electron-store (based on the Node.js file system). The latter can store a larger amount of data (such as user configurations and offline caches).

[0206] Structured data management can be achieved using lightweight databases such as LowDB, which is suitable for scenarios with frequent CRUD operations.

[0207] (2) System-level file access

[0208] Electron can directly read and write local files using Node.js's fs module, bypassing browser sandbox restrictions. For example, after receiving a file path parameter from a webpage, Electron can open the local file and return the content to the frontend.

[0209] 3) Cross-platform compatibility extension:

[0210] (1) Unified interface for adapting to different systems

[0211] Electron automatically wraps the differences in underlying APIs between Windows, macOS, and Linux, for example:

[0212] The file dialog calls dialog.showOpenDialog, which is mapped to the Windows COM interface or macOS Objective-C method 5.

[0213] System notifications are implemented through the Notification module, which automatically matches the native styles of each platform.

[0214] (2) Performance optimization under hybrid architecture

[0215] By combining Web Workers to handle computationally intensive tasks (such as big data parsing), the main process is responsible for I / O operations, thus avoiding UI lag.

[0216] 4) Enterprise-level scenario verification:

[0217] (1) Support for offline and network-restricted environments

[0218] Electron applications can run completely without a browser, supporting offline data storage and delayed synchronization (such as an airline dispatch system being able to operate a local database even when the network is down).

[0219] (2) Safety reinforcement practices

[0220] ContextIsolation isolates the rendering process from the Node.js environment to prevent XSS attacks.

[0221] Use code signing to verify the application's origin and prevent malicious programs from impersonating it.

[0222] This invention also provides a computer device. Figure 6 This is a schematic diagram of a computer device in an embodiment of the present invention. The computer device 600 includes a memory 610, a processor 620, and a computer program 630 stored in the memory 610 and executable on the processor 620. When the processor 620 executes the computer program 630, it implements the above-mentioned cross-sandbox secure communication method based on the Electron framework.

[0223] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described cross-sandbox secure communication method based on the Electron framework.

[0224] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described cross-sandbox secure communication method based on the Electron framework.

[0225] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0226] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0227] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0228] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0229] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A cross-sandbox secure communication method based on Electron framework, characterized in that, include: Receive a user's request to start the Electron main process; Determine the latest permission rules and local registration agreement based on the request to start the Electron main process; The latest permission rules and local registration agreement are parsed. The Electron main process is started using the latest parsed permission rules and local registration protocol, and a startup success message is returned to the user. After the Electron main process starts successfully, the protocol layer is invoked to receive messages from users that carry requests for access to local resources. The protocol layer is used to provide a unified communication protocol, data structure, transmission rules and interface; the interface is obtained by encapsulating the interfaces of different platforms after hiding the interface differences; The message is encapsulated, and the middleware layer is invoked to perform permission verification and correctness verification on the encapsulated message; the middleware layer is used to perform permission verification, correctness verification and / or encryption on the data, and to distribute the message using a message router. The middleware layer is invoked to distribute the validated message according to the message type and retrieve local resources to return to the user.

2. The method of claim 1, wherein, The middleware layer is configured with a preloaded script; the preloaded script includes a dynamic strategy engine; the dynamic strategy engine is used to perform permission verification on data based on the request source, operation type, and dynamically generated minimum permission whitelist, and to block unauthorized data.

3. The method of claim 1, wherein, Also includes: Receive user configuration operations for permission rules; The configured permission rules are parsed and then stored. Return a message to the user indicating that the first update was successful.

4. The method of claim 3, wherein, Also includes: Receive user configuration operations for the local registration agreement; The configured local registration protocol is parsed and stored. Return a second update success message to the user.

5. The method of claim 4, wherein, The local resource access request includes a request to start a local program and / or a request to access a local file.

6. The method of claim 1, wherein, The middleware layer is configured with a dynamic sandbox permission control mechanism; the dynamic sandbox permission control mechanism includes a hierarchical permission policy, a permission update policy, a hash verification policy, and a parameter template policy. The hierarchical permission policy includes a pre-established permission hierarchy model; The permission hierarchy model is used to divide user permissions into two levels: In the permission hierarchy model, users with basic permissions have the permission to read basic configuration and / or operating system version; users with restricted permissions in the permission hierarchy model need to grant authorization through a pop-up window to have the permission to access the user document directory. The permission update strategy involves the main process monitoring the policy server and updating permissions in real time based on the monitoring results. The hash verification strategy is used to verify data integrity through a hash verification algorithm before local program calls; The parameter template strategy is used to encapsulate parameters using a preset template and then transmit them encrypted.

7. The method of claim 1, wherein, The protocol layer is configured with a parameter verification mechanism to unify the data structure and transmission rules between the main process and the rendering process using a preset format, and to transmit path parameters using a preset format.

8. The method of claim 1, wherein, The protocol layer is configured with a batch processing mechanism to aggregate high-frequency messages into batch requests; The protocol layer is also configured with a shared memory mechanism to provide a shared array buffer for the data stream; The protocol layer is also configured with a polymorphic invocation mechanism for creating subclasses of adapters for different platforms. The subclasses inherit from a base class and polymorphically invoke the interfaces of different platforms based on the subclasses and the base class.

9. A cross-sandbox secure communication system based on Electron framework, characterized in that, include: The system comprises a protocol layer, a middleware layer, and a service layer; the service layer includes a rendering process module, a main process module, a strategy server, and a local service integration module. The protocol layer is used to unify the communication protocols, data structures, transmission rules, and interfaces between modules in the service layer; the interface is obtained by encapsulating the interfaces of different platforms after hiding the interface differences; The middleware layer is used to perform permission verification, correctness verification and / or encryption on the data communicated between modules in the service layer, to isolate the rendering process module in a sandbox, and to distribute messages using a message router. The rendering process module is used to receive messages from users carrying local resource access requests after the Electron main process starts successfully. The message is encapsulated; the middleware layer is invoked to encrypt the parameters of the local resource access request in the encapsulated message; the protocol layer is invoked to send the encrypted message to the main process module; the local resources returned by the main process module are received and returned to the user. The main process module is used to decrypt encrypted messages; call the middleware layer to perform permission and correctness verification on the decrypted messages; distribute the verified messages to the local service integration module according to the message type; receive local resources returned by the local service integration module and send them to the rendering process module. The policy server is used to receive the request from the user to start the Electron main process through the main process module, and return the latest permission rule information and local registration protocol to the main process module so that the Electron main process starts successfully. The local service integration module is used to receive the verified message and return local resources to the main process module.

10. The system as described in claim 9, characterized in that, The middleware layer is configured with a preloaded script; the preloaded script includes a dynamic strategy engine; the dynamic strategy engine is used to perform permission verification on the data communicated between modules in the service layer based on the request source, operation type and dynamically generated minimum permission whitelist, and to block unauthorized data.

11. The system of claim 10, wherein, The main process module is also used to receive a user's request to start the Electron main process; request the latest permission rule information and local registration protocol from the policy server according to the request to start the Electron main process; and receive the latest permission rule information and local registration protocol returned by the policy server. The system parses the latest permission rules and local registration protocol; updates the permission rules and local registration protocol stored in the main process module using the parsed latest permission rules and local registration protocol; encrypts the updated permission rules and local registration protocol before storing them; and returns a startup success message to the user.

12. The system of claim 11, wherein, The rendering process module is also used to receive user configuration operations for permission rule information, send the configured permission rule information to the policy server, and receive the first update success information returned by the policy server and forward it to the user.

13. The system of claim 12, wherein, The policy server is used to parse and store the permission rule information after receiving it from the rendering process module, and then return the first update success information to the rendering process module.

14. The system of claim 13, wherein, The rendering process module is also used to receive user configuration operations for the local registration protocol, send the configured local registration protocol to the policy server, and receive the second update success information returned by the policy server and forward it to the user.

15. The system of claim 14, wherein, The policy server is used to parse and store the local registration protocol after receiving it from the rendering process module, and then return a second update success message to the rendering process module.

16. The system of claim 9, wherein, The middleware layer is configured with a dynamic sandbox permission control mechanism; the dynamic sandbox permission control mechanism includes a hierarchical permission policy, a permission update policy, a hash verification policy, and a parameter template policy. The hierarchical permission policy includes a pre-established permission hierarchy model; The permission hierarchy model is used to divide user permissions into two levels: In the permission hierarchy model, users with basic permissions have the permission to read basic configuration and / or operating system version; users with restricted permissions in the permission hierarchy model need to grant authorization through a pop-up window to have the permission to access the user document directory. The permission update strategy involves the main process monitoring the policy server and updating permissions in real time based on the monitoring results. The hash verification strategy is used to verify data integrity through a hash verification algorithm before local program calls; The parameter template strategy is used to encapsulate parameters using a preset template and then transmit them encrypted.

17. The system of claim 9, wherein, The protocol layer is configured with a parameter verification mechanism to unify the data structure and transmission rules between the main process and the rendering process using a preset format, and to transmit path parameters using a preset format.

18. The system of claim 9, wherein, The protocol layer is configured with a batch processing mechanism to aggregate high-frequency messages into batch requests; The protocol layer is also configured with a shared memory mechanism to provide a shared array buffer for the data stream; The protocol layer is also configured with a polymorphic invocation mechanism for creating subclasses of adapters for different platforms. The subclasses inherit from a base class and polymorphically invoke the interfaces of different platforms based on the subclasses and the base class.

19. The system of any of claims 9-18, wherein, The local resource access request includes a request to start a local program and / or a request to access a local file.

20. An Electron framework based cross-sandbox secure communication apparatus, characterized in that, include: The Electron main process start request receiving module is used to receive user requests to start the Electron main process; The latest permission rule information determination module is used to determine the latest permission rule information and local registration agreement based on the request to start the Electron main process. The parsing module is used to parse the latest permission rule information and local registration agreement; The startup success message return module is used to start the Electron main process using the latest parsed permission rule information and local registration protocol, and return a startup success message to the user. The message receiving module is used to receive messages from users carrying local resource access requests after the Electron main process starts successfully by calling the protocol layer. The protocol layer is used to provide a unified communication protocol, data structure, transmission rules and interface; the interface is obtained by encapsulating the interfaces of different platforms after hiding the interface differences; The verification module is used to encapsulate messages and call the middleware layer to perform permission verification and correctness verification on the encapsulated messages; the middleware layer is used to perform permission verification, correctness verification and / or encryption on data, and to distribute messages using a message router. The local resource return module is used to call the middleware layer to distribute the validated message according to the message type and retrieve the local resource to return to the user.

21. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 8.

22. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

23. A computer program product, characterised in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images