Method and device for data communication between homologous tabs in different browser pages

Abstract

The application provides a data communication method and device between homologous and different tab pages in the same browser, comprising the following steps: in the homologous and same browser environment, a sender tab page varies a preset key in a key pool based on a page identifier of the sender to obtain a varied key; an API of a browser shared storage object is called, and target data to be transmitted is encrypted and stored in a preset key name of the shared storage object through the varied key; a receiver tab page detects changes of the target data in the preset key name in the shared storage object through a registered storage event listener; when the target data changes, the storage event is triggered, and an event callback function of the receiver tab page is executed to obtain the changed target data, and the changed target data is decrypted to perform a predefined operation. In the application, the defect that real-time and safe communication cannot be directly performed between different tab pages is overcome.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and apparatus for data communication between different tab pages of the same source and browser. Background Technology

[0002] When performing multiple webpage operations on a PC within the same browser and origin, there is a type of shopping operation where you need to navigate from the order list page to the details page to confirm receipt or cancel the order. If you open a new page within the same browser and then return to the list page after completing the operation, it will reduce efficiency. On the other hand, if you open a new page within a new browser and then complete the operation, you cannot guarantee that the data between the two pages will be synchronized in a timely manner.

[0003] In modern web applications, communication between different tabs within the same origin has always been a challenging problem. Traditional communication methods are limited by browser security restrictions, preventing direct real-time communication between different tabs. Therefore, a new method is needed to achieve efficient and secure communication between tabs within the same domain and browser, providing a better user experience and functional scalability. Summary of the Invention

[0004] The main objective of this invention is to provide a data communication method and apparatus between different tab pages of the same source and browser, aiming to overcome the current deficiency that it is impossible to directly perform real-time secure communication between different tab pages.

[0005] To achieve the above objectives, the present invention provides a data communication method between different tab pages of the same origin and browser, comprising the following steps:

[0006] In a same-origin, same-browser environment, the sending tab page mutates the preset key in the key pool based on the sending page identifier to obtain the mutated key;

[0007] Call the browser's shared storage object API to encrypt the target data to be transmitted and store it under the preset key name of the shared storage object using a mutation key;

[0008] The receiving tab page detects changes to the target data under the preset key name within the shared storage object through a registered storage event listener;

[0009] When the target data changes, the storage event is detected and the event callback function of the receiving tab is executed to obtain the changed target data and decrypt the changed target data to perform a predefined operation.

[0010] Furthermore, the browser shared storage object is localStorage or sessionStorage, and the API is localStorage.setItem() or sessionStorage.setItem().

[0011] Furthermore, the preset key name is a specific key value predetermined for the sender's tab page and the receiver's tab page, used to limit the detection range of the storage event listener and eliminate interference from changes in non-target data in the shared storage object.

[0012] Furthermore, the event callback function is also used for:

[0013] When the target data after the change is detected to be empty, the predefined operation is prohibited.

[0014] Furthermore, after storing the target data via the API, the sender's tag page is also used for:

[0015] Upon receiving a clear operation command, exiting the browser, or at preset intervals, the shared storage object is cleared; the clear operation is performed by calling the window.localStorage.clear() or window.sessionStorage.clear() function.

[0016] Furthermore, the predefined operations include data display updates, data preloading, or state synchronization;

[0017] The data display update refers to the recipient's tab page refreshing the page content in real time based on the changed target data; the data preloading refers to the recipient's tab page preloading related resources based on the changed target data; and the status synchronization refers to the recipient's tab page synchronizing the operation status of the sender's tab page based on the changed target data.

[0018] Furthermore, based on the sender's page identifier, the preset key in the key pool is mutated to obtain the mutated key, including:

[0019] The sender's tag page extracts the domain level information of the current page and the page identifier generated during page rendering, and generates the page identifier as a key mutation factor;

[0020] Based on domain name level information, the corresponding preset key is selected from the key pool; the key pool stores multiple preset keys, each of which has a different type and corresponds to different domain name level information.

[0021] The selected preset key is mutated based on the key mutation factor to obtain the mutated key.

[0022] Furthermore, when storing the target data to be transmitted in a shared storage object using a mutation key and encrypting it under a preset key name, it also includes:

[0023] Domain hierarchical information and page identifiers are concatenated into key metadata, which is then stored along with the encrypted target data in the value corresponding to the preset key name of the shared storage object.

[0024] Further, the selected preset key is mutated based on the key mutation factor to obtain the mutated key, including:

[0025] The selected preset key is divided into a first key segment and a second key segment. The key mutation factor and the first key segment are subjected to a bit-by-bit weighted operation to obtain the first mutation segment. The weights in the bit-by-bit weighted operation are jointly determined by the key mutation factor and the character types of the corresponding bits of the first key segment.

[0026] Perform a bitwise XOR operation between the key mutation factor and the second key segment to obtain the second mutation segment;

[0027] Generate a mutation key based on the first mutation segment and the second mutation segment.

[0028] The present invention also provides a data communication device between different tab pages of the same origin and browser, comprising:

[0029] The mutation unit is used to mutate the preset key in the key pool based on the sender's page identifier in the same origin and same browser environment to obtain the mutated key.

[0030] The storage unit is used to call the browser's shared storage object API to encrypt and store the target data to be transmitted under the preset key name of the shared storage object using a mutation key.

[0031] The listening unit is used by the receiving tab page to detect changes in the target data under the preset key name in the shared storage object through the registered storage event listener;

[0032] The execution unit is used to listen for the storage event when the target data changes, execute the event callback function of the receiving tab page to obtain the changed target data, and decrypt the changed target data to perform predefined operations.

[0033] The present invention provides a data communication method and apparatus between different tab pages of the same origin and browser, comprising: in a same origin and browser environment, the sending tab page mutates a preset key in a key pool based on the sending page identifier to obtain a mutated key; calling the API of the browser's shared storage object to encrypt and store the target data to be transmitted under a preset key name in the shared storage object using the mutated key; the receiving tab page detects changes to the target data under the preset key name in the shared storage object through a registered storage event listener; when the target data changes, the storage event is triggered, the event callback function of the receiving tab page is executed to obtain the changed target data, and the changed target data is decrypted to perform a predefined operation. This invention overcomes the current limitation of not being able to directly perform real-time secure communication between different tab pages. Attached Figure Description

