Cross-window data transmission method and device, equipment, storage medium and program product

Abstract

The invention discloses a cross-window data transmission method and device, equipment, a storage medium and a program product. The method comprises the steps that a ready signal of a child window is monitored, under the condition that the ready signal is received, whether a source for sending the ready signal belongs to a trusted source list of a parent window or not is verified, and the ready signal is a notification signal sent after loading of the child window is completed; if yes, a ready state notification is sent to the parent window, the ready state notification is used for triggering reissuing operation of a message cache queue of the parent window, the message cache queue is used for storing routing metadata to be sent, and the routing metadata is used for achieving interface data updating of the child window; under the condition that the routing metadata is received, verifying whether a source for sending the routing metadata belongs to a trusted source list of the child window or not; and if yes, sending the routing metadata to the child window.

Description

Technical Field

[0001] This application relates to the field of cross-window data interaction technology, and more specifically, to a cross-window data transfer method, apparatus, device, storage medium, and program product. Background Technology

[0002] In web development, the main page (parent window) typically needs to embed independent child pages (child windows) to achieve modular functional design. Cross-window data transfer is required between parent and child windows to ensure collaborative business operations between pages. For example, when an e-commerce platform's main page embeds a payment child page, core information such as order paths needs to be synchronized to the child page to complete business linkage.

[0003] In existing technologies, for this type of cross-window data transmission requirement, the browser's native Window.postMessage API is usually used directly. Specifically, the corresponding message sending and listening logic is deployed in the parent window and child window respectively. The parent window actively initiates data sending, and the child window completes data reception by listening to message events, thereby realizing bidirectional communication.

[0004] However, the existing implementation has obvious drawbacks: First, the page loading sequence of the parent window and the child window is inconsistent. If the parent window sends data before the child window is ready to load, the child window has not yet completed the message listening logic, which can easily cause message loss and core data cannot be effectively delivered. Second, the native communication method lacks an effective message source verification mechanism, which makes it easy to receive illegal and malicious cross-source messages, posing a security risk of data leakage. Summary of the Invention

[0005] The main purpose of this application is to provide a method, apparatus, device, storage medium and program product for cross-window data transmission, in order to solve the problems of message loss and cross-source security risks in existing cross-window communication, and to achieve reliable data transmission between parent and child windows and malicious message interception, thereby ensuring the stability and security of business collaboration.

[0006] To achieve the above objectives, a first aspect of this application proposes a cross-window data transmission method, comprising: listening to a ready signal of a child window, and upon receiving the ready signal, verifying whether the source sending the ready signal belongs to the trusted source list of the parent window, wherein the ready signal is a notification signal sent after the child window completes loading; if so, sending a ready status notification to the parent window, wherein the ready status notification is used to trigger a resend operation of the parent window's message cache queue, wherein the message cache queue is used to store routing metadata to be sent, and the routing metadata is used to update the interface data of the child window; upon receiving the routing metadata, verifying whether the source sending the routing metadata belongs to the trusted source list of the child window; if so, sending the routing metadata to the child window.

[0007] According to the cross-window data transfer method provided in this application, after sending a ready status notification to the parent window, the method further includes: receiving a routing metadata request sent by the child window, wherein the routing metadata request is a request initiated by the child window if it has not received the routing metadata within a preset time after sending the ready signal; and sending a data request notification to the parent window based on the routing metadata request, wherein the data request notification is used to trigger the parent window to return the routing metadata.

[0008] According to the cross-window data transmission method provided in this application, after sending the routing metadata to the child window, the method further includes: removing the signal listening task for the parent window and the child window.

[0009] According to the cross-window data transmission method provided in this application, before listening to the ready signal of the sub-window, the method further includes: determining a standard communication identifier corresponding to different communication scenarios, wherein the standard communication identifier includes the communication identifier carried by the ready status notification, the communication identifier carried by the data request notification, and the communication identifier carried by the token expiration notification, and the standard communication identifier is used to assist in identifying the communication scenario.

[0010] According to the cross-window data transmission method provided in this application, the method further includes: when a token expiration notification carrying a corresponding standard communication identifier is detected, verifying whether the source sending the token expiration notification belongs to the trusted source list of the parent window; if so, forwarding the token expiration notification to the child window, wherein the token expiration notification is used to trigger the identity status reset operation of the child window.

