A data processing method, apparatus and device
By storing device identifiers in multiple storage locations on the web client and performing comparison detection and update processing, the problem of unstable data storage on the web client is solved, and secure data interaction is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING BANGCLE TECH CO LTD
- Filing Date
- 2024-11-28
- Publication Date
- 2026-05-29
AI Technical Summary
Data storage on web clients is susceptible to the effects of web page operations, leading to unstable data storage and an inability to effectively guarantee the security of data interaction.
In the web client, device identifiers are stored in multiple preset storage locations (page tags, persistent cache, temporary cache, and RAM), and comparison detection and update processing are performed when user operation is detected to generate target verification information to ensure the security of data access requests.
It improves the stability of device identification, enables secure data transmission with the server, and enhances the security of web data interaction.
Smart Images

Figure CN122120255A_ABST
Abstract
Description
Technical Field
[0001] This document relates to the field of computer technology, and in particular to a data processing method, apparatus, and device. Background Technology
[0002] With the rapid development of network technology and the surge in internet users, web services have become the mainstream way to provide services to the outside world. However, this trend has also been accompanied by increasingly rampant cyberattacks, with normal network services frequently being disrupted and the security of user privacy data not being guaranteed.
[0003] To ensure the data security of web services, web clients can interact with the server based on stored device identifiers. However, because web client data storage is susceptible to the influence of web page operations, data storage is unstable, making it impossible to effectively guarantee the security of data interaction. Therefore, this specification provides a technical solution to improve the security of web data interaction. Summary of the Invention
[0004] The purpose of the embodiments in this specification is to provide a technical solution to improve the security of web data interaction.
[0005] To achieve the above technical solution, the embodiments in this specification are implemented as follows: This specification provides a data processing method applied to a web client. The method includes: receiving a device identifier generated by a server based on the device attribute information of the web client; storing the device identifier in multiple preset storage locations, including page tags, persistent cache, temporary cache, and RAM; upon detecting a user triggering a target web page operation, comparing and detecting the device identifiers stored in the multiple preset storage locations; and if multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, updating the device identifier stored in the second storage location based on the device identifier stored in the first storage location; upon detecting a data access instruction triggered by the user, generating target verification information based on the device identifier stored in the preset storage locations, and sending a data access request carrying the target verification information to the server, wherein the data access request triggers the server to perform device verification processing on the web client based on the target verification information, and if device verification is successful, processing the data access request.
[0006] This specification provides a data processing apparatus, comprising: an identifier receiving module for receiving a device identifier generated by a server based on device attribute information of the data processing apparatus; an identifier storage module for storing the device identifier in multiple preset storage locations, the preset storage locations including page tags, persistent cache, temporary cache, and RAM; a comparison detection module for performing comparison detection processing on the device identifiers stored in the multiple preset storage locations when a user triggers an operation on a target web page, and updating the device identifier stored in the second storage location based on the device identifier stored in the first storage location when multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected; and a request sending module for generating target verification information based on the device identifier stored in the preset storage locations when a user triggers a data access instruction, and sending a data access request carrying the target verification information to the server, the data access request triggering the server to perform device verification processing on the data processing apparatus based on the target verification information, and processing the data access request if the device verification is successful.
[0007] This specification provides an embodiment of a data processing device, comprising: a processor; and a memory arranged to store computer-executable instructions, wherein, when executed, the executable instructions cause the processor to: receive a device identifier generated by a server based on device attribute information of a web client; store the device identifier in multiple preset storage locations, the preset storage locations including page tags, persistent cache, temporary cache, and running memory; upon detecting a user triggering an operation on a target web page, perform a comparison and detection process on the device identifiers stored in the multiple preset storage locations, and if multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected among the multiple preset storage locations, update the device identifier stored in the second storage location based on the device identifier stored in the first storage location; upon detecting a data access instruction triggered by the user, generate target verification information based on the device identifier stored in the preset storage locations, and send a data access request carrying the target verification information to the server, the data access request being used to trigger the server to perform device verification processing on the web client based on the target verification information, and, if the device verification is successful, process the data access request.
[0008] This specification also provides a storage medium for storing computer-executable instructions. When executed by a processor, the executable instructions implement the following process: receiving a device identifier generated by a server based on the device attribute information of a web client; storing the device identifier in multiple preset storage locations, including page tags, persistent cache, temporary cache, and RAM; upon detecting a user-triggered operation on a target web page, comparing and detecting the device identifiers stored in the multiple preset storage locations; and if multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, updating the device identifier stored in the second storage location based on the device identifier stored in the first storage location; upon detecting a user-triggered data access instruction, generating target verification information based on the device identifier stored in the preset storage locations, and sending a data access request carrying the target verification information to the server. The data access request triggers the server to perform device verification processing on the web client based on the target verification information, and if device verification is successful, processing the data access request.
[0009] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the following process: receiving a device identifier generated by a server based on device attribute information of a web client; storing the device identifier in multiple preset storage locations, including page tags, persistent cache, temporary cache, and RAM; upon detecting a user triggering an operation on a target web page, comparing and detecting the device identifiers stored in the multiple preset storage locations, and if multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, updating the device identifier stored in the second storage location based on the device identifier stored in the first storage location; upon detecting a data access instruction triggered by the user, generating target verification information based on the device identifier stored in the preset storage locations, and sending a data access request carrying the target verification information to the server, the data access request being used to trigger the server to perform device verification processing on the web client based on the target verification information, and processing the data access request if device verification is successful. Attached Figure Description
[0010] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 This is an embodiment of a data processing method described in this specification; Figure 2 This is a schematic diagram illustrating the module configuration of a web client and server in this specification. Figure 3 This is a schematic diagram of a data processing procedure described in this specification; Figure 4 This is yet another embodiment of the data processing method described in this specification; Figure 5 This is one embodiment of a data processing device described in this specification; Figure 6 This is an embodiment of a data processing device described in this specification. Detailed Implementation
[0011] This specification provides a data processing method, apparatus, and device through its embodiments.
[0012] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.
[0013] This specification provides a technical solution to improve the security of web data interaction. With the rapid development of network technology and the surge in internet users, web services have become the mainstream way to provide services. However, this trend is also accompanied by increasingly rampant network attacks, frequently disrupting normal network services and compromising the security of user privacy data. To ensure the data security of web services, web clients can interact with the server based on stored device identifiers. However, because web client data storage is easily affected by web page operations, data storage is unstable and cannot effectively guarantee the security of data interaction. Therefore, this specification provides a technical solution to improve the security of web data interaction. In this scheme, the web client can receive a device identifier generated by the server based on the web client's device attribute information and store the device identifier in multiple preset storage locations. These preset storage locations may include page tags, persistent cache, temporary cache, and RAM. When a user triggers an operation on the target web page, the device identifiers stored in the multiple preset storage locations can be compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the device identifier stored in the second storage location can be updated based on the device identifier stored in the first storage location. When a user triggers a data access command, target verification information is generated based on the device identifier stored in the preset storage locations, and a data access request carrying the target verification information is sent to the server. The data access request can be used to trigger the server to perform device verification processing on the web client based on the target verification information, and if the device verification is successful, the data access request is processed. In this way, the device identifier is stored in multiple different preset storage locations. When a user triggers an operation on the target web page, the device identifier stored in the second storage location can be updated according to the majority principle. This avoids situations where the device identifier stored in the preset storage locations is lost due to the user triggering the target web page operation, thus improving the stability of the device identifier. Furthermore, based on the target verification information generated by the device identifier, secure data transmission between the device identifier and the server can be achieved, thereby improving the security of web data interaction.
[0014] like Figure 1 As shown in the embodiments of this specification, a data processing method is provided. The execution subject of this method can be a terminal device, such as a mobile terminal device like a mobile phone or tablet computer, or a computer device like a laptop or desktop computer. The terminal device can be a web client capable of providing web services to users. Specifically, the method may include the following steps: In step S102, the device identifier generated by the receiving server based on the device attribute information of the web client is received.
[0015] The device attribute information may include the web client's user agent identifier (UserAgent), the approximate memory value of the device on which the web client is running (DeviceMemory), the array of Multipurpose Internet Mail Extensions (MIME) types registered in the web client (AcceptMimeType), the device type on which the web client is running (NavigatorPlatform), whether temporary caching (SessionStorage) is supported, whether persistent caching (LocalStorage) is supported, whether Indexed DB is supported, the Canvas ID (CanvasID), the error data obtained after performing an empty eval operation (EmptyEvalLength), the fonts supported by the web client (Fonts), and whether the web client has forged the set language (hasLiedLanguages), etc. The Canvas ID can be a value that is dynamically generated by the Canvas and converted into Base64 format.
[0016] In practice, the web client can send device attribute information to the server, and the server can generate a device identifier corresponding to the web client based on the web client's device attribute information.
[0017] For example, the server can generate a device identifier corresponding to the web client based on the web client's device attribute information, using a pre-trained identifier generation model. The identifier generation model can be a model built based on a preset machine learning algorithm.
[0018] Alternatively, the server can generate a hash value corresponding to the device attribute information based on a preset hash algorithm, and then use this hash value as the device identifier corresponding to the web client.
[0019] In addition, there are many other ways to generate device identifiers. Different generation methods can be selected according to different actual application scenarios. This specification does not limit the specific methods in this embodiment.
[0020] In addition, to ensure the uniqueness of the device identifier on the web client, the server can perform a uniqueness check on the generated device identifier locally. If an identifier with the same name as the generated device identifier already exists in the server's local storage module, the server can append a preset character (such as 0) to the generated device identifier and then perform a uniqueness check on the appended device identifier. If duplicate identifiers still exist, the server can add a preset character (such as 1) to the last character of the appended device identifier and then perform a uniqueness check. This process continues until the processed device identifier passes the uniqueness check. The server can then send the device identifier that has passed the uniqueness check to the web client.
[0021] In step S104, the device identifier is stored in multiple preset storage locations.
[0022] The preset storage locations can include page tags (html), persistent cache (LocalStorage), temporary cache (SessionStorage), and runtime memory (cookie).
[0023] In practice, to ensure the data security of the device identifier during transmission, the server can encrypt the device identifier and sign it before sending the encrypted device identifier and signature information to the web client.
[0024] The web client can decrypt the encrypted device identifier and verify the signature based on the signature information and the decrypted device identifier. After successful verification, it can be confirmed that the decrypted device identifier has not been tampered with during data transmission. Then, the web client can store the device identifier in the page tag (html), persistent cache (LocalStorage), temporary cache (SessionStorage), and runtime memory (cookie).
[0025] In step S106, when a user triggers an operation on the target web page, a comparison and detection process is performed on the device identifiers stored in multiple preset storage locations. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected among the multiple preset storage locations, the device identifier stored in the second storage location is updated according to the device identifier stored in the first storage location.
[0026] In implementation, since user-triggered web page operations may cause device identifiers stored in one or more preset storage locations to be cleared, there may be inconsistencies in the device identifiers stored in multiple preset storage locations. In this case, the preset storage location where the same device identifier is stored in multiple preset storage locations can be identified as the first storage location, and the other preset storage locations can be identified as the second storage location. Based on the device identifier stored in the first storage location, the device identifier stored in the second storage location can be updated to make the device identifier stored in the second storage location the same as the device identifier stored in the first storage location.
[0027] For example, when a user triggers action 1 on a target web page, the device identifier in the persistent cache (LocalStorage) corresponding to action 1 may be cleared. This results in inconsistencies in the device identifiers stored in multiple preset storage locations. In this case, the web client can determine the page tag (html), temporary cache (SessionStorage), and runtime memory (cookie) with the same device identifier as the first storage location, determine the persistent cache (LocalStorage) as the second storage location, and update the device identifier stored in the persistent cache (LocalStorage) according to the device identifier stored in the first storage location.
[0028] In addition, to prevent malicious third parties from tampering with the device identifiers stored in the preset storage locations, the web client can also compare and detect the device identifiers stored in multiple preset storage locations according to a preset detection period. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the client can update the device identifier stored in the second storage location according to the device identifier stored in the first storage location.
[0029] In step S108, when a user-triggered data access command is detected, target verification information is generated based on the device identifier stored in a preset storage location, and a data access request carrying the target verification information is sent to the server.
[0030] Among them, the data access request can be used to trigger the server to perform device verification processing on the web client based on the target verification information, and process the data access request if the device verification is successful.
[0031] In implementation, the web client can compare and detect the device identifiers stored in multiple preset storage locations again. If the device identifiers stored in multiple preset storage locations pass the comparison and detection, target verification information can be generated based on the device identifier stored in any storage location.
[0032] Furthermore, if the device identifier stored in multiple preset storage locations fails the comparison detection, the web client can generate target verification information based on the device identifiers stored in multiple storage locations with the same device identifier.
[0033] The web client can generate target verification information based on preset verification information generation algorithms (such as hash algorithms, preset encryption algorithms, machine learning algorithms, etc.), information corresponding to data access instructions (such as business identifiers, user identifiers, data information to be accessed, etc.) and device identifiers.
[0034] Web clients can send data access requests carrying device identifiers and target verification information to the server.
[0035] Thus, as Figure 2 As shown, the modules that the web client runs can include a collection module, a listening module, and a storage module. These three modules can provide support for the server. In the server environment, there must be at least one server to deploy the program and support the operation of the identifier generation module, storage module, and identification module.
[0036] The web client can collect device attribute information through the collection module. The web server can generate a unique device identifier corresponding to the web client based on the web client's device attribute information through the identifier generation module, and add the unique device identifier to the traffic packet. Simultaneously, the generated device identifier can be stored through the storage module and sent to the web client. The reported packet will contain the unique device identifier and target verification information (such as a token), which can be added to the header or cookie.
[0037] The web client's listening module can be used to obtain the device identifier sent by the server and store the device identifier through the storage module.
[0038] When the server receives a data access request from a web client, it can identify the target verification information and device identifier in the data access request through an identification model.
[0039] In addition, such as Figure 3As shown, when a web client user initiates an access request, the site resources are obtained to the local web client. After the resources are obtained, the program code automatically runs first to perform the collection action. After collecting the device attribute information, the data can be reported to the server through the API interface.
[0040] After receiving a request, the server-side program can generate a unique identifier (i.e., device identifier) based on the device attribute information. After storing the device identifier, it can then return the device identifier to the web client. After receiving the device identifier returned by the server, the web client can store the device identifier in a preset local storage location and listen for XHR and Fetch type requests through the listening module, adding device and target verification information to the request message.
[0041] If risky traffic occurs, the server can locate the risky device by using the device identifier in the traffic.
[0042] For example, taking the target verification information as a hash value generated by the web client for the device identifier according to a preset hash algorithm, the server can generate a corresponding hash value for the received device identifier according to the preset hash algorithm, and perform matching processing between the generated hash value and the received hash value. If the matching fails, it indicates that there is a risk in the data transmission process, and it can be determined that there is a risk in the data transmission process between the web client and the server corresponding to the device identifier.
[0043] This specification provides a data processing method. A web client can receive a device identifier generated by a server based on the web client's device attribute information and store the device identifier in multiple preset storage locations. These preset storage locations may include page tags, persistent cache, temporary cache, and RAM. When a user triggers an operation on a target web page, the device identifiers stored in the multiple preset storage locations can be compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the device identifier stored in the second storage location can be updated based on the device identifier stored in the first storage location. When a user triggers a data access command, target verification information is generated based on the device identifier stored in the preset storage locations, and a data access request carrying the target verification information is sent to the server. The data access request can be used to trigger the server to perform device verification processing on the web client based on the target verification information. If the device verification is successful, the data access request is processed. In this way, the device identifier is stored in multiple different preset storage locations. When a user triggers an operation on the target web page, the device identifier stored in the second storage location can be updated according to the majority principle. This avoids situations where the device identifier stored in the preset storage locations is lost due to the user triggering the target web page operation, thus improving the stability of the device identifier. Furthermore, based on the target verification information generated by the device identifier, secure data transmission between the device identifier and the server can be achieved, thereby improving the security of web data interaction.
[0044] In practical applications, operations on the target web page can include web page refresh, web page close, and web cache clearing.
[0045] In practical applications, the device identifier stored in a preset storage location can also be updated using the device identifier stored in the random access memory. One possible processing method is provided below, such as... Figure 4 As shown, the specific process may include the following steps, S202.
[0046] In S202, when a user triggers a web process termination command, the device identifier stored in the random access memory is obtained, and the device identifier stored in the preset storage location is updated based on the obtained device identifier.
[0047] Random Access Memory (RAM) can be an internal memory that directly exchanges data with the CPU. RAM can support reading and writing at any time and is very fast. It can usually be used as a temporary data storage medium for the operating system or other running programs.
[0048] In practice, the web client's listening module can also be used to listen for page unload behavior. The unload behavior will call a callback function when the web page is refreshed or closed. If the unload behavior exists, the web client can read the device identifier from RAM memory and store the read device identifier in multiple preset storage locations.
[0049] In practical applications, the specific processing method for generating target verification information based on the device identifier stored in the preset storage location in step S108 can vary. The following provides another optional processing method, such as... Figure 4 As shown, the specific process may include the following steps, S1082.
[0050] In step S1082, target verification information is generated based on the device identifier stored in the preset storage location and the timestamp of the data access instruction.
[0051] In practical applications, the device identifier can be obtained by the server concatenating multiple first results according to a preset hash algorithm. The first result can be the hash value generated by the server for each device attribute information.
[0052] In implementation, web clients can embed data collection code. When a user visits a target website with this embedded code, device attribute information can be collected. For example, the target website can integrate the code using HTML script tags, allowing the code to run and collect information when the website is accessed. After collecting the information, dynamic calculations can be performed to determine the web client's device attribute information. In other words, the web client can determine its device attribute information through both static data collection and dynamic calculations.
[0053] Static data collection includes: UserAgent can be obtained through the open API of Navigator functions, i.e., navigator.userAgent. DeviceMemory can be obtained through the open API of Navigator functions, i.e., navigator.DeviceMemory. AcceptMimeType can be obtained through the open API of Navigator functions, i.e., navigator.mimeTypes. NavigatorPlatform can be obtained through the open API of Navigator functions, i.e., navigator.platform.
[0054] Dynamic calculations can include: 1. SessionStorage: Checks if sessionStorage exists. If it does not exist, it returns false. If it exists, it stores and retrieves temporary data. It returns true if successful and true if unsuccessful. 2. LocalStorage: Checks if localStorage exists. If it does not exist, it returns false. If it exists, it stores and retrieves temporary data. It returns true if successful and true if unsuccessful. 3. Indexed DB: Check if an Indexed DB exists. If it does not exist, return false. If it exists, store and retrieve temporary data. Return true if successful, otherwise return true. 4. hasLiedLanguages: By analyzing the functions navigator.language and navigator.languages, if the first element in the navigator.languages array is not navigator.language, then it is true; otherwise, it is false. 5. EmptyEvalLength: This function attempts to retrieve the required data by accessing the `toString` method of `eval`. If this fails, it attempts to access the `toString` method in its prototype chain. If that also fails, it returns an empty string. 6. Fonts: By temporarily creating two span tags and assigning temporary text to them, one span is set to a standard font and the other to a non-standard font. After rendering, it is determined whether the rendered widths of the two span tags are the same. If they are the same, it means that the current web client supports this non-standard font; otherwise, it does not support it. 7. CanvasID: Create a canvas object, use the canvas to draw a prototype with a width of 250px and a height of 80px, and fill it with a fixed string of characters "glyphs". After rendering, use the toDataURL method to get the string converted to Base64 format.
[0055] Then, the web client can transmit the device attribute information to the server for the first time through the network communication interface. The network communication between the web client and the server can be carried out using the HTTP protocol, and the parameters carried can be the device attribute information.
[0056] After receiving the device attribute information transmitted by the web client for the first time, the server can preprocess all the device attribute information. This preprocessing can include: The UserAgent is truncated, for example, by extracting the first 20 characters; DeviceMemory is processed from a floating-point type to a string type; AcceptMimeType is processed from an array type to a string type; SessionStorage is processed from a boolean type to a string type; LocalStorage is processed from a boolean type to a string type; Indexed DB is processed from a boolean type to a string type; Fonts is processed from an array type to a string type; and hasLiedLanguages is processed from a boolean type to a string type.
[0057] After preprocessing, the server can concatenate the processed information into strings, perform a hash calculation on the concatenated strings to obtain a unique identifier (i.e., device identifier). Alternatively, the server's identifier generation module can calculate the hash value for each device attribute information to obtain a first result, concatenate multiple first results, and use the murmur3 algorithm to calculate the hash value as the device identifier. This is then stored through the storage module. During storage, the uniqueness of the identifier is verified. If a duplicate device identifier already exists, the server can pad the newly generated unique identifier before storing it. If duplicates still exist, padding will continue until no duplicates exist, and a new unique identifier will be returned as the device identifier.
[0058] After the server completes the calculation, it can perform symmetric encryption on the string obtained by concatenating the device identifier and timestamp, and store the encrypted value as a token in the database. Then, it returns the device identifier and token to the web client. The server can store the device identifier in persistent memory using a key-value pair.
[0059] After receiving the device identifier and token, the web client can encrypt the device identifier and store it in a local persistent cache, while the token can be stored in a local temporary cache.
[0060] To ensure the security and stability of storage, web clients can store device identifiers in multiple preset storage locations, namely page tags, persistent cache, temporary cache, and running memory.
[0061] After storage is completed, the web client can recalculate the information once according to the preset detection period (such as every 1 second). By combining and comparing the device identifiers stored in the four preset storage locations, if the device identifier stored in one of the storage locations is inconsistent with the device identifiers stored in the other three storage locations, the web client can update the total number of device identifiers stored in the second storage location according to the majority principle, based on the consistent device identifier stored in the first storage location.
[0062] In subsequent normal network access requests, the web client can add a device identifier to the traffic, as well as target verification information (i.e., a token) generated based on the device identifier and the timestamp of the data access instruction.
[0063] After receiving a data access request, the server's identification module analyzes the unique device identifier and token in the request and maps and stores them. When the API security platform detects an anomaly in the interface request, it can locate the at-risk device using the device identifier.
[0064] In practical applications, the device identifier stored in the second storage location (excluding the running memory) can also be updated based on the device identifier stored in the running memory. One possible processing method is provided below. Figure 4 As shown, the process may specifically include the following steps, S204.
[0065] In step S204, if the device identifier stored in the first storage location is empty and the second storage location includes the running memory, the device identifier stored in the storage locations other than the running memory in the second storage location is updated according to the device identifier stored in the running memory.
[0066] In practice, if two storage locations store different device identifiers, the value in the storage location that is different from the value stored in the running memory can be updated to the same value as the value stored in the running memory, according to the principle of running memory priority.
[0067] In this way, a unique device identifier can be generated through the server-side identifier generation module. The device identifier stored through the web client's storage module significantly improves its stability when reused. This ensures identifier stability even after operations such as closing the page, refreshing the page, or clearing the cache. Through two-way verification of the unique identifier and the token identifier, in scenarios where the device identifier has been replaced, the true device identifier can be traced back through the token identifier, thereby locating the risky device.
[0068] This specification provides a data processing method. A web client can receive a device identifier generated by a server based on the web client's device attribute information and store the device identifier in multiple preset storage locations. These preset storage locations may include page tags, persistent cache, temporary cache, and RAM. When a user triggers an operation on a target web page, the device identifiers stored in the multiple preset storage locations can be compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the device identifier stored in the second storage location can be updated based on the device identifier stored in the first storage location. When a user triggers a data access command, target verification information is generated based on the device identifier stored in the preset storage locations, and a data access request carrying the target verification information is sent to the server. The data access request can be used to trigger the server to perform device verification processing on the web client based on the target verification information. If the device verification is successful, the data access request is processed. In this way, the device identifier is stored in multiple different preset storage locations. When a user triggers an operation on the target web page, the device identifier stored in the second storage location can be updated according to the majority principle. This avoids situations where the device identifier stored in the preset storage locations is lost due to the user triggering the target web page operation, thus improving the stability of the device identifier. Furthermore, based on the target verification information generated by the device identifier, secure data transmission between the device identifier and the server can be achieved, thereby improving the security of web data interaction.
[0069] The above describes the data processing method provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a data processing device, such as... Figure 5 As shown.
[0070] The data processing device includes: an identifier receiving module 501, an identifier storage module 502, a comparison and detection module 503, and a request sending module 504, wherein: The identifier receiving module 501 is used to receive a device identifier generated by the server based on the device attribute information of the data processing device. The identifier storage module 502 is used to store the device identifier in multiple preset storage locations, including page tags, persistent cache, temporary cache and running memory; The comparison detection module 503 is used to perform comparison detection processing on the device identifiers stored in the plurality of preset storage locations when a user triggers an operation on the target web page, and when it is detected that there are multiple first storage locations with the same device identifier and a second storage location with a different device identifier than the first storage location, the module updates the device identifier stored in the second storage location according to the device identifier stored in the first storage location. The request sending module 504 is used to generate target verification information based on the device identifier stored in the preset storage location when a data access instruction triggered by the user is detected, and send a data access request carrying the target verification information to the server. The data access request is used to trigger the server to perform device verification processing on the data processing device based on the target verification information, and to process the data access request if the device verification is successful.
[0071] In the embodiments described in this specification, the target web page operations include web page refresh operations, web page close operations, and web cache clearing operations.
[0072] In the embodiments described in this specification, the device further includes: The first update module is used to, upon detecting that the user has triggered a web process termination command, obtain the device identifier stored in the random access memory, and update the device identifier stored in the preset storage location according to the obtained device identifier.
[0073] In this embodiment of the specification, the request sending module 504 is used for: The target verification information is generated based on the device identifier stored in the preset storage location and the timestamp of the data access instruction.
[0074] In this embodiment of the specification, the device identifier is obtained by the server processing the result of concatenating multiple first results according to the preset hash algorithm, where the first result is the hash value generated by the server for each device attribute information.
[0075] In the embodiments described in this specification, the device further includes: The second update module is used to update the device identifier stored in the storage location other than the running memory in the second storage location, based on the device identifier stored in the running memory, when the device identifier stored in the first storage location is empty and the second storage location includes the running memory.
[0076] This specification provides a data processing apparatus in its embodiments. A web client can receive a device identifier generated by a server based on the web client's device attribute information and store the device identifier in multiple preset storage locations. These preset storage locations may include page tags, persistent cache, temporary cache, and RAM. When a user triggers an operation on a target web page, the device identifiers stored in the multiple preset storage locations can be compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the device identifier stored in the second storage location can be updated based on the device identifier stored in the first storage location. When a user triggers a data access command, target verification information is generated based on the device identifier stored in the preset storage locations, and a data access request carrying the target verification information is sent to the server. The data access request can be used to trigger the server to perform device verification processing on the web client based on the target verification information, and if the device verification is successful, the data access request is processed. In this way, the device identifier is stored in multiple different preset storage locations. When a user triggers an operation on the target web page, the device identifier stored in the second storage location can be updated according to the majority principle. This avoids situations where the device identifier stored in the preset storage locations is lost due to the user triggering the target web page operation, thus improving the stability of the device identifier. Furthermore, based on the target verification information generated by the device identifier, secure data transmission between the device identifier and the server can be achieved, thereby improving the security of web data interaction.
[0077] The above are the data processing apparatuses provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a data processing device, such as... Figure 6 As shown.
[0078] The data processing device can provide terminal equipment or servers, etc., for the above embodiments.
[0079] Data processing devices can vary considerably depending on their configuration or performance. They may include one or more processors 601 and memory 602, with memory 602 storing one or more application programs or data. Memory 602 can be temporary or persistent storage. The application programs stored in memory 602 may include one or more modules (not shown), each module including a series of computer-executable instructions for the data processing device. Furthermore, processor 601 may be configured to communicate with memory 602 and execute the series of computer-executable instructions stored in memory 602 on the data processing device. The data processing device may also include one or more power supplies 603, one or more wired or wireless network interfaces 604, one or more input / output interfaces 605, and one or more keyboards 606.
[0080] Specifically, in this embodiment, the data processing device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the data processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: The receiving server generates a device identifier based on the device attribute information of the web client; The device identifier is stored in multiple preset storage locations, including page tabs, persistent cache, temporary cache, and running memory. When a user triggers an operation on the target web page, the device identifiers stored in the multiple preset storage locations are compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected among the multiple preset storage locations, the device identifier stored in the second storage location is updated according to the device identifier stored in the first storage location. Upon detecting a data access command triggered by the user, target verification information is generated based on the device identifier stored in the preset storage location, and a data access request carrying the target verification information is sent to the server. The data access request is used to trigger the server to perform device verification processing on the web client based on the target verification information, and if the device verification is successful, the data access request is processed.
[0081] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the data processing device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0082] This specification provides a data processing device. A web client can receive a device identifier generated by a server based on the web client's device attribute information and store the device identifier in multiple preset storage locations. These preset storage locations may include page tags, persistent cache, temporary cache, and RAM. When a user triggers an operation on a target web page, the device identifiers stored in the multiple preset storage locations can be compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the device identifier stored in the second storage location can be updated based on the device identifier stored in the first storage location. When a user triggers a data access command, target verification information is generated based on the device identifier stored in the preset storage locations, and a data access request carrying the target verification information is sent to the server. The data access request can be used to trigger the server to perform device verification processing on the web client based on the target verification information, and if the device verification is successful, the data access request is processed. In this way, the device identifier is stored in multiple different preset storage locations. When a user triggers an operation on the target web page, the device identifier stored in the second storage location can be updated according to the majority principle. This avoids situations where the device identifier stored in the preset storage locations is lost due to the user triggering the target web page operation, thus improving the stability of the device identifier. Furthermore, based on the target verification information generated by the device identifier, secure data transmission between the device identifier and the server can be achieved, thereby improving the security of web data interaction.
[0083] Furthermore, based on the above Figures 1 to 4 The method shown in this specification, along with one or more embodiments, also provides a storage medium for storing computer-executable instruction information. In one specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, it can achieve the following process: The receiving server generates a device identifier based on the device attribute information of the web client; The device identifier is stored in multiple preset storage locations, including page tabs, persistent cache, temporary cache, and running memory. When a user triggers an operation on the target web page, the device identifiers stored in the multiple preset storage locations are compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected among the multiple preset storage locations, the device identifier stored in the second storage location is updated according to the device identifier stored in the first storage location. Upon detecting a data access command triggered by the user, target verification information is generated based on the device identifier stored in the preset storage location, and a data access request carrying the target verification information is sent to the server. The data access request is used to trigger the server to perform device verification processing on the web client based on the target verification information, and if the device verification is successful, the data access request is processed.
[0084] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described storage medium embodiment is basically similar to the method embodiment, so the description is relatively simple; relevant parts can be referred to the description of the method embodiment.
[0085] This specification provides a storage medium in which a web client can receive a device identifier generated by a server based on the web client's device attribute information and store the device identifier in multiple preset storage locations. These preset storage locations may include page tags, persistent cache, temporary cache, and RAM. When a user triggers an operation on a target web page, the device identifiers stored in the multiple preset storage locations can be compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the device identifier stored in the second storage location can be updated based on the device identifier stored in the first storage location. When a user triggers a data access command, target verification information is generated based on the device identifier stored in the preset storage locations, and a data access request carrying the target verification information is sent to the server. The data access request can trigger the server to perform device verification processing on the web client based on the target verification information, and if device verification is successful, the data access request is processed. In this way, the device identifier is stored in multiple different preset storage locations. When a user triggers an operation on the target web page, the device identifier stored in the second storage location can be updated according to the majority principle. This avoids situations where the device identifier stored in the preset storage locations is lost due to the user triggering the target web page operation, thus improving the stability of the device identifier. Furthermore, based on the target verification information generated by the device identifier, secure data transmission between the device identifier and the server can be achieved, thereby improving the security of web data interaction.
[0086] Furthermore, based on the above Figures 1 to 4 The method shown in this specification, along with one or more embodiments, also provides a computer program product including a computer program that, when executed by a processor, performs the following process: The receiving server generates a device identifier based on the device attribute information of the web client; The device identifier is stored in multiple preset storage locations, including page tabs, persistent cache, temporary cache, and running memory. When a user triggers an operation on the target web page, the device identifiers stored in the multiple preset storage locations are compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected among the multiple preset storage locations, the device identifier stored in the second storage location is updated according to the device identifier stored in the first storage location. Upon detecting a data access command triggered by the user, target verification information is generated based on the device identifier stored in the preset storage location, and a data access request carrying the target verification information is sent to the server. The data access request is used to trigger the server to perform device verification processing on the web client based on the target verification information, and if the device verification is successful, the data access request is processed.
[0087] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described embodiment of a computer program product is relatively simple in description because it is fundamentally similar to the method embodiment; relevant parts can be referred to the description of the method embodiment.
[0088] This specification provides a computer program product in which a web client can receive a device identifier generated by a server based on the web client's device attribute information and store the device identifier in multiple preset storage locations. These preset storage locations may include page tags, persistent cache, temporary cache, and RAM. Upon detecting a user-triggered web page operation, the web client can compare and detect the device identifiers stored in the multiple preset storage locations. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected, the web client can update the device identifier stored in the second storage location based on the device identifier stored in the first storage location. Upon detecting a user-triggered data access command, the web client generates target verification information based on the device identifier stored in the preset storage locations and sends a data access request carrying the target verification information to the server. The data access request can trigger the server to perform device verification processing on the web client based on the target verification information, and if device verification is successful, the server processes the data access request. In this way, the device identifier is stored in multiple different preset storage locations. When a user triggers an operation on the target web page, the device identifier stored in the second storage location can be updated according to the majority principle. This avoids situations where the device identifier stored in the preset storage locations is lost due to the user triggering the target web page operation, thus improving the stability of the device identifier. Furthermore, based on the target verification information generated by the device identifier, secure data transmission between the device identifier and the server can be achieved, thereby improving the security of web data interaction.
[0089] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.
[0090] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.
[0091] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.
[0092] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.
[0093] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.
[0094] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0095] Embodiments in this specification are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable parallel device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable parallel device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0096] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable fraud device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0097] These computer program instructions can also be loaded onto a computer or other programmable device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0098] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0099] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0100] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0101] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0102] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0103] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0104] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.
[0105] The above description is merely an embodiment of this specification and is not intended to limit this document. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.
Claims
1. A data processing method, the method being applied to a web client, the method comprising: The receiving server generates a device identifier based on the device attribute information of the web client; The device identifier is stored in multiple preset storage locations, including page tabs, persistent cache, temporary cache, and running memory. When a user triggers an operation on the target web page, the device identifiers stored in the multiple preset storage locations are compared and detected. If multiple first storage locations with the same device identifier and a second storage location with a different device identifier are detected among the multiple preset storage locations, the device identifier stored in the second storage location is updated according to the device identifier stored in the first storage location. Upon detecting a data access command triggered by the user, target verification information is generated based on the device identifier stored in the preset storage location, and a data access request carrying the target verification information is sent to the server. The data access request is used to trigger the server to perform device verification processing on the web client based on the target verification information, and if the device verification is successful, the data access request is processed.
2. The method according to claim 1, wherein the target web page operation includes a web page refresh operation, a web page close operation, and a web cache clearing operation.
3. The method according to claim 1, further comprising: Upon detecting that the user has triggered a web process termination command, the device identifier stored in the random access memory is obtained, and the device identifier stored in the preset storage location is updated based on the obtained device identifier.
4. The method according to claim 1, wherein generating target verification information based on the device identifier stored in the preset storage location includes: The target verification information is generated based on the device identifier stored in the preset storage location and the timestamp of the data access instruction.
5. The method according to claim 1, wherein the device identifier is obtained by the server processing the result of concatenating multiple first results according to the preset hash algorithm, and the first result is the hash value generated by the server for each device attribute information.
6. The method according to claim 1, further comprising: If the device identifier stored in the first storage location is empty and the second storage location includes the running memory, the device identifier stored in the storage locations other than the running memory in the second storage location is updated according to the device identifier stored in the running memory.
7. A data processing apparatus, the apparatus comprising: The identifier receiving module is used to receive a device identifier generated by the server based on the device attribute information of the data processing device. An identifier storage module is used to store the device identifier in multiple preset storage locations, including page tags, persistent cache, temporary cache, and running memory. The comparison detection module is used to perform comparison detection processing on the device identifiers stored in the multiple preset storage locations when a user triggers an operation on the target web page; and when it is detected that there are multiple first storage locations with the same device identifier and a second storage location with a different device identifier than the first storage location, the module updates the device identifier stored in the second storage location according to the device identifier stored in the first storage location. The request sending module is used to generate target verification information based on the device identifier stored in the preset storage location when a data access instruction triggered by the user is detected, and send a data access request carrying the target verification information to the server. The data access request is used to trigger the server to perform device verification processing on the data processing device based on the target verification information, and to process the data access request if the device verification is successful.
8. A data processing device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the data processing method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the data processing method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the steps of the data processing method according to any one of claims 1 to 6.