[0034] Figure 1 This is a schematic diagram illustrating the steps of a data communication method between different tab pages from the same source and browser in one embodiment of the present invention;

[0035] Figure 2 This is a structural block diagram of a data communication device between different tab pages of the same source and browser in one embodiment of the present invention;

[0036] Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0037] The implementation, functional features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0039] It is particularly important to note that all technical steps, algorithm applications, and parameter settings in the technical solution of this application have clear technical objectives and application value. They do not utilize complex steps and algorithmic formulas to achieve simple functions. To provide detailed explanations of each step and avoid ambiguity, some conventional algorithms are used for illustration. However, this does not mean that the algorithms and technical features listed herein are the only way to implement the technical solution of this application, nor is it intended to limit the scope of protection of this application. This application is not a combination or stacking of the listed algorithms and technical features; its essence is to exemplify the implementation methods of this application to fully explain it. It does not pursue formal complexity by adding meaningless technical steps, nor does it involve the accumulation of technologies divorced from practical needs; it conforms to the conventional logic of technical improvement and design.

[0040] Reference Figure 1 One embodiment of the present invention provides a data communication method between different tab pages of the same origin and browser, comprising the following steps:

[0041] Step S1: In a same-origin, same-browser environment, the sender's tab page mutates the preset key in the key pool based on the sender's page identifier to obtain the mutated key;

[0042] Step S2: Call the browser's shared storage object API to encrypt the target data to be transmitted and store it under the preset key name of the shared storage object using a mutation key;

[0043] Step S3: The receiving tab page detects changes in the target data under the preset key name within the shared storage object through the registered storage event listener;

[0044] Step S4: When the target data changes, the storage event is detected and the event callback function of the receiving tab page is executed to obtain the changed target data and decrypt the changed target data to perform a predefined operation.

[0045] In this embodiment, as described in step S1 above, a customized key is used to enhance the uniqueness and security of the target data encryption, preventing the leakage of all data due to the cracking of a single key. The specific operation logic is as follows:

[0046] In a same-origin, same-browser environment (i.e., all tabs have the same protocol, domain name, and port, ensuring that the browser allows cross-tab access to shared storage resources), the sending tab first obtains its own page identifier, which is a unique string generated during page rendering initialization. This ensures that the identifiers of different tabs within the same browser are not duplicated, and can uniquely distinguish the sending source.

[0047] Next, the sender retrieves the corresponding preset key from a locally stored key pool. The key pool is usually stored in the browser's IndexedDB or localStorage and contains multiple sets of symmetric preset keys generated based on Chinese cryptographic algorithms (such as SM4) or internationally recognized algorithms (such as AES). Each set of preset keys is associated with a specific domain level (e.g., key group A corresponds to the second-level domain example.com, and key group B corresponds to the third-level domain app.example.com). The sender determines the domain level by parsing the current page's window.location.hostname, and then accurately selects the appropriate preset key to avoid misuse of keys across different levels.

[0048] Finally, the sender uses the page identifier as the core key mutation factor to perform a mutation operation on the selected preset key, generating a mutated key that is only bound to the current sender's tag page. This key combines the basic security of the preset key with the uniqueness of the page identifier, providing customized security for subsequent data encryption.

[0049] As described in step S2 above, relying on the browser's shared storage capability, the encrypted target data can be accessed and stored across different tabs. At the same time, the data access scope is limited by preset key names. The specific operation logic is as follows:

[0050] The sender's label page first encrypts the target data to be transmitted. The target data includes business data (such as form content, transaction information, and page status parameters) and auxiliary data (such as data generation timestamps and data version numbers). The sender uses the mutation key generated in step S1 to fully encrypt the target data using a symmetric encryption algorithm (such as SM4-CBC mode), generating binary encrypted data. At the same time, the sender calculates the SHA-256 hash value of the encrypted data for the receiver to subsequently verify data integrity.

[0051] Subsequently, the sender calls the browser's native API for shared storage objects, which can be either localStorage or sessionStorage (localStorage data is permanently stored in the browser and is suitable for long-term data sharing; sessionStorage data is only stored in the current browser session and is suitable for temporary data synchronization). If localStorage is selected, the localStorage.setItem(key, value) API is called; if sessionStorage is selected, the sessionStorage.setItem(key, value) API is called.

[0052] In this API, the key name is a pre-agreed key name (e.g., crossTabData_2025) between the sender and receiver. This key name has unique identification and is used only for data storage in this communication scheme, avoiding conflicts with storage key names of other services within the browser. In one embodiment, the value of the API is a concatenated string of encrypted data and a hash value, ensuring that the stored data contains both core business information and has a basis for integrity verification. After calling the API, the target data is stored in encrypted form under the entry corresponding to the pre-agreed key name of the shared storage object, achieving secure storage that can be read across tags.

[0053] As described in step S3 above, a real-time sensing mechanism for changes in shared storage data is established to ensure that updated target data can be captured promptly. The specific operation logic is as follows:

[0054] After initialization, the receiving tab immediately registers a storage event listener with the browser, which can be achieved using the `window.addEventListener(storage, callback)` function. Here, `storage` is a native browser event type that is triggered when a tab within the same browser performs `setItem`, `removeItem`, or `clear` operations on `localStorage` or `sessionStorage`. The listener's callback function is a custom event handler function defined by the receiving tab, used for subsequent data parsing and processing.