[0011] This application also provides a cross-window data transmission device, comprising the following modules: a processing module and a communication module; the processing module is configured to listen for the ready signal of a child window, and upon receiving the ready signal, verify whether the source of the ready signal belongs to the trusted source list of the parent window, wherein the ready signal is a notification signal sent after the child window has completed loading; the communication module is configured to, if so, send a ready status notification to the parent window, wherein the ready status notification is used to trigger a resend operation of the message cache queue of the parent window, wherein the message cache queue is used to store routing metadata to be sent, and the routing metadata is used to update the interface data of the child window; the processing module is configured to, upon receiving the routing metadata, verify whether the source of the routing metadata belongs to the trusted source list of the child window; the communication module is configured to, if so, send the routing metadata to the child window.

[0012] According to the cross-window data transmission device provided in this application, after sending a ready status notification to the parent window, the communication module is further configured to receive a routing metadata request sent by the child window. The routing metadata request is a request initiated by the child window if it has not received the routing metadata within a preset time after sending the ready signal. Based on the routing metadata request, a data request notification is sent to the parent window, which is used to trigger the parent window to return the routing metadata.

[0013] According to the cross-window data transmission device provided in this application, after the routing metadata is sent to the child window, the processing module is further configured to remove the signal listening task for the parent window and the child window.

[0014] According to the cross-window data transmission device provided in this application, before the ready signal of the listening sub-window is received, the processing module is further configured to determine the standard communication identifier corresponding to different communication scenarios. The standard communication identifier includes the communication identifier carried by the ready status notification, the communication identifier carried by the data request notification, and the communication identifier carried by the token expiration notification. The standard communication identifier is used to assist in identifying the communication scenario.

[0015] According to the cross-window data transmission device provided in this application, the processing module is further configured to verify whether the source sending the Token expiration notification belongs to the trusted source list of the parent window when the Token expiration notification carries the corresponding standard communication identifier; the communication module is further configured to forward the Token expiration notification to the child window if the Token expiration notification is found to be true, and the Token expiration notification is used to trigger the identity status reset operation of the child window.

[0016] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the cross-window data transfer method as described above.

[0017] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the cross-window data transfer method as described above.

[0018] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the cross-window data transfer method as described above.

[0019] The technical solutions provided by the embodiments of this application may include the following beneficial effects: Because the parent window only triggers the resending operation of the message cache queue after receiving the ready signal sent after the child window has finished loading and after verifying that the child window's source belongs to the parent window's trusted source list, and the message cache queue pre-stores the routing metadata to be sent, the message loss problem caused by the inconsistency of the loading sequence of the parent and child windows and the parent window sending data in advance can be avoided in the existing technology. This ensures that core data such as routing metadata can be effectively delivered to the child window, and ensures that the child window can successfully complete the interface data update. Furthermore, after receiving the routing metadata, it verifies whether the parent window that sent the data belongs to the trusted source list of the child window. The routing metadata is only sent to the child window after the verification is successful. Therefore, a two-way source verification mechanism is constructed, which fills the gap of the lack of effective message source verification in the native communication method. It can effectively intercept illegal and malicious cross-source messages and eliminate the security risks of data leakage from the root.

[0020] Thus, this application not only solves the reliability problem of cross-window data transmission, but also enhances the security of data transmission, ensuring the stable and secure operation of business collaboration between parent and child windows, and significantly improving the practicality and security of cross-window data interaction in web development. Attached Figure Description

[0021] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 One of the flowcharts illustrating the cross-window data transfer method provided in this application; Figure 2 The second flowchart illustrating the cross-window data transfer method provided in this application; Figure 3 This is a schematic diagram of the cross-window data transmission device provided by the present invention; Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] In this application, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing this application and its embodiments, and are not intended to limit the indicated device, element, or component to having a specific orientation, or to be constructed and operated in a specific orientation.

[0025] Furthermore, in addition to indicating location or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in this application based on the specific circumstances.

[0026] Furthermore, the terms "installation," "setup," "equipped with," "connection," "linked," and "socketing" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0027] This application describes some exemplary embodiments for illustrative purposes. It should be understood that this application may be implemented in other ways not specifically shown in the accompanying drawings.

