A local service communication method, electronic device, storage medium and program product

Abstract

Embodiments of the present application provide a local service communication method, electronic equipment, storage medium and program product, the method comprises: in the script running environment of a web page, running the first content script injected by the browser extension, redefine the network communication constructor function as the proxy constructor function; through the proxy constructor function, intercept the communication request initiated by the web page for the local service, and pass the communication request to the isolated running environment where the second content script injected by the browser extension through the page message passing interface; through the second content script, the communication request is forwarded to the background service process of the browser extension by using the extension message passing interface; through the background service process, based on the communication request and the local service, a network connection is established to complete the data interaction between the web page and the local service. Realize the safe and stable data interaction between the web page and the local service, and the transparency of the web page front-end code.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and more specifically, to a local service communication method, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of Web technologies, more and more enterprise applications are migrating from desktop clients to browser-based web applications. However, in scenarios such as hardware-level secure authentication, access to intranet and underlying system capabilities, and industrial IoT terminal access, Web applications are limited by browser security sandboxes. Pages still need to rely on local services deployed on the local machine as an intermediary to bridge the gap and access local hardware and underlying capabilities.

[0003] Among them, the local service relay solution is simple to implement and has an open protocol, making it the industry mainstream for a long time. Its core idea is: deploy and start an HTTP or WebSocket service locally, and the business web page directly initiates network requests to communicate with the local service through an HTTP or WebSocket created by the SDK, with the local service handling the underlying data exchange.

[0004] However, as browsers continue to strengthen their security policies, especially with the tightening of Cross-Origin Server (CORS) restrictions, mixed content blocking, and Local Network Access (LNA) policies, direct connections to local services face increasing limitations. For example: public web pages fetching / XHR (including AJAX) accessing local HTTP services constitutes cross-origin requests, and all cross-origin requests require the server to configure CORS response headers; mixed content blocking: public HTTPS pages cannot reliably access local HTTP or WS services, requiring the use of HTTPS or WSS protocols and TLS certificates, which increases the deployment complexity of local services; Local Network Access (LNA): even if local services use HTTPS or WSS protocols, public web pages cannot directly access them, and browsers will prompt users for permission by default; if the user chooses to block, the service will become unavailable. These factors have gradually reduced the practicality of direct connections to local services, resulting in a worse user experience. At the same time, there is also the challenge of restoring local communication capabilities without rewriting the SDK, given the large number of existing business systems that cannot be modified. Summary of the Invention

[0005] The purpose of this application is to provide a local service communication method, electronic device, storage medium, and program product to achieve secure and stable data interaction between web pages and local services that is transparent to the web page front-end code.

[0006] A first aspect of this application provides a local service communication method, the method comprising: In the script execution environment of the webpage, the first content script injected by the browser extension is executed, and the network communication constructor is redefined as the proxy constructor. The proxy constructor intercepts the communication requests initiated by the webpage for local services, and passes the communication requests to the isolated runtime environment where the second content script injected by the browser extension is located through the page message passing interface; The second content script uses an extended messaging interface to forward the communication request to the background service process of the browser extension. The background service process establishes a network connection with the local service based on the communication request to complete the data interaction between the webpage and the local service.

[0007] In the above implementation process, by injecting dual content scripts through browser extensions and combining them with cross-environment message passing, the restricted network requests of the webpage are intercepted and forwarded to the extension background process with higher network privileges for execution. This bypasses the browser's security restrictions on webpages directly accessing local services, and realizes secure, stable, and transparent data interaction between the webpage and local services to the webpage front-end code.

[0008] Furthermore, in the script execution environment of the webpage, the first content script injected by the browser extension is run, and the network communication constructor is redefined as the proxy constructor, including: Before the page script of the webpage is executed, the first content script is run, and the reference of the global network communication constructor in the script runtime environment is set to the proxy constructor.

[0009] In the above implementation process, by injecting and running the first content script before the execution of the webpage's own script, the reference to the global network communication constructor is replaced with the proxy constructor, ensuring that all subsequent network requests initiated by the webpage based on the global constructor can be intercepted and taken over without omission.