[0055] To prevent the listener from detecting irrelevant data changes (such as other services' operations on shared storage), the receiver presets key name filtering logic in the callback function. When the listener captures the storage event, it first reads the key property of the event object (i.e., the shared storage key name being operated on) and determines whether the key name is consistent with the preset key name agreed upon by the sender. If they are inconsistent, the execution of the callback function is terminated directly, and the event is not processed. If they are consistent, the current changed data is confirmed to be the target communication data, and the subsequent data acquisition process continues.

[0056] Meanwhile, the receiver listener has environment adaptability. If the browser is detected as Safari, an additional hidden iframe is created. The hidden iframe is used to indirectly listen for changes in shared storage data, ensuring that the target data changes of the preset key name can be stably detected in different browser environments, avoiding communication interruption due to browser compatibility.

[0057] As in step S4 above, after the sender performs the storage operation, the browser triggers the storage event to all tabs (including the receiving tabs) that have registered storage event listeners in the same origin. After the receiving listener captures the event, it executes the preset event callback function.

[0058] The event callback function first retrieves the changed target data from the event object, and then reads the latest value corresponding to the preset key name in the shared storage through the newValue property of the event object. If newValue is null (indicating that the data has been deleted), the event callback function terminates execution directly to avoid invalid processing; if newValue is not null, the string is split according to the preset separator (such as "|") to separate the encrypted data and the hash value.

[0059] Subsequently, the receiver performs a decryption operation on the encrypted data: the receiver must first obtain a mutation key consistent with the sender's. If the receiver and sender share a key pool (e.g., through synchronization via a common backend), the receiver repeats the key mutation process based on the sender's page identifier (which can be extracted from auxiliary information carried in the encrypted data) and domain level to generate the same mutation key; if the receiver has pre-stored the sender's mutation key, it directly uses that key. The receiver uses the mutation key and a symmetric decryption algorithm consistent with the sender's to decrypt the encrypted data, obtaining the original target data; simultaneously, it can calculate the SHA-256 hash value of the decrypted original data and compare it with the split hash value. If they match, it confirms that the data has not been tampered with; if they do not match, it triggers a data anomaly alarm and terminates subsequent operations.

[0060] Finally, the recipient executes predefined operations based on business requirements. These predefined operations include, but are not limited to, data display updates (such as filling the form content from the target data into the recipient's page form), data preloading (such as preloading related resources like images and scripts based on resource addresses in the target data), and status synchronization (such as synchronizing the page operation status from the target data to the button disable / enable status on the recipient's page). This enables cross-tab page business collaboration and completes the entire data communication process.

[0061] In one embodiment, the browser shared storage object is localStorage or sessionStorage, and the API is localStorage.setItem() or sessionStorage.setItem().

[0062] In this embodiment, the browser-shared storage object used by the sender to encrypt and store the target data is either localStorage or sessionStorage. If long-term retention of communication data is required (e.g., cross-browser session sharing), localStorage is selected, and its native API localStorage.setItem(key, value) is called. If only temporary data synchronization is required (limited to the current browser session), sessionStorage is selected, and its native API sessionStorage.setItem(key, value) is called. The key for both APIs is a pre-agreed key name agreed upon by the sender and receiver (to avoid conflicts with other business key names), and the value is a concatenated string of the target data encrypted with the mutation key and a hash value, thereby achieving secure cross-tag storage of encrypted data.

[0063] In one embodiment, the preset key name is a specific key value predetermined for the sender's tab page and the receiver's tab page, used to limit the detection range of the storage event listener and exclude interference from changes in non-target data in the shared storage object.

[0064] In this embodiment, in the same-origin, same-browser tag communication method, the preset key name is a specific key value agreed upon in advance by the sender and receiver (such as crossTabData_2025). Its core function is to define the detection range for the receiver's storage event listener: when the listener detects a data change in a shared storage object (localStorage or sessionStorage), it first determines whether the key name of the changed data is consistent with the preset key name, and only performs subsequent processing on the consistent target communication data, thereby eliminating interference from non-target data changes caused by other business operations and ensuring that the listener accurately responds to communication-related data updates.

[0065] In one embodiment, the event callback function is further used for:

[0066] When the target data after the change is detected to be empty, the predefined operation is prohibited.

[0067] In this embodiment, when the modified target data obtained from the shared storage object is empty (e.g., the newValue attribute is null, possibly due to data being accidentally deleted or transmission errors), subsequent predefined operations (such as data display updates, state synchronization, etc.) will be directly prohibited to prevent the receiver from executing incorrect business logic based on invalid data and to ensure the reliability of the communication process.

[0068] In one embodiment, after storing the target data via API, the sender's tag page is further used for:

[0069] Upon receiving a clear operation command, exiting the browser, or at preset intervals, the shared storage object is cleared; the clear operation is performed by calling the window.localStorage.clear() or window.sessionStorage.clear() function.

[0070] In this embodiment, after the sender's tag page calls the API to complete the target data storage, it will also perform a clearing operation on the shared storage object in three scenarios:

[0071] The clearing operation is triggered in three ways: first, when a clear command is received; second, when the user exits the browser; and third, when it is automatically triggered at preset intervals (e.g., every hour). The clearing operation is implemented by calling the corresponding function. If localStorage is used, window.localStorage.clear() is called; if sessionStorage is used, window.sessionStorage.clear() is called. This clears redundant data in the shared storage object and avoids consuming too much browser storage resources.

[0072] In one embodiment, the predefined operation includes data display update, data preloading, or state synchronization;

[0073] The data display update refers to the recipient's tab page refreshing the page content in real time based on the changed target data; the data preloading refers to the recipient's tab page preloading related resources based on the changed target data; and the status synchronization refers to the recipient's tab page synchronizing the operation status of the sender's tab page based on the changed target data.

[0074] In one embodiment, a modified key is obtained by modifying a preset key in the key pool based on the sender's page identifier, including:

[0075] The sender's tag page extracts the domain level information of the current page and the page identifier generated during page rendering, and generates the page identifier as a key mutation factor;

[0076] Based on domain name level information, the corresponding preset key is selected from the key pool; the key pool stores multiple preset keys, each of which has a different type and corresponds to different domain name level information.

[0077] The selected preset key is mutated based on the key mutation factor to obtain the mutated key.

[0078] In this embodiment, firstly, unique characteristic information that can uniquely associate with the sender's tag page is collected to provide a customized basis for subsequent key mutation, ensuring that the mutated key is strongly bound to the sender's page. The specific operation logic is as follows: The sender's tag page first extracts the domain name hierarchy information of the current page through the browser's native interface. Using the browser's function to obtain the complete domain name, complete domain names such as application, store, sample, and business are obtained. Then, the hierarchy is parsed according to the domain name hierarchy splitting rules. The sender uses a preset hierarchy recognition algorithm to finally determine and store the domain name hierarchy information of the current page, providing a basis for subsequently selecting a suitable preset key.

[0079] Next, the sender extracts the page identifier generated during page rendering. This page identifier must be unique across different tabs within the same browser. It is typically generated when the page completes its initial rendering event, by combining browser environment characteristics with page rendering timing information. For example, it combines the page navigation start timestamp (accurate to milliseconds), 10 random characters, and the initial page rendering height, concatenating them into a string like "1718923456789-random character combination-800". After generation, this identifier is stored using the browser's session storage function (ensuring it can still be read after a page refresh) to avoid duplicate generation and inconsistencies.

[0080] Finally, the sender converts the page identifier into a standardized key mutation factor. Since the page identifier is in string format, it needs to be encoded to adapt to subsequent encryption operations: first, the page identifier string is converted into binary data using a common character encoding, and then converted into a processable text format using basic encoding; if the length of the converted encoding is less than the preset length (usually 64 bits, suitable for the segmented operation requirements of symmetrical encryption keys), it is padded with "0"s to reach 64 bits; if the length exceeds 64 bits, it is compressed to 64 bits using a national cryptographic hash algorithm, ultimately forming a fixed-length, uniformly formatted key mutation factor to ensure consistency and operability in subsequent mutation operations on the preset key.

[0081] Next, precise matching between the key pool and the sending page is achieved through domain level, avoiding security risks caused by misuse of keys by pages at different levels. At the same time, the security and adaptability of the key pool are improved by using multiple types of preset keys. The specific operation logic is as follows:

[0082] First, the storage and structure design of the key pool is clearly defined. The key pool is typically stored in a local database provided by the browser (supporting large-capacity, structured storage), avoiding storage in local storage (which is prone to accidental deletion or consuming storage quotas). Multiple preset keys stored in the key pool are generated using encryption algorithms, and each preset key has a different type. In one embodiment, the type differences are reflected in the choice of encryption algorithm (e.g., some preset keys are generated based on Chinese national cryptographic algorithms, suitable for domestic compliant scenarios; some are generated based on internationally common encryption algorithms, suitable for internationally common scenarios), key length (e.g., 128 bits, 256 bits, adapting to different security level requirements), and key validity period (e.g., some preset keys have a validity period of 7 days, some 30 days, set according to the business security requirements corresponding to the domain level).

[0083] Secondly, establish a correspondence between preset keys and domain name hierarchical information. Within the key pool, each preset key is associated with a domain name hierarchical matching rule, designed with precise matching and hierarchical priority.

[0084] Finally, the sender executes the preset key selection process. The sender compares the extracted domain level information with the domain level matching rules of the preset keys in the key pool one by one to select the corresponding preset key. After selection, the sender reads the preset key through a transaction operation in the local database (the reading process must be encrypted with a temporarily generated session key to avoid exposing the preset key in plaintext), ensuring that the selected preset key is both compatible with the domain level of the current sender's page and meets business security requirements.

[0085] Next, a mutation operation is performed on the selected preset key to ensure that the mutated key retains the basic security characteristics of the preset key while incorporating the unique features of the sender's page, making the mutated key more secure and unique, and enhancing the security of data transmission.

[0086] In one embodiment, when storing the target data to be transmitted in a preset key name of a shared storage object using a mutation key, the method further includes:

[0087] Domain hierarchical information and page identifiers are concatenated into key metadata, which is then stored along with the encrypted target data in the value corresponding to the preset key name of the shared storage object.

[0088] In this embodiment, after encrypting the target data to be transmitted with the mutation key and storing it in the preset key name of the shared storage object, an additional metadata concatenation operation is required: the extracted domain name level information and page identifier are concatenated into key metadata, and then the key metadata is merged with the encrypted target data and stored together in the value corresponding to the preset key name of the shared storage object, providing key association information for the receiver to subsequently match the corresponding preset key and restore the mutation key.

[0089] In one embodiment, the selected preset key is mutated based on the key mutation factor to obtain a mutated key, including:

[0090] The selected preset key is divided into a first key segment and a second key segment. The key mutation factor and the first key segment are subjected to a bit-by-bit weighted operation to obtain the first mutation segment. The weights in the bit-by-bit weighted operation are jointly determined by the key mutation factor and the character types of the corresponding bits of the first key segment.

[0091] Perform a bitwise XOR operation between the key mutation factor and the second key segment to obtain the second mutation segment;

[0092] Generate a mutation key based on the first mutation segment and the second mutation segment.

[0093] In this embodiment, firstly, a unique feature is injected into the preset key through segmented differential operations. The first segment of the key employs a bit-by-bit weighted operation to enhance the randomness and uniqueness of mutations through dynamic weighting. The specific operation logic is as follows:

[0094] The selected preset key is segmented, and preset keys of different lengths are split into a first key segment and a second key segment according to the principle of equal length division. Next, a dynamic weighting rule for bit-by-bit weighting is determined. The weights are jointly determined by the character type of the corresponding bit of the key mutation factor and the character type of the corresponding bit of the first key segment. In a feasible embodiment, the character type is divided into two categories according to the numerical characteristics of binary data: if the value of a bit is 1, it is defined as an active bit; if the value is 0, it is defined as a base bit. Four preset weight combination rules are used: If the bit corresponding to the key mutation factor is an activation bit and the bit corresponding to the first segment key is also an activation bit, the weight is set to 1.5 (the superposition of the two types of activation bits enhances the influence of this bit on the mutation result); if the bit corresponding to the key mutation factor is an activation bit and the bit corresponding to the first segment key is a base bit, the weight is set to 1.2 (a single activation bit moderately increases the influence of this bit); if the bit corresponding to the key mutation factor is a base bit and the bit corresponding to the first segment key is an activation bit, the weight is set to 0.8 (a single activation bit reduces the influence of this bit); if the bit corresponding to the key mutation factor is a base bit and the bit corresponding to the first segment key is a base bit, the weight is set to 0.5 (the superposition of the two types of base bits minimizes the influence of this bit).

[0095] Finally, a bitwise weighted operation is performed to generate the first variant segment. Operations are performed on each pair of corresponding bits of the key mutation factor and the first key segment, from left to right: first, the two binary values ​​(0 or 1) are converted to decimal values; then, the decimal value of the corresponding bit of the key mutation factor is multiplied by the dynamic weight to obtain the weighted value; the weighted value is added to the decimal value of the corresponding bit of the first key segment to obtain the bitwise operation result; if the bitwise operation result is greater than 1, 1 is taken as the binary result of that bit; if the bitwise operation result is less than or equal to 1, the binary result is determined according to the rounding principle. All bitwise operation results are concatenated in their original order to form the first variant segment with the same length as the single key segment, ensuring that this segment retains both the basic characteristics of the first key segment and incorporates the exclusive weighted influence of the key mutation factor.

[0096] Then, the randomness of the second key is enhanced by an XOR operation, while a weighted operation with the first key creates a differentiated combination, avoiding the security reduction caused by the repetition of the two mutation logics. The specific operation logic is as follows:

[0097] First, confirm that the format of the key variation factor and the second key are consistent, ensuring that both are in binary format and have the same length. If the key variation factor is in text encoding format (such as the basic encoding format), convert it to binary data first. If the second key is in decimal or hexadecimal format due to storage format issues, it also needs to be converted to binary data to avoid format mismatch leading to calculation errors.

[0098] Next, the rules for bitwise XOR operation are clarified. The core logic of XOR operation is that the result is 0 for the same bits and 1 for different bits. Specifically, for each pair of corresponding bits: if the binary value of the corresponding bit of the key mutation factor is the same as the binary value of the corresponding bit of the second key (both are 0 or both are 1), then the result of the operation of that bit is 0; if the two values ​​are different (one is 0 and the other is 1), then the result of the operation of that bit is 1.

[0099] Finally, a bitwise XOR operation is performed to generate the second variant segment. The XOR operation is performed sequentially from left to right on all corresponding bits of the key mutation factor and the second key segment, and the result of each bit is recorded. After all bitwise operations are completed, all results are concatenated in their original order to form the second variant segment with the same length as the single key segment. Compared to the weighted operation of the first segment, the XOR operation logic of the second segment is simpler but more random, quickly breaking the original binary distribution pattern of the second key segment. This creates a complementary effect of weighted control and random flipping with the first variant segment, improving the overall security strength of the mutated key.

[0100] Finally, a mutation key is generated based on the first and second mutation segments. The first and second mutation segments are concatenated into a complete binary key stream in a fixed order: first mutation segment first, second mutation segment last. Next, a format conversion is performed on the concatenated key. Since encryption algorithms typically require keys in a specific format, the complete binary key stream needs to be converted to the target format: if using a national cryptographic algorithm, the binary data is converted to hexadecimal text format; if using an internationally recognized encryption algorithm, the binary data is converted to Base64 encoded format, ensuring that the mutation key format meets the input requirements for encryption operations.

[0101] In one embodiment, a modified key is obtained by modifying a preset key in the key pool based on the sender's page identifier, including:

[0102] Based on each numeric character in the preset key, they are sequentially mapped to coordinate points in a coordinate system, and then connected sequentially to simulate a key curve;

[0103] Based on the characters in the sender's page identifier, a character array is generated; feature attributes of the character array in multiple dimensions are extracted.

[0104] Each feature attribute is mapped to a corresponding number; each number is used as the horizontal axis and substituted into the key curve to solve for the vertical axis value.

[0105] The calculated ordinate values ​​are combined to obtain a coordinate value combination; the coordinate value combination is aligned with the preset key, and weighted calculation is performed bit by bit; the results of the weighted calculation are combined to obtain the mutated key; wherein, when performing weighted calculation bit by bit, the weight is allocated according to the numerical difference in the corresponding bit.

[0106] In this embodiment, firstly, the preset key in the key pool is screened and extracted. The preset key is a symmetric key containing numeric characters (e.g., 32-bit, with a character set of 0 to 9). The sender's tag page first traverses each character of the preset key and filters out all numeric characters (if the preset key contains non-numeric characters).

[0107] Next, the numeric characters are sequentially mapped to coordinate points in a coordinate system. A two-dimensional Cartesian coordinate system is used (the X-axis is the sequence number axis, and the Y-axis is the numeric value axis). The X-coordinate of the coordinate point is determined according to the arrangement order of the numeric characters of the preset key, and the Y-coordinate of the coordinate point is determined according to the value of the numeric character. For example, if the first 5 numeric characters of the preset key are 3, 7, 2, 9, and 5, then the first numeric character 3 is mapped to coordinate points 1 and 3, the second numeric character 7 is mapped to coordinate points 2 and 7, and so on. All numeric characters of the preset key are mapped to corresponding coordinate points to form an original coordinate point sequence containing multiple coordinate points.

[0108] Finally, the coordinate points are connected sequentially to simulate and generate a key curve. The adjacent coordinate points are connected by linear interpolation in ascending order of their X coordinates (i.e., the original arrangement order of the numeric characters of the preset key). At the same time, the connected polyline is smoothed (by calculating the midpoint of adjacent line segments, the polyline is adjusted to a continuous and smooth curve to avoid overly sharp inflection points). In the end, a key curve that uniquely corresponds to the preset key is formed. The shape of this curve is directly determined by the numeric character sequence of the preset key, ensuring that different preset keys correspond to different curve shapes.

[0109] Next, the sender label page first removes invalid characters (such as spaces and newlines) from the page identifier, and then segments the remaining characters into segments of fixed length: if the page identifier length is L and the number of rows of the character array is set to M, then the length of each segment is L divided by M (if L is not divisible by M, then 0 is added to the last segment to the specified length), forming an initial character array of M rows and K columns (K is the length of each segment).

[0110] Next, multi-dimensional feature attributes of the character array are extracted, from three dimensions: character type distribution, character numerical features, and array structure features, to ensure that the feature attributes can fully reflect the uniqueness of the page identifier.

[0111] Character type distribution characteristics: The proportion of numeric characters, alphabetic characters, and symbolic characters in each row of the character array is statistically analyzed. For example, if a row contains 3 numeric characters, 1 letter, and 1 symbol, then the proportion of numeric characters is 60%, the proportion of alphabetic characters is 20%, and the proportion of symbolic characters is 20%. The proportions of these three types in each row are used as the type distribution characteristics for that row. A total of M sets of type distribution characteristics are extracted from the entire array.

[0112] Character numerical features: Convert alphanumeric characters in the array to numbers according to ASCII codes (e.g., A equals 65, a equals 97), and convert symbol characters to numbers according to a preset mapping table (e.g., hash equals 35, minus equals 45), to obtain a numerical array; calculate the mean, maximum, and minimum values ​​of each column in the numerical array. For example, if a column contains values ​​of 65, 35, 97, 45, and 20, then the mean is 52.4, the maximum is 97, and the minimum is 20. Use the three types of values ​​in each column as the numerical statistical features of that column. Extract a total of K sets of numerical statistical features from the entire array.

[0113] Array structure features: Calculate the row difference (the sum of the absolute values ​​of the differences between corresponding column values ​​in two adjacent rows) and column difference (the sum of the absolute values ​​of the differences between corresponding row values ​​in two adjacent columns) of the numerical array. For example, the row difference between the 1st and 2nd rows is equal to the absolute value of 65 minus 35 plus the absolute value of 35 minus 45 plus the absolute value of 97 minus 20 plus the subsequent value. The column difference between the 1st and 2nd columns is equal to the absolute value of 65 minus 35 plus the absolute value of 35 minus 97 plus the absolute value of 97 minus 45 plus the subsequent value. The sum of all row differences and the sum of all column differences are used as the structural difference features of the array, and a total of 2 sets of structural difference features are extracted.

[0114] Finally, the extracted multi-dimensional feature attributes are filtered and integrated to remove duplicate or overly correlated features. The final page identifier feature attribute set, composed of type distribution features, numerical statistical features, and structural difference features, is retained to ensure that the feature attribute set corresponds one-to-one with the page identifier, with no duplication and complete information.

[0115] Multi-dimensional feature attributes are mapped one by one to standardized numbers, and corresponding mapping rules are adopted for different types of feature attributes:

[0116] For example, type distribution feature mapping: multiply the proportion of numbers, letters, and symbols by 10 respectively, and take the integer part as the mapping number. For example, if the type distribution of a certain row is 60%, 20%, and 20%, then it is mapped to the numbers 6, 2, and 2. The specific mapping rules for feature attributes of different types will not be elaborated here.

[0117] All the mapped feature attributes are arranged in the order of type distribution features to numerical statistical features and then to structural difference features to form a feature number sequence. The sequence length is consistent with the total number of feature attributes.

[0118] Next, the feature numbers are used as the x-axis and substituted into the key curve to solve for the y-axis value. The X-axis of the key curve is used as the feature number axis, and each number in the feature number sequence is used as the X-coordinate value and substituted into the curve equation of the key curve. Finally, the solved y-axis values ​​are organized and combined. The solved y-axis values ​​corresponding to each feature number are arranged in the original order of the feature number sequence. If decimals occur during the solution process, they are rounded to the nearest integer (ensuring the values ​​are integers to accommodate subsequent key mutation numerical operations), forming a coordinate value combination. The length of this combination is consistent with the feature number sequence, and each value is strongly bound to the feature attribute identified on the page and the curve shape of the preset key.

[0119] The coordinate value combination is length-aligned with the preset key. If the length of the coordinate value combination is P and the length of the preset key is N: if P equals N, then the coordinate value combination is directly aligned bit by bit; if P is less than N, then the coordinate value combination is repeated cyclically until the length reaches N; if P is greater than N, then the first N bits of the coordinate value combination are truncated and aligned with the preset key (ensuring that the lengths of the two are consistent, and operations can be performed bit by bit).

[0120] Next, a weighted calculation is performed bit by bit, with weights allocated according to the differences between corresponding digits. The aligned coordinate value combination is denoted as C (C1, C2 up to CN), and the preset key is denoted as K (K1, K2 up to KN, which has been converted into a digital sequence):

[0121] Calculate the difference between each digit: Δi is equal to the absolute value of Ci minus Ki (i ranges from 1 to N, and Δi is the absolute value of the difference between the i-th digit).

[0122] Determine the weight value for each bit: Set the weight according to the magnitude of Δi. The preset weight rules can be: if Δi is less than 5, the weight is 1.2; if Δi is greater than or equal to 5 and less than or equal to 10, the weight is 1.0; if Δi is greater than 10, the weight is 0.8.

[0123] Perform a weighted calculation: The weighted result Ri of the i-th bit is equal to (Ci multiplied by 0.4 plus Ki multiplied by 0.6) multiplied by the weight value, where 0.4 and 0.6 are the basic weights of Ci and Ki, ensuring that the basic security of the preset key is not excessively diluted. Finally, combine the weighted results to generate a variant key. Arrange the integer weighted calculation results of each bit in order and convert the base to obtain the variant key. After generation, perform a uniqueness check on the variant key. If the check passes, it is stored in the browser's security partition for subsequent target data encryption, ensuring that the variant key retains the basic security characteristics of the preset key while incorporating the unique characteristics of the page identifier, possessing high security and uniqueness.

[0124] In one embodiment, a modified key is obtained by modifying a preset key in the key pool based on the sender's page identifier, including:

[0125] The sender label page converts the numeric characters in the page identifier into corresponding two-dimensional coordinates as nodes in the undirected graph, maps the alphanumeric characters in the page identifier to numbers and assigns values ​​to each node; nodes are connected by edges, and the value of an edge is determined by the values ​​of the two connected nodes, thus forming the undirected graph of the page identifier;

[0126] Extract the core features of the undirected graph with page identifiers, including the mean value of edges and the number of edges.

[0127] Select a preset key from the key pool, take the mean of the edges modulo 256 to get the offset K, and cyclically shift each element in the original S-box of the SM4 algorithm to the right by K positions to generate a unique S-box.

[0128] The number of core features is obtained and used as the offset parameter when generating the SM4 round key. When generating subkeys in each round, an XOR operation is performed with the offset parameter.

[0129] Substitute the preset key into the adjusted SM4, and perform multiple rounds of iteration using a dedicated S-box and the adjusted round key to obtain the initial mutation key;

[0130] The final mutation key is generated by flipping a specified bit of the initial mutation key based on the number of edges.

[0131] In this embodiment, the sending label page first classifies the characters in the page identifier, filtering out numeric and alphanumeric characters (removing invalid characters such as symbols and spaces): For numeric characters, they are split according to the rule of grouping every two consecutive digits (if the last group has less than two digits, it is padded with 0 to 2 digits), and each group of digits is converted into a two-dimensional coordinate (e.g., the numeric characters 12345 are split into 12, 34, 50, corresponding to two-dimensional coordinates 1 and 2, 3 and 4, 5 and 0). Each two-dimensional coordinate is used as a node in an undirected graph, ensuring that the number of nodes is consistent with the number of numeric character groups.

[0132] Next, numerical mapping is performed on the letter characters in the page identifier and values ​​are assigned to the nodes. Each letter character is converted into a number according to its ASCII code (e.g., uppercase A equals 65, lowercase a equals 97). If the number of letter characters is the same as the number of nodes, the number corresponding to each letter is directly used as the value of the corresponding node. If the number of letter characters is less than the number of nodes, the letter and number are distributed cyclically. If the number of letter characters is more than the number of nodes, the numbers corresponding to the first N letters (N is the number of nodes) are extracted as the values ​​of the nodes, ensuring that each node has a unique numerical identifier.

[0133] Finally, edges between nodes are constructed and assigned values. Adjacent node connection rules are used to connect nodes with adjacent indices in the undirected graph with edges. The value of an edge is calculated by the values ​​of the two connected nodes, specifically the absolute value of the difference between the values ​​of the two nodes. After all nodes and edges are constructed, an undirected graph that uniquely maps to the current page identifier is formed.

[0134] The sender label page first calculates the mean value of the edges, counts the values ​​of all edges in the undirected graph identified by the page, adds up the values ​​of all edges to get the total edge values, and then divides the total edge values ​​by the total number of edges to get the mean value of the edges (if the result is a decimal, it is rounded to the nearest integer to ensure that the parameter is in integer format).

[0135] Next, the number of edges is counted. The total number of edges in the undirected graph of the page identifier is directly counted, and the number of edges is used as one of the core features for the specified bit flipping operation in subsequent key mutation.

[0136] Select a preset key from the key pool, extract the mean value of the edges in the core feature set of the undirected graph, and take the modulo of the mean value of the edges with 256 to obtain the S-box adjustment offset K (ensure that the value of K is between 0 and 255 to fit the size of the original SM4 S-box). The original SM4 S-box is an 8-bit data replacement table with 16 rows and 16 columns. Adjust each element in the original S-box according to the rule of cyclically shifting it right by K bits. If the element exceeds the range of 8 bits after shifting right, correct it by taking the modulo of 256. After the adjustment is completed, a unique S-box corresponding to the current page identifier is generated.

[0137] Next, the round key generation parameters are adjusted, and the number of edges in the core feature set of the undirected graph is extracted. The number of edges is used as the offset parameter when generating the round key in the SM4 algorithm. The SM4 algorithm contains 32 rounds of iterative operations. Each round of iteration needs to generate a corresponding round key. In the original round key generation process, a fixed round constant is used in each round. After adjustment, the fixed round constant of each round is XORed with the offset parameter (number of edges) to obtain the adjusted round constant. In subsequent rounds when generating subkeys, the adjusted round constant is used to replace the original round constant, ensuring that the round key generation process is strongly bound to the page identifier.

[0138] The sender's label page selects a 128-bit preset key as the initial input key for the SM4 algorithm, and substitutes it into the adjusted SM4 algorithm, which includes a dedicated S-box and an adjusted round key. The algorithm performs 32 rounds of iterative operations. In each round of iteration, the nonlinear transformation stage uses a dedicated S-box to replace the original S-box for data replacement, and the linear transformation stage uses a subkey generated by the adjusted round key for operation, ensuring that each round of iteration incorporates the core features of the page's undirected graph.

[0139] After 32 rounds of iterative computation, a 128-bit intermediate computation result is output. This result is used as the initial mutation key, which already possesses the basic security characteristics of the preset key and the exclusive mutation characteristics of the page identifier.

[0140] The sender's label page first determines the specified bit range of the initial mutation key. It extracts the number of edges from the core feature set of the undirected graph, multiplies this number by 8 to obtain the starting position of the specified bits, and the range of the specified bits is from the starting position to the starting position plus 7. If the calculated starting position exceeds the key length (128 bits), it takes the remainder of the starting position divided by 128 to redetermine the specified bit range, ensuring that the specified bits are within the valid key length.

[0141] The initial mutation key's bits within a specified range are flipped (0 becomes 1, 1 becomes 0). This flipping operation only applies to the specified bit range; other bits remain unchanged to avoid excessively altering the initial mutation key's basic structure. After flipping the specified bits, a 128-bit final mutation key is obtained. This key undergoes a validity check. If the check passes, it is stored in the browser's security partition for subsequent target data encryption. This ensures that the final mutation key not only meets the security requirements of the SM4 algorithm but also possesses the characteristic of being uniquely bound to the current page identifier, effectively improving the key's resistance to cracking.

[0142] In the above embodiments, this application incorporates some existing algorithms and technical features for explanation and description to make the specification more detailed, clear, and complete, thus complying with the provisions of the Patent Law. However, this is not achieved by using a series of complex steps and algorithmic formulas, nor by complicating the technical solution, nor by combining or stacking conventional or simple features. The existing algorithms and technical features listed are for the purpose of disclosing the specific implementation methods of each step of this application (not to limit this application) and to avoid situations where this application cannot be implemented.

[0143] Reference Figure 2 In another embodiment of the present invention, a data communication device for different tab pages of the same origin and browser is also provided, comprising:

[0144] The mutation unit is used to mutate the preset key in the key pool based on the sender's page identifier in the same origin and same browser environment to obtain the mutated key.

[0145] The storage unit is used to call the browser's shared storage object API to encrypt and store the target data to be transmitted under the preset key name of the shared storage object using a mutation key.

[0146] The listening unit is used by the receiving tab page to detect changes in the target data under the preset key name in the shared storage object through the registered storage event listener;

[0147] The execution unit is used to listen for the storage event when the target data changes, execute the event callback function of the receiving tab page to obtain the changed target data, and decrypt the changed target data to perform predefined operations.

[0148] In this embodiment, the specific implementation of each unit in the above device embodiment is described in the above method embodiment, and will not be repeated here.

[0149] Reference Figure 3 This invention also provides a computer device, which can be a server, and its internal structure can be as follows: Figure 3As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0150] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0151] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0152] In summary, the data communication method and apparatus between different tab pages of the same origin and browser provided in this embodiment of the invention includes: in a same origin and browser environment, the sending tab page mutates a preset key in a key pool based on the sending page identifier to obtain a mutated key; it calls the API of the browser's shared storage object to encrypt and store the target data to be transmitted under a preset key name in the shared storage object using the mutated key; the receiving tab page detects changes to the target data under the preset key name in the shared storage object through a registered storage event listener; when the target data changes, the storage event is triggered, the event callback function of the receiving tab page is executed to obtain the changed target data, and the changed target data is decrypted to perform a predefined operation. This invention overcomes the current limitation of not being able to directly perform real-time secure communication between different tab pages.