[0028] In modular web development scenarios, such as an e-commerce platform's main page embedding a payment subpage or a backend management system's main interface embedding a data statistics subpage, where parent and child windows need to collaborate to complete business tasks, the parent window often needs to synchronize core information such as routing metadata to the child window to support the child window's interface rendering and function operation.

[0029] like Figure 1 and Figure 2 As shown, this application provides a cross-window data transfer method, which can be applied to a cross-window data transfer device, which includes at least the postMessage tool. The cross-window data transfer method may include steps S101-S104: S101. The cross-window data transmission device listens to the ready signal of the child window, and upon receiving the ready signal, verifies whether the source sending the ready signal belongs to the trusted source list of the parent window.

[0030] The aforementioned ready signal is a notification signal sent after the sub-window has finished loading.

[0031] In actual webpage loading, the loading sequence of the parent and child windows can easily become inconsistent. The child window can only receive data sent by the parent window after all page resources have been loaded and message listening logic has been deployed. Therefore, the cross-window data transmission device can continuously monitor the ready signal sent by the child window through a Map storage listener. This ready signal is the status notification actively sent by the child window after loading. At the same time, in order to prevent illegal and malicious child windows from sending false signals to trick the parent window into sending data, the cross-window data transmission device will immediately verify whether the child window that sent the ready signal is in the parent window's pre-configured trusted source list after receiving the ready signal. For example, it will check whether the domain name of the child window is consistent with the registered domain name in the trusted list, thereby avoiding interference from invalid and malicious signals from the source.

[0032] S102. If so, the cross-window data transfer device sends a ready status notification to the parent window.

[0033] The ready status notification is used to trigger the resending operation of the parent window message cache queue. The message cache queue is used to store routing metadata to be sent. The routing metadata is used to update the interface data of the child window.

[0034] Once the cross-window data transmission device verifies the legitimacy of the child window's origin, it can send a ready status notification to the parent window. The parent window has previously stored the routing metadata to be sent to the child window in a message cache queue. This message cache queue stores core data awaiting transmission to the child window. When the parent window receives the ready status notification from the device, it triggers a resend operation in this cache queue. This completely resolves the message loss issue caused by the parent window prematurely sending data before the child window is ready.

[0035] For example, the parent window pre-stores the order routing information required by the payment sub-page. Before receiving the ready notification, this information will be securely stored in the cache queue and will not be lost because the sub-window is not loaded. This ensures that the routing metadata can be accurately delivered after the sub-window is ready, providing support for the update of the sub-window's interface data.

[0036] S103. Upon receiving the routing metadata, the cross-window data transmission device verifies whether the source sending the routing metadata belongs to the trusted source list of the sub-window.

[0037] When the cross-window data transmission device obtains the routing metadata from the parent window's message cache queue, it does not send it directly to the child window. This is because in cross-window communication scenarios, there is not only the threat of unauthorized child windows, but also the risk of unauthorized parent windows sending false or malicious data to child windows. For example, a malicious page disguised as a legitimate parent window might send incorrect routing information to the child window, inducing the user to enter a phishing interface. Therefore, after receiving the routing metadata, the device will further verify whether the parent window that sent the routing metadata is in the child window's preset trusted source list. By constructing a reverse verification mechanism, a two-way source verification closed loop can be formed, making up for the lack of effective source verification in the native postMessage communication method.

[0038] S104. If so, the cross-window data transmission device sends the routing metadata to the child window.

[0039] Once the cross-window data transmission device confirms that the parent window sending the routing metadata is legitimate, it will send the routing metadata to the corresponding child window. After receiving this data, the child window can update its own interface data based on this routing metadata. For example, after the payment subpage receives the order routing information, it will automatically render the corresponding order payment interface.

[0040] In this embodiment, by listening to the ready signal sent after the child window completes loading, and only triggering the resending operation of the parent window's message cache queue after receiving the ready signal and verifying that the child window's source belongs to the parent window's trusted source list, and since the message cache queue pre-stores the routing metadata to be sent, the message loss problem caused by inconsistent loading times of parent and child windows and premature data sending by the parent window in the prior art can be avoided. This ensures that core data such as routing metadata can be effectively delivered to the child window, guaranteeing that the child window can successfully complete the interface data update. Furthermore, because after receiving the routing metadata, it verifies whether the parent window that sent the data belongs to the child window's trusted source list, and only sends the routing metadata to the child window after successful verification, a two-way source verification mechanism is constructed. This fills the gap in the lack of effective message source verification in the native communication method, effectively intercepting illegal and malicious cross-source messages and eliminating the security risk of data leakage from the root. Thus, this application not only solves the reliability problem of cross-window data transmission but also strengthens the security of data transmission, ensuring the stable and secure operation of business collaboration between parent and child windows, and significantly improving the practicality and security of cross-window data interaction in web development.