[0010] Furthermore, the step of intercepting communication requests initiated by the webpage for local services through the proxy constructor and passing the communication requests to the isolated runtime environment where the second content script injected by the browser extension resides through the page messaging interface includes: The proxy constructor captures the communication request initiated by the page script of the webpage and extracts the target connection parameters in the communication request; The proxy constructor generates a connection identifier for the communication connection, constructs a cross-context message object based on the target connection parameters and the connection identifier, and calls the page messaging interface to send the cross-context message object carrying the connection identifier to the second content script running in the isolated runtime environment.

[0011] In the above implementation process, the target connection parameters in the communication request are extracted through the proxy constructor, a connection identifier is generated for the communication connection, and it is then normalized and encapsulated into a cross-context message object carrying the connection identifier and sent using the page message passing interface. This realizes the secure transmission of network request data from the main webpage environment to the extended isolation environment, which not only ensures the complete extraction and accurate routing of key request information, but also follows the browser's cross-context communication security mechanism, laying a reliable data foundation for the subsequent extended background process to take over and establish a real local network connection.

[0012] Further, the step of forwarding the communication request to the browser extension's background service process via the second content script using the extended messaging interface includes: The cross-context message object is passed through via the second content script; The second content script calls the extended messaging interface to forward the cross-context message object carrying the connection identifier to the background service process.

[0013] In the above implementation process, a connection identifier is generated for the communication connection through the proxy constructor and passed through by the second content script. This realizes message matching and status tracking between the web environment and the extended background process based on the connection identifier, effectively avoiding response disorder or loss when multiple connections are concurrent.

[0014] Furthermore, the step of establishing a network connection with the local service based on the communication request through the background service process to complete the data interaction between the webpage and the local service includes: The background service process parses the communication request and initiates a connection request to the local service based on a preset network communication protocol; After establishing a connection with the local service, the request data corresponding to the communication request is sent to the local service; The system obtains the response data carrying the connection identifier returned by the local service, and returns the response data to the script execution environment of the webpage through the extended messaging interface and the page messaging interface, so that the proxy constructor can distribute the response data to the corresponding page script based on the connection identifier.

[0015] In the above implementation process, a network connection is established between the webpage and the local service through a background service process to forward data, which breaks through the security restrictions of the browser sandbox and enables the webpage to securely access local resources. At the same time, a complete data return method is constructed by combining connection identifiers and dual message passing interfaces, which ensures the connectivity of cross-environment data interaction and the accurate routing of response results in high-concurrency scenarios.

[0016] Furthermore, the background service process runs in a privileged execution context with local network access permissions; the network connection is not subject to the restrictions of the web security sandbox.

[0017] In the above implementation process, by placing the background service process in a privileged execution context and removing the restrictions on network connections imposed by the web security sandbox, the browser's native security policy on web page access to the local network is broken, enabling the web page to communicate with local services in compliance with regulations by leveraging the high privileges of the extended background.

[0018] Furthermore, the network communication constructor includes a network socket constructor or a Hypertext Transfer Protocol request constructor; the network connection includes a long connection or a short connection.

[0019] In the above implementation process, by being compatible with various network communication constructors and connection types, the system can flexibly adapt to appropriate communication modes according to the interface specifications of local services and the needs of business scenarios. For example, high-frequency real-time interaction uses WebSocket long connections, while low-frequency single calls use HTTP short connections. This improves the protocol compatibility, scenario adaptability, and transmission efficiency of data interaction between web pages and local services.

[0020] A second aspect of this application provides an electronic device, the electronic device comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements any of the methods described in the first aspect.

[0021] A third aspect of this application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement any of the methods described in the first aspect.