[0153] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0154] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0155] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for communicating data between homologous and homotopic pages in different tabs of the same browser, characterized in that, The method comprises the following steps: In the same browser environment, the sender label page varies a preset key in the key pool based on the page identifier of the sender to obtain a variant key; including: the sender label page extracts the domain name level information of the current page, and extracts the page identifier generated during page rendering, and generates the page identifier as a key variation factor; based on the domain name level information, a corresponding preset key is selected from the key pool; the key pool stores a plurality of preset keys, each preset key is different in type, and each preset key corresponds to different domain name level information; the selected preset key is divided into a first segment key and a second segment key, the key variation factor and the first segment key are executed by bit weighting operation to obtain a first variation segment; wherein the weight of the bit weighting operation is determined by the character type of the corresponding bit of the key variation factor and the first segment key; the key variation factor and the second segment key are executed by bit XOR operation to obtain a second variation segment; the variant key is generated based on the first variation segment and the second variation segment; The API of the browser shared storage object is called, and the target data to be transmitted is stored in the preset key name of the shared storage object through the variant key encryption; The receiver label page detects the changes of the target data under the preset key name in the shared storage object through the registered storage event listener; When the target data changes, the storage event is triggered, and the event callback function of the receiver label page is executed to obtain the changed target data, and the changed target data is decrypted to perform a predefined operation.