[0041] Optionally, after sending a ready status notification to the parent window, the cross-window data transfer device can also receive a routing metadata request sent by the child window. The routing metadata request is a request initiated by the child window if it has not received the routing metadata within a preset time after sending the ready signal. Based on the routing metadata request, a data request notification is sent to the parent window, which is used to trigger the parent window to return the routing metadata.

[0042] Specifically, in actual cross-window data transmission scenarios, even if the parent window's message cache queue is resent via a ready signal, unexpected events such as network latency or cache queue data anomalies may still cause the child window to fail to receive routing metadata in a timely manner after sending the ready signal. For example, the payment child window of an e-commerce platform may have finished loading and sent a ready signal, but due to a temporary data reading delay in the parent window's cache queue, the child window may not receive the order routing information for a long time.

[0043] To address the aforementioned issues, this application adds a backup process of "child window proactive inquiry" in addition to the main process of "parent window reissue." Specifically, this means that... Figure 2As shown, after sending a ready signal, the child window starts a timer of preset duration, continuously listening for whether it has received the routing metadata resent by the parent window during this period. If it still hasn't received it after the timer expires, it indicates that there may be an anomaly in the main process, and the child window will proactively send a routing metadata request to the cross-window data transmission device, explicitly informing the device of its receiving status. After receiving the routing metadata request, the cross-window data transmission device will first verify that the initiator of the request is a legitimate child window that has been verified by the parent window's trusted source to prevent unauthorized windows from interfering with communication through the request mechanism. Then, based on the request, it will send a data request notification to the parent window. After receiving the notification, the parent window will retrieve the corresponding routing metadata from the message cache queue again, or obtain the latest routing metadata in real time, ensuring that the sent data is timely.

[0044] The above solution addresses the limitations of a single retransmission mechanism. Even if data transmission fails due to network or caching issues in the main process, data retransmission can be achieved through the active request of the child window. Furthermore, this mechanism requires no manual intervention and is completed automatically by the device and parent-child windows. This ensures the reliability of data transmission without increasing development and usage costs, further enhancing the stability and user experience of cross-window data interaction, and enabling smooth business collaboration between parent and child windows even in complex environments.

[0045] Optionally, after sending the routing metadata to the child window, the cross-window data transfer device may also remove the signal listening task for the parent window and the child window.

[0046] Specifically, after the cross-window data transfer is completed, the child window has completed the interface update based on the routing metadata, and the core business collaboration requirements of the parent and child windows have been met. At this point, there is no need to maintain signal monitoring for both parties. If the monitoring task is retained, it will lead to continuous occupation of system resources, and long-term operation may cause memory leaks and affect the overall performance of the webpage.

[0047] To avoid system burden caused by invalid listening, the cross-window data transmission device can proactively trigger the listening removal process after confirming that the routing metadata has been successfully sent to the child window and no subsequent communication requests have been received from either party. On the one hand, it stops listening to the relevant signals of the parent window and no longer responds to events such as cache queue resending feedback and data update notifications from the parent window; on the other hand, it terminates listening to the child window's ready signals, routing metadata requests, and other signals, and no longer receives subsequent communication instructions from the child window.

[0048] For example, once the order sub-window of an e-commerce platform successfully receives and renders the order routing metadata from the parent window, all listening tasks for that parent-child window combination can be automatically removed, freeing up process resources and memory space originally used for listening.

[0049] The above solution can optimize system performance, reduce unnecessary resource consumption, and make web pages run more smoothly, especially in scenarios where multiple child windows are embedded in the main window, thus avoiding lag caused by the accumulation of listening tasks. On the other hand, it can reduce the risk of communication interference, as other irrelevant signals will no longer be captured and processed by the device, further ensuring the security and stability of cross-window communication.

[0050] Optionally, before the ready signal of the listening sub-window, the cross-window data transmission device can also determine the standard communication identifier corresponding to different communication scenarios. The standard communication identifier includes the communication identifier carried by the ready status notification, the communication identifier carried by the data request notification, and the communication identifier carried by the token expiration notification. The standard communication identifier is used to assist in identifying the communication scenario.