[0022] A fourth aspect of this application provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements any of the methods described in the first aspect. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1A flowchart illustrating a local service communication method provided in an embodiment of this application; Figure 2 A schematic diagram of a system architecture for communication between a webpage and a local service, provided as an embodiment of this application; Figure 3 An interactive flowchart for intercepting and forwarding WebSocket requests is provided in an embodiment of this application; Figure 4 A timing diagram illustrating the multi-stage interaction between a browser extension and a local service, provided in an embodiment of this application; Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0026] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] To address any of the problems raised above, embodiments of this application provide a local service communication method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a local service communication method provided in an embodiment of this application.

[0028] In this embodiment, the method includes: Step S10: In the script execution environment of the webpage, run the first content script injected by the browser extension and redefine the network communication constructor as the proxy constructor; Step S20: Intercept the communication request initiated by the webpage for the local service through the proxy constructor, and pass the communication request to the isolated runtime environment where the second content script injected by the browser extension is located through the page message passing interface; Step S30: Using the second content script, the communication request is forwarded to the background service process of the browser extension via the extended messaging interface; Step S40: Through the background service process, establish a network connection with the local service based on the communication request to complete the data interaction between the webpage and the local service.

[0029] It should be noted that local services are service programs that run on the user's local computer, listen on local ports, and provide functions such as hardware access or local file processing.

[0030] The script execution environment of a webpage: the main environment in a browser used to execute the native JavaScript code of a webpage.

[0031] Browser extensions: Plugins installed in a browser that have higher privileges than web pages, allowing access to browser-specific APIs and the initiation of network requests that are not restricted by the same-origin policy.

[0032] First content script: A script injected into the main runtime environment of a webpage by a browser extension. It is used to directly intercept or modify the native code logic of the webpage.

[0033] Network communication constructor: The native API constructor used in web pages to initiate network requests, such as WebSocket, XMLHttpRequest, etc.

[0034] Proxy constructor: A redefined custom constructor used to replace the native constructor, which internally intercepts requests and changes their execution path.

[0035] Communication request: A network request command and data that a webpage attempts to exchange data with a local service.

[0036] Page message passing interface: An API (such as window.postMessage) used to pass messages between different JavaScript runtime environments (such as the main environment and the isolated environment) on the same page.

[0037] The second content script: A script injected into the isolated runtime environment by a browser extension, capable of simultaneously receiving page messages and calling extension-specific APIs.

[0038] Isolated runtime environment: The browser extension content script runs in a sandbox environment by default, which is isolated from the web page's JS environment, ensuring that the extension code is not maliciously tampered with by the web page.

[0039] Extended messaging interface: A dedicated API (such as chrome.runtime.sendMessage) used within browser extensions for communication between different components (such as content scripts and background service processes).

[0040] Background service process: The background running environment of the browser extension, with full extension permissions, not restricted by the web security sandbox, and can directly initiate local network connections.

[0041] Specifically, the browser extension injects the first content script into the main JS environment of the webpage. Through code rewriting, it replaces the webpage's native network communication constructor with a custom proxy constructor, allowing subsequent network requests from the webpage to be handled by the proxy. When the webpage calls the replaced constructor to initiate a request for a local service, the proxy constructor intercepts the request, preventing it from directly making a network call. Instead, it sends the request data across the environment boundary via the page's messaging interface to the second content script running in an isolated environment. The second content script, upon receiving the page message in the isolated environment, extracts the communication request data and uses the extension's internal messaging interface to forward the request across processes to the extension's background service process. Upon receiving the request data, the background service process, leveraging its high-privilege nature, directly acts as a client to establish a real network connection with the local service and perform data sending and receiving, ultimately achieving indirect communication between the webpage and the local service.

[0042] In this embodiment, by injecting dual content scripts through browser extensions and combining them with cross-environment messaging, the restricted network requests of the webpage are intercepted and forwarded to the extension background process with higher network privileges for execution. This bypasses the browser's security restrictions on webpages directly accessing local services, and achieves secure, stable, and transparent data interaction between the webpage and local services to the webpage's front-end code.

[0043] Based on any of the above embodiments, the step of running the first content script injected by the browser extension in the script execution environment of the webpage, and redefining the network communication constructor as the proxy constructor, includes: Before the page script of the webpage is executed, the first content script is run, and the reference of the global network communication constructor in the script runtime environment is set to the proxy constructor.