2. The method of claim 1, wherein the method further comprises: The preset key name is a specific key value determined in advance by the sender label page and the receiver label page, which is used to limit the detection range of the storage event listener and exclude the interference of non-target data changes in the shared storage object.

3. The method of claim 1, wherein the method further comprises: The event callback function is also used to: When it is detected that the changed target data is empty, the predefined operation is prohibited.

4. The method of claim 1, wherein the method further comprises: After the sender label page stores the target data through the API, it is also used to: Receive the empty operation instruction, exit the browser, or every preset time, execute the empty operation of the shared storage object; the empty operation is executed by calling the window.localStorage.clear() or window.sessionStorage.clear() function.

5. The method of claim 1, wherein the method further comprises: The predefined operation includes data display update, data preloading or state synchronization; The data display update is to refresh the page display content in real time according to the changed target data, the data preloading is to load the associated resources in advance based on the changed target data, and the state synchronization is to synchronize the operation state of the sender label page based on the changed target data.

6. The method of claim 1, wherein the method further comprises: When the target data to be transmitted is stored in the preset key name of the shared storage object through the variant key encryption, it also includes: The domain name level information and the page identifier are spliced into key metadata, and the encrypted target data is stored in the value corresponding to the preset key name of the shared storage object.

7. An apparatus for communicating data between homologous and homotopic pages of a browser, characterized by: It includes: The variation unit is used to, in a homologous same browser environment, send a sender label page to vary a preset key in a key pool based on a page identification of the sender to obtain a variation key; the variation unit includes: the sender label page extracts domain name hierarchical information of a current page and extracts a page identification generated when the page is rendered, and generates the page identification as a key variation factor; based on the domain name hierarchical information, a corresponding preset key is selected from the key pool; the key pool stores a plurality of preset keys, the types of the preset keys are different, and the preset keys correspond to different domain name hierarchical information; the selected preset key is divided into a first segment key and a second segment key, the key variation factor and the first segment key are subjected to bit-by-bit weighted operation to obtain a first variation segment; wherein the weight in the bit-by-bit weighted operation is determined by the character types on the corresponding positions of the key variation factor and the first segment key; the key variation factor and the second segment key are subjected to bit-by-bit exclusive or operation to obtain a second variation segment; and the variation key is generated based on the first variation segment and the second variation segment; The storage unit is used to call an API of a browser shared storage object, and store target data to be transmitted in the shared storage object under a preset key name through the variation key; The listening unit is used to detect changes of the target data under the preset key name in the shared storage object through a registered storage event listener by a receiver label page; The execution unit is used to, when the target data is changed, listen to the storage event being triggered, execute an event callback function of the receiver label page to obtain the changed target data, and decrypt the changed target data to execute a predefined operation.

Images