[0051] Specifically, in cross-window communication scenarios, there may be various communication needs between parent and child windows, such as the child window informing the parent window that it is "ready", the child window requesting routing metadata, and the parent window notifying the child window that the "Token has expired". Different communication needs correspond to different business logic. Before the cross-window data transmission device starts listening for the ready signal of the child window, a standard communication identifier can be predefined.

[0052] By assigning unique standard communication identifiers to different communication scenarios, the standardization of communication identifiers across different scenarios can be achieved, enabling cross-window data transmission devices to quickly identify the core intent of communication messages. In specific processing, cross-window data transmission devices can define standard identifiers corresponding to various types of communication based on actual business scenarios. For example, the communication identifier corresponding to a ready status notification can be set to "IFRAME_READY"; the communication identifier corresponding to a data request notification can be set to "FETCH_PARENT_ROUTE_META"; and the communication identifier corresponding to a token expiration notification can be set to "TOKEN_LOSE_EFFICACY".

[0053] Through the above solution, on the one hand, standard communication identifiers allow devices to accurately distinguish different communication scenarios, avoiding processing logic errors caused by message type confusion and improving the accuracy of cross-window communication; on the other hand, unified identifier specifications allow developers to avoid redesigning message recognition logic when connecting different sub-windows or expanding new communication scenarios, simply by using the already defined standard identifiers or adding corresponding identifiers, reducing development redundancy and maintenance costs; at the same time, standardized identifiers also provide a basis for subsequent message filtering, allowing devices to receive only messages carrying standard communication identifiers and directly block invalid messages without identifiers or with illegal identifiers, further enhancing the security and efficiency of communication.

[0054] Optionally, the cross-window data transmission device can also verify whether the source of the token invalidation notification belongs to the trusted source list of the parent window when it detects that the token invalidation notification carries the corresponding standard communication identifier; if so, the token invalidation notification is forwarded to the child window, and the token invalidation notification is used to trigger the identity status reset operation of the child window.

[0055] Specifically, in cross-window application scenarios such as micro-frontends and multi-module nesting, user authentication relies on tokens (login credentials) for maintenance. However, tokens have an expiration date. When the parent window detects that a token has expired or become invalid, if it cannot be synchronized to all child windows in a timely manner, the child windows will still use the invalid token to perform business operations, causing problems such as data request failures and permission verification anomalies.

[0056] To avoid the aforementioned problems, this application can rely on a predefined standard communication identifier for token expiration notifications to achieve accurate identification and secure synchronization of expiration status, preventing maliciously forged expiration notifications from interfering with business operations. In the specific processing, the cross-window data transmission device continuously monitors all messages carrying the standard communication identifier. When a message with the identifier corresponding to a token expiration notification is detected, a source verification process is first initiated to check whether the entity sending the notification belongs to the parent window's pre-set trusted source list. For example, it verifies whether the sender's domain name and application identifier are consistent with the parent window's registration information. This is because malicious third parties may forge token expiration notifications, attempting to induce child windows to perform identity reset operations, thereby stealing user information or interfering with business processes. Only notifications that pass source verification are considered legitimate and valid expiration notifications.

[0057] The above solution achieves several advantages. First, by quickly identifying token expiration notifications using standard communication identifiers, confusion with other communication messages can be avoided, ensuring accurate state synchronization. Second, the upfront trusted source verification process effectively intercepts maliciously forged expiration notifications, preventing child windows from being illegally induced to perform identity resets, thus protecting user information security and business stability. Third, it achieves real-time synchronization of parent and child window identity states, avoiding business errors and data anomalies caused by token expiration and asynchrony, improving user experience. Furthermore, since this mechanism requires no manual intervention, with the entire process of listening, verifying, and forwarding completed automatically by the device, development and maintenance costs are reduced, making cross-window application identity management more efficient and reliable.

[0058] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0059] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0060] The cross-window data transfer method provided in this application can be executed by a cross-window data transfer device or a control module within that device. This application uses the execution of the cross-window data transfer method by a cross-window data transfer device as an example to illustrate the cross-window data transfer device provided in this application.