[0044] It should be noted that page scripts are native JavaScript code contained within or dynamically loaded by the webpage itself, used to implement the webpage's business logic and interactive functions.

[0045] Global network communication constructor: The native network communication API constructor that is mounted on the browser's global object (such as window), such as window.WebSocket or window.XMLHttpRequest, for page scripts to call directly to initiate network requests.

[0046] The term "reference pointing" refers to modifying the value of a variable or object property in programming languages ​​such as JavaScript to a reference to another function or object, so that when the variable name is called, the new function or object being pointed to is actually executed.

[0047] Specifically, by leveraging the browser's script injection mechanism, the first content script is ensured to run before the webpage's own page script begins parsing and execution, thus seizing the initiative in code execution. During the execution of the first content script, the global object in the script's runtime environment is accessed, the native global network communication constructor is located, and its property reference is modified to point to the custom proxy constructor, completing the replacement of the underlying API.

[0048] In this embodiment, by injecting and running the first content script before the execution of the webpage's own script, the reference to the global network communication constructor is replaced with the proxy constructor, ensuring that all subsequent network requests initiated by the webpage based on the global constructor can be intercepted and taken over without omission.

[0049] Based on any of the above embodiments, the step of intercepting the communication request initiated by the webpage for the local service through the proxy constructor and passing the communication request to the isolated runtime environment where the second content script injected by the browser extension resides through the page message passing interface includes: The proxy constructor captures the communication request initiated by the page script of the webpage and extracts the target connection parameters in the communication request; The proxy constructor generates a connection identifier for the communication connection, constructs a cross-context message object based on the target connection parameters and the connection identifier, and calls the page messaging interface to send the cross-context message object carrying the connection identifier to the second content script running in the isolated runtime environment.

[0050] It should be noted that the target connection parameters are the specific configuration information contained in the communication request used to establish a network connection, such as the target URL, port number, protocol type, request headers or request body data, etc.

[0051] Specifically, when a webpage's page script calls the replaced proxy constructor to initiate a communication request, the proxy constructor internally intercepts the call, preventing it from directly issuing a network request. It then parses and extracts the target connection parameters required to establish a connection from the request parameters. The proxy constructor generates a unique connection identifier for the current communication connection and encapsulates the extracted target connection parameters and the connection identifier together into a cross-context message object conforming to cross-environment transmission specifications. For example, it adds a message type identifier for the receiver to identify. Subsequently, it calls the page messaging interface to send this message object across the environment boundary from the webpage's main runtime environment to the isolated runtime environment where the second content script resides.

[0052] In this embodiment, the target connection parameters in the communication request are extracted by the proxy constructor, a connection identifier is generated for the communication connection, and it is then normalized and encapsulated into a cross-context message object carrying the connection identifier before being sent using the page message passing interface. This achieves secure transmission of network request data from the main webpage environment to the extended isolation environment, ensuring the complete extraction and accurate routing of key request information while adhering to the browser's cross-context communication security mechanism. This lays a reliable data foundation for the subsequent takeover by the extended background process and the establishment of a real local network connection.

[0053] Based on any of the above embodiments, the step of forwarding the communication request to the background service process of the browser extension via the second content script using the extended messaging interface includes: The cross-context message object is passed through via the second content script; The second content script calls the extended messaging interface to forward the cross-context message object carrying the connection identifier to the background service process.

[0054] It should be noted that the connection identifier is a unique string or number generated by the proxy constructor for each communication connection, used to distinguish different communication connections in asynchronous communication.

[0055] Mapping relationship: The correspondence between connection identifiers and communication instances created by the proxy constructor. The mapping relationship is used to accurately match the corresponding communication instance when a response is received.

[0056] Specifically, upon receiving a cross-context message object from the main webpage runtime environment, the second content script passes it through without generating a separate request identifier. Using the browser's extended messaging API, the second content script directly forwards the cross-context message object carrying the connection identifier to the background service process, where the actual request processing is handled. The connection identifier is generated by the proxy constructor when intercepting the communication request and written into the cross-context message object; the second content script only acts as a message relay.

[0057] In this embodiment, a connection identifier is generated for the communication connection by a proxy constructor and then passed through by the second content script. This enables message matching and status tracking between the web page environment and the extended background process based on the connection identifier, effectively avoiding response errors or loss when multiple connections are running concurrently.

[0058] Based on any of the above embodiments, the step of establishing a network connection with the local service through the background service process based on the communication request to complete the data interaction between the webpage and the local service includes: The background service process parses the communication request and initiates a connection request to the local service based on a preset network communication protocol; After establishing a connection with the local service, the request data corresponding to the communication request is sent to the local service; The system obtains the response data carrying the connection identifier returned by the local service, and returns the response data to the script execution environment of the webpage through the extended messaging interface and the page messaging interface, so that the proxy constructor can distribute the response data to the corresponding page script based on the connection identifier.

[0059] It should be noted that the preset network communication protocol is a pre-configured communication rule for data transmission between the background service process and the local service, such as TCP, WebSocket, or native messaging protocols.

[0060] Request data: The actual instructions, parameters, or payload contained in the communication request that need to be sent to the local service for processing.

[0061] Response data: The return result generated by the local service after processing the request data.

[0062] Specifically, the background service process parses the received communication request, extracts network information such as the target address, and initiates a network connection request to the local service according to a preset network communication protocol. After successfully establishing a network connection with the local service, the background service process sends the specific request data contained in the communication request to the local service for processing. The background service process receives the response data with a connection identifier returned by the local service and sequentially transmits it back to the web page environment through the extended messaging interface (backend to content script) and the page messaging interface (content script to web page). The proxy constructor distributes the response data to the corresponding page script that initially initiated the request based on the connection identifier and the pre-established mapping relationship.

[0063] In this embodiment, a background service process is used to proxy the webpage and establish a network connection with the local service and forward data, thereby overcoming the security limitations of the browser sandbox and enabling secure access to local resources by the webpage. At the same time, a complete data return method is constructed by combining connection identifiers and dual message passing interfaces, ensuring the connectivity of cross-environment data interaction and the accurate routing of response results in high-concurrency scenarios.

[0064] Based on any of the above embodiments, the background service process runs in a privileged execution context with local network access permissions; the network connection is a connection that is not restricted by the web security sandbox.

[0065] It should be noted that privileged execution context is a high-privilege runtime environment granted to background service processes in the browser extension architecture, allowing them to bypass the security restrictions of ordinary web pages, execute cross-domain requests, or access underlying system resources.

[0066] The background service process runs in a privileged execution context, which gives it direct access to the local network.

[0067] Web security sandbox restrictions refer to the isolation and execution environment mechanism provided by the browser for web page code, which strictly restricts the direct access of web pages to the local file system, local network (such as localhost, LAN IP) and cross-domain resources to ensure system security.

[0068] Local network access permissions: System-level permissions that allow programs to access network interfaces and resources of other devices on the local host or local area network.

[0069] In this embodiment, by placing the background service process in a privileged execution context and removing the restrictions on network connections imposed by the web security sandbox, the browser's native security policy's block on webpage access to the local network is broken, enabling the webpage to communicate with local services in compliance with regulations by leveraging the high privileges of the extended background.

[0070] Based on any of the above embodiments, the network communication constructor includes a network socket constructor or a Hypertext Transfer Protocol request constructor; the network connection includes a long connection or a short connection.

[0071] It should be noted that the network socket constructor is a constructor used to create full-duplex communication objects based on protocols such as WebSocket, which supports bidirectional real-time data transmission between the client and the server.

[0072] Hypertext Transfer Protocol Request Constructor: A constructor used to create request objects based on the HTTP / HTTPS protocol, such as XMLHttpRequest or the Fetch API, for standard client-server request and response interactions.

[0073] Persistent connections: Once a network connection is established, it remains open, allowing for multiple data exchanges over that connection. Persistent connections are suitable for communication scenarios with high frequency or real-time requirements.