[0061] It should be noted that the embodiments of this application can divide the cross-window data transmission device into functional modules based on the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. Optionally, the module division in the embodiments of this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0062] like Figure 3As shown in the figure, this application embodiment provides a cross-window data transmission device 300. The cross-window data transmission device 300 includes: a processing module 301 and a communication module 302; the processing module 301 is used to listen to the ready signal of a child window, and upon receiving the ready signal, verify whether the source sending the ready signal belongs to the trusted source list of the parent window, wherein the ready signal is a notification signal sent after the child window completes loading; the communication module 302 is used to, if yes, send a ready status notification to the parent window, wherein the ready status notification is used to trigger a resend operation of the parent window's message cache queue, wherein the message cache queue is used to store routing metadata to be sent, and the routing metadata is used to update the interface data of the child window; the processing module 301 is used to, upon receiving the routing metadata, verify whether the source sending the routing metadata belongs to the trusted source list of the child window; the communication module 302 is used to, if yes, send the routing metadata to the child window.

[0063] Optionally, after sending the ready status notification to the parent window, the communication module 302 is further configured to receive a routing metadata request sent by the child window, wherein the routing metadata request is a request initiated by the child window if it has not received the routing metadata within a preset time after sending the ready signal; and based on the routing metadata request, send a data request notification to the parent window, wherein the data request notification is used to trigger the parent window to return the routing metadata.

[0064] Optionally, after sending the routing metadata to the child window, the processing module 301 is further configured to remove the signal listening task for the parent window and the child window.

[0065] Optionally, before the ready signal of the listening sub-window, the processing module 301 is further configured to determine the standard communication identifier corresponding to different communication scenarios. The standard communication identifier includes the communication identifier carried by the ready status notification, the communication identifier carried by the data request notification, and the communication identifier carried by the token expiration notification. The standard communication identifier is used to assist in identifying the communication scenario.

[0066] Optionally, the processing module 301 is further configured to verify whether the source sending the Token expiration notification belongs to the trusted source list of the parent window when the Token expiration notification carries the corresponding standard communication identifier; the communication module 302 is further configured to forward the Token expiration notification to the child window if the Token expiration notification is yes, and the Token expiration notification is used to trigger the identity status reset operation of the child window.

[0067] In this embodiment, by listening to the ready signal sent after the child window completes loading, and only triggering the resending operation of the parent window's message cache queue after receiving the ready signal and verifying that the child window's source belongs to the parent window's trusted source list, and since the message cache queue pre-stores the routing metadata to be sent, the message loss problem caused by inconsistent loading times of parent and child windows and premature data sending by the parent window in the prior art can be avoided. This ensures that core data such as routing metadata can be effectively delivered to the child window, guaranteeing that the child window can successfully complete the interface data update. Furthermore, because after receiving the routing metadata, it verifies whether the parent window that sent the data belongs to the child window's trusted source list, and only sends the routing metadata to the child window after successful verification, a two-way source verification mechanism is constructed. This fills the gap in the lack of effective message source verification in the native communication method, effectively intercepting illegal and malicious cross-source messages and eliminating the security risk of data leakage from the root. Thus, this application not only solves the reliability problem of cross-window data transmission but also strengthens the security of data transmission, ensuring the stable and secure operation of business collaboration between parent and child windows, and significantly improving the practicality and security of cross-window data interaction in web development.

[0068] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440, wherein the processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a cross-window data transfer method. This method includes: listening to the ready signal of a child window; and, upon receiving the ready signal, verifying whether the source sending the ready signal belongs to the trusted source list of the parent window, wherein the ready signal is a notification signal sent after the child window completes loading; if so, sending a ready status notification to the parent window, wherein the ready status notification is used to trigger a resend operation of the parent window's message cache queue, wherein the message cache queue is used to store routing metadata to be sent, and the routing metadata is used to update the interface data of the child window; and, upon receiving the routing metadata, verifying whether the source sending the routing metadata belongs to the trusted source list of the child window; if so, sending the routing metadata to the child window.

[0069] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part 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 the present invention. 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.