[0074] Short connection: A connection is established before each data exchange and is immediately closed after the exchange is completed. This is suitable for communication scenarios with low frequency or single requests.

[0075] Specifically, the network connection between background service processes and local services includes long connections that maintain continuous communication and short connections that are established on demand and disconnected when not in use.

[0076] In its implementation, the core idea of ​​the local service communication method is to construct a client proxy for the local service within the main execution environment of the page through a browser extension. This transfers real network I / O to the privileged context of the Service Worker within the extension, bypassing browser security restrictions and achieving zero modification to business integration (i.e., the SDK still calls the original API) and zero rewriting of the local service protocol (i.e., request / response body is passed through). For ease of explanation, a WebSocket service is used as an example; see [link to documentation]. Figure 2 : The system consists of three parts: a web page layer, a browser extension component, and a local WebSocket service process. (1) Web page layer (100). Web applications running in the browser initiate local service call requests by creating WebSocket instances through the JavaScript interface, without needing to know the underlying communication details; (2) Browser Extension Bridge Layer (200). It consists of content scripts (210) and background service workers (220). The content scripts are injected through two types of scripts: one runs in the main runtime environment (MAIN world) to replace the WebSocket constructor; the other acts as a message relay between the WebSocket and Service Worker in the isolated world; the Service Worker is responsible for the actual WebSocket local service connection; (3) Local Service Layer (300 / 400). The WebSocket server (300) running locally receives requests from the extended Service Worker, calls the local target application (400), and returns the processing result.

[0077] It should be understood that the internal layering of browser extensions (such as the separation of content_scripts and Service Workers) was originally designed to address the security isolation issues within the extension itself. Content scripts run in a special privileged context: they can access web pages and communicate with other components of the extension via the Chrome messaging API. The local service communication method leverages this characteristic of content scripts, redefining the internal security isolation mechanism of the extension as a secure proxy architecture for web-native communication, thus endowing it with entirely new technical capabilities. See [link to relevant documentation]. Figure 3 .

[0078] In the main execution environment (Page_MAIN) of the business-side webpage, the extended content scripts (content_scripts(MAIN)) define the global WebSocket as the proxy constructor PatchedWebSocket before the service connection begins; The proxy object listens for local service call requests initiated by the page, sends them to the content scripts (content_scripts(isolated)) via postMessage, and then uses chrome.runtime.sendMessage to complete the message relay with the ServiceWorker; Service Worker establishes a real communication connection with the local service, making the browser unable to detect the service connecting to localhost.

[0079] The technical essence of the above-mentioned circumvention measures lies in the fact that the communication path is changed from Web page → local service (constrained by security policies) to Web page → proxy service request client postMessage → content script sendMessage → Service Worker → WebSocket → local service (using extended privileges) through architectural design, thus achieving compliant communication while fully complying with browser security policies.

[0080] Specifically: LNA policy circumvention: Because the browser extension's host_permissions declares access permissions for local network addresses, the local service connection initiated by the Service Worker runs in an extended security context independent of the web page, and its network requests are not restricted by the LNA policy for public web pages. Mixed content policy avoidance: The content script in the HTTPS page forwards the request to the Service Worker through the Chrome Message API. The Service Worker, which runs in the privileged context of the extension, establishes a local connection, avoiding the mixed content blocking triggered by WS or HTTP when the HTTPS page directly accesses it. Therefore, it is not subject to the constraints of the Web page mixed content policy. CORS policy avoidance: If the local service is HTTP, its connection is initiated by the Service Worker rather than the JavaScript of the web page, and therefore is not subject to the page's CORS policy. The web page only needs to communicate with the content script through window.postMessage. Because it is a standardized web API, it does not introduce cross-domain risks. Permissions declaration: Explicitly declare access permissions to the local WebSocket service address in the extension's manifest.json using host_permissions to ensure that the browser allows the extension to establish a connection.

[0081] The described local service communication method utilizes the independent, high-privilege execution environment of browser extensions. Through cross-context proxying of the WebSocket constructor, the web page script formally calls the standard WebSocket, but the extension actually establishes the local connection. Ultimately, this bypasses the browser's loopback restriction on direct page connections without modifying the original SDK or changing the local service protocol.

[0082] See Figure 4 The complete workflow of the local service communication method is divided into three stages: extension loading stage, initialization stage, and request stage. (1) During the browser extension loading phase, the extension injects the content script into the matching web page according to the manifest.json configuration, and starts the Service Worker at the same time; (2) During the initialization phase, the content script listens for and detects the creation of the WebSocket instance; the Service Worker establishes a real long connection with the local WebSocket service according to the page protocol, and initializes the message queue and event queue, etc. (3) After listening to the Web page request, the content script sends a message through window.postMessage and forwards it to the Service Worker through chrome.runtime.sendMessage; (4) After receiving the message, the Service Worker encapsulates the original JSON frame and sends it to the local service via WebSocket; (5) After the local service processes the request and returns a response, the Service Worker requests the execution callback; (6) The response result is sent back to the Web page via the content script.

[0083] Optionally, local services based on communication protocols such as TCP and HTTP are essentially the same in form as WebSocket, both being local services directly connected to the loopback layer by the page's JavaScript. They can all adopt the core idea of ​​the local service communication method, namely, using a browser extension as a secure proxy to securely forward web messages to the local service process. In practical applications, the proxy point can be selected based on the actual Web API used by the SDK, and is not limited to WebSocket.

[0084] One scenario in which the local service communication method can be implemented is as follows: In the field of secure identity authentication, security vendors provide local service relay solutions for B / S architecture business systems, which are used for services such as login authentication and data encryption / decryption based on USBKey.

[0085] In this scenario, assume the business integrates xtxasyn.js to implement a local WebSocket connection (wss: / / 127.0.0.1:21061 / xtxapp / ), calling dozens of interfaces such as SOF_*. With Chrome LNA tightening, when the browser detects local network access under public HTTPS mode, it will display a permission pop-up on the page. Once the user chooses to deny access, the browser will not prompt again, and the local service will remain unavailable. Given the limited scope of existing business systems and the difficulty in modifying them, the technical solution for upgrading the business application to the aforementioned local service communication method is as follows: Install and enable the browser extension; The integration on the page side remains unchanged, but the native WebSocket connection to 127.0.0.1 is switched to a proxy connection injected by extension. The actual local connection is transferred to the Service Worker, which declares allowed service connections using the host_permissions declaration in manifest.json, such as "ws: / / 127.0.0.1:21051 / *" or "wss: / / 127.0.0.1:21061 / *". The communication link becomes the primary runtime environment postMessage → extended isolated content script sendMessage → the actual WebSocket in Service Worker; No changes are needed for local services.

[0086] Since LNA and other policies do not apply to proxy connections, pop-ups no longer appear on the page, the service becomes available automatically, and users are unaware of it. Integration with existing business systems requires no modifications, achieving zero-intrusion compatibility; existing local services require no changes, resulting in no regression costs; expansion requires no additional business encapsulation, only channel switching.

[0087] In summary, the local service communication method provides a bridging and transformation solution for web local applications using local service relay. By constructing a service proxy, it transfers sensitive page direct connections to a high-privilege extended context, circumventing browser security policy restrictions. This results in zero changes to business integration, no modification to product protocols, and no user impact, while also allowing for engineered reuse of the extension. From the integration side, business integration requires zero modification, maintaining WebSocket semantics, long connections, and server-side event push mechanisms, consistent with the service provider's SDK. From the user side, the browser does not detect local direct connections, eliminating the need for authorization prompts and ensuring a seamless user experience. From the service provider side, the local service communication protocol requires no modification; only a lightweight implementation of the extension is needed to handle local service client proxying and message pass-through. This bridging transformation model can be applied to different communication protocols in different business scenarios, is engineered and reusable, and possesses significant versatility and standardization potential. Compared to Chrome's official enterprise policy pre-authorization LNA, this local service communication method eliminates the need for user authorization at each site, resulting in a productizable user experience. Compared to NativeMessaging, the local service communication method reuses existing communication protocols for local services, requires zero SDK modifications, no Host or related registration, and significantly reduces transformation costs.