[0070] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the cross-window data transfer method provided by the above methods. The method includes: listening to the ready signal of a child window, and upon receiving the ready signal, verifying whether the source of the ready signal belongs to the trusted source list of the parent window, wherein the ready signal is a notification signal sent after the child window has completed loading; if so, sending a ready status notification to the parent window, wherein the ready status notification is used to trigger a resend operation of the message cache queue of the parent window, wherein the message cache queue is used to store routing metadata to be sent, and the routing metadata is used to update the interface data of the child window; upon receiving the routing metadata, verifying whether the source of the routing metadata belongs to the trusted source list of the child window; if so, sending the routing metadata to the child window.

[0071] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the cross-window data transfer method provided by the above methods. The method includes: listening to a ready signal of a child window; and, upon receiving the ready signal, verifying whether the source sending the ready signal belongs to the trusted source list of the parent window, wherein the ready signal is a notification signal sent after the child window has completed loading; if so, sending a ready status notification to the parent window, wherein the ready status notification is used to trigger a resend operation of the parent window's message cache queue, wherein the message cache queue is used to store routing metadata to be sent, and the routing metadata is used to update the interface data of the child window; and, upon receiving the routing metadata, verifying whether the source sending the routing metadata belongs to the trusted source list of the child window; if so, sending the routing metadata to the child window.

[0072] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0073] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0074] The above description is merely a preferred embodiment of this application and is not intended to limit 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 protection scope of this application.

Claims

1. A method for cross-window data transfer, characterized in that, include: Listen for the ready signal of the child window, and if the ready signal is received, verify whether the source of the ready signal belongs to the trusted source list of the parent window. The ready signal is a notification signal sent after the child window has finished loading. If so, a ready status notification is sent to the parent window. The ready status notification is used to trigger the resending operation of the parent window's message cache queue. The message cache queue is used to store the routing metadata to be sent. The routing metadata is used to update the interface data of the child window. Upon receiving the routing metadata, verify whether the source sending the routing metadata belongs to the trusted source list of the sub-window; If so, the routing metadata is sent to the sub-window.

2. The cross-window data transfer method according to claim 1, characterized in that, After sending the ready status notification to the parent window, the method further includes: Receive the routing metadata request sent by the child window, wherein the routing metadata request is a request initiated by the child window if it has not received the routing metadata within a preset time after sending the ready signal; Based on the route metadata request, a data request notification is sent to the parent window, which triggers the parent window to return the route metadata.

3. The cross-window data transfer method according to claim 1, characterized in that, After sending the routing metadata to the sub-window, the method further includes: Remove the signal listening task for the parent window and the child window.

4. The cross-window data transfer method according to claim 1, characterized in that, Before the ready signal of the listening sub-window is received, the method further includes: Determine standard communication identifiers corresponding to different communication scenarios. The standard communication identifiers include the communication identifiers carried by the ready status notification, the data request notification, and the token expiration notification. The standard communication identifiers are used to assist in identifying communication scenarios.

5. The cross-window data transfer method according to claim 4, characterized in that, The method further includes: When a token expiration notification carrying the corresponding standard communication identifier is detected, verify whether the source sending the token expiration notification belongs to the trusted source list of the parent window; If so, the Token expiration notification is forwarded to the child window, and the Token expiration notification is used to trigger the identity status reset operation of the child window.

6. A cross-window data transfer device, characterized in that, include: Processing module and communication module; The processing module is used to listen to the ready signal of the child window, and when the ready signal is received, to verify whether the source of the ready signal belongs to the trusted source list of the parent window. The ready signal is a notification signal sent after the child window has finished loading. The communication module is used to send a ready status notification to the parent window if the condition is met. The ready status notification is used to trigger a resend operation of the parent window's message cache queue. The message cache queue is used to store routing metadata to be sent. The routing metadata is used to update the interface data of the child window. The processing module is used to verify, upon receiving the routing metadata, whether the source sending the routing metadata belongs to the trusted source list of the sub-window. The communication module is used to send the routing metadata to the sub-window if the condition is met.

7. The cross-window data transmission device according to claim 6, characterized in that, After sending the ready status notification to the parent window, the communication module is further configured to receive a routing metadata request sent by the child window. The routing metadata request is a request initiated by the child window if it has not received the routing metadata within a preset time after sending the ready signal. Based on the route metadata request, a data request notification is sent to the parent window, which triggers the parent window to return the route metadata.

8. An electronic 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 cross-window data transfer method as described in any one of claims 1 to 5.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the cross-window data transfer method as described in any one of claims 1 to 5.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the cross-window data transfer method as described in any one of claims 1 to 5.

Images