[0088] In this embodiment, by being compatible with multiple network communication constructors and connection types, the system can flexibly adapt to appropriate communication modes according to the interface specifications of local services and the needs of business scenarios. For example, high-frequency real-time interaction uses WebSocket long connections, while low-frequency single calls use HTTP short connections. This improves the protocol compatibility, scenario adaptability, and transmission efficiency of data interaction between web pages and local services.

[0089] Based on the methods described in any of the above embodiments, this application also provides, as follows: Figure 5 The diagram shows the structure of an electronic device. Figure 5 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to implement the methods described in any of the above embodiments.

[0090] Based on the methods described in any of the above embodiments, this application also provides a computer storage medium storing a computer program, which, when executed by a processor, can be used to perform the methods described in any of the above embodiments.

[0091] Based on the methods described in any of the above embodiments, this application also provides a computer program product, which includes one or more computer programs or instructions. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. When executed by a processor, the computer program implements the methods described in any of the above embodiments.

[0092] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0093] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0094] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0095] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0096] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0097] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A local service communication method, characterized in that, The method includes: In the script execution environment of the webpage, the first content script injected by the browser extension is executed, and the network communication constructor is redefined as the proxy constructor. The proxy constructor intercepts the communication requests initiated by the webpage for local services, and passes the communication requests to the isolated runtime environment where the second content script injected by the browser extension is located through the page message passing interface; The second content script uses an extended messaging interface to forward the communication request to the background service process of the browser extension. The background service process establishes a network connection with the local service based on the communication request to complete the data interaction between the webpage and the local service.

2. The method according to claim 1, characterized in that, In the script execution environment of the webpage, the first content script injected by the browser extension is run, and the network communication constructor is redefined as the proxy constructor, including: Before the page script of the webpage is executed, the first content script is run, and the reference of the global network communication constructor in the script runtime environment is set to the proxy constructor.

3. The method according to claim 1, characterized in that, The step of intercepting communication requests initiated by the webpage for local services through the proxy constructor and passing the communication requests to the isolated runtime environment where the second content script injected by the browser extension resides through the page messaging interface includes: The proxy constructor captures the communication request initiated by the page script of the webpage and extracts the target connection parameters in the communication request; The proxy constructor generates a connection identifier for the communication connection, constructs a cross-context message object based on the target connection parameters and the connection identifier, and calls the page messaging interface to send the cross-context message object carrying the connection identifier to the second content script running in the isolated runtime environment.

4. The method according to claim 3, characterized in that, The step of forwarding the communication request to the background service process of the browser extension via the second content script using the extended messaging interface includes: The cross-context message object is passed through via the second content script; The second content script calls the extended messaging interface to forward the cross-context message object carrying the connection identifier to the background service process.

5. The method according to claim 4, characterized in that, The step of establishing a network connection with the local service based on the communication request through the background service process to complete the data interaction between the webpage and the local service includes: The background service process parses the communication request and initiates a connection request to the local service based on a preset network communication protocol; After establishing a connection with the local service, the request data corresponding to the communication request is sent to the local service; The system obtains the response data carrying the connection identifier returned by the local service, and returns the response data to the script execution environment of the webpage through the extended messaging interface and the page messaging interface, so that the proxy constructor can distribute the response data to the corresponding page script based on the connection identifier.

6. The method according to any one of claims 1-5, characterized in that, The background service process runs in a privileged execution context with local network access permissions; the network connection is not subject to the restrictions of the web security sandbox.

7. The method according to any one of claims 1-5, characterized in that, The network communication constructor includes a network socket constructor or a Hypertext Transfer Protocol request constructor; the network connection includes a long connection or a short connection.

8. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements the method described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the method described in any one of claims 1-7.

10. A computer program product, characterized 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-7.

Images