Node interaction method and system for a hierarchical tree

Abstract

This disclosure relates to a method and system for node interaction in a hierarchical structure tree. The method is applied to a terminal and includes: receiving an interaction operation for a target node in the hierarchical structure tree; determining whether the interaction operation is allowed to execute based on the terminal's effective interaction permission information to obtain a first determination result; if the first determination result indicates that the interaction operation is allowed to execute, responding to the interaction operation, and sending a confirmation request to a server for the server to determine whether the interaction operation is allowed to execute; wherein the server generates response information for the confirmation request based on its effective interaction permission information; receiving the response information sent by the server; and determining whether to execute the interaction operation based on the response information. This ensures the matching between the terminal's interaction operation on a node and the currently effective interaction permissions, improving the timeliness of the interaction operation response.

Description

Technical Field

[0001] This disclosure relates to the fields of mobile internet software engineering and information security technology, and more specifically, to a node interaction method and system for a hierarchical structure tree. Background Technology

[0002] In enterprise mobile application technologies, hierarchical tree structures (such as department trees, organization trees, and personnel trees) are often used for filtering and selection (e.g., selecting organizations, departments, personnel, virtual organizational units, etc.). Existing implementations typically adopt the following pattern: 1) The server authenticates the interface based on permission models such as RBAC (Role-Based Access Control) / ABAC (Attribute-Based Access Control) and filters the returned data. 2) The client side mainly handles presentation layer rendering and interactive event processing. Whether a node can be displayed or interacted with depends on local rules or coarse-grained fields returned by the server (e.g., only visible nodes are returned, or only optional nodes are returned).

[0003] However, in the above scheme, the terminal's interactive operations on the node do not match the currently effective interactive permissions, or the response to the interactive operations lacks timeliness. Summary of the Invention

[0004] The main purpose of this disclosure is to provide a node interaction method and system for a hierarchical structure tree to solve the technical problems of mismatch between the terminal's interaction operation on the node and the currently effective interaction permission, or the lack of timeliness in the response of the interaction operation. It achieves the technical effects of improving the matching between the terminal's interaction operation on the node and the currently effective interaction permission, as well as improving the timeliness of the response of the interaction operation.

[0005] To achieve the above objectives, a first aspect of this disclosure proposes a node interaction method for a hierarchical structure tree, which is applied to a terminal and includes: Receive interactive operations for target nodes in the hierarchical structure tree; Based on the interaction permission information enabled on the terminal, determine whether the interaction operation is allowed to be executed, so as to obtain the first determination result; If the first determination result indicates that the interactive operation is allowed to be executed, the system responds to the interactive operation and sends a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein, the server generates the response information of the confirmation request based on the interactive permission information that is effective on the server. Receive response information sent by the server; The decision to perform an interactive action is based on the response information.

[0006] In some possible implementations, the confirmation request includes first version information of the interaction permission information that has been activated on the terminal; and Before receiving the response information sent by the server, the method also includes: If the version represented by the first version information is different from the version represented by the second version information, the interaction permission information corresponding to the second version information sent by the receiving server is the incremental interaction permission information relative to the interaction permission information corresponding to the first version information, wherein the second version information represents the version of the interaction permission information that is effective on the server. Based on the incremental interaction permission information, update the interaction permission information that is effective on the terminal to obtain the updated interaction permission information; Based on the updated interaction permission information, determine whether the interaction operation is allowed to be executed, so as to obtain the updated first determination result; If the updated first confirmation result indicates that the interactive operation can be executed, send an updated confirmation request to the server.

[0007] In some possible implementations, determining whether to perform an interactive operation based on the response information includes: If the response message indicates that execution is permitted, then continue to respond to interactive operations in order to execute the interactive operations; If the response indicates that execution is not allowed, then the already responded interactive operation will be canceled.

[0008] In some possible implementations, the confirmation request includes a request identifier generated by the terminal; The response information is generated in the following way: If the confirmation request indicated by the request identifier has already been processed by the server, a response is generated based on the historical processing results of the confirmation request; and Cancel responded interactive actions, including: Cancel the already responded interactive operation based on the request identifier.

[0009] In some possible implementations, the method further includes: Within the trusted execution environment of the terminal, a key for the terminal is generated based on the terminal's device identifier and a non-derivative random seed value. The terminal's active permission information is encrypted using a key to obtain encrypted data. Storing encrypted data; and Before determining whether an interactive operation is allowed to be executed based on the interactive permission information enabled on the terminal, the method further includes: Within a trusted execution environment, encrypted data is decrypted using a key to obtain the terminal's effective interaction permission information.

[0010] Secondly, embodiments of this disclosure provide a node interaction device for a hierarchical structure tree, which is applied to a terminal and includes: The first receiving unit is configured to receive interactive operations for target nodes in the hierarchical structure tree. The first determining unit is configured to: determine whether the interactive operation is allowed to be executed based on the interactive permission information effective on the terminal, so as to obtain the first determining result; The first sending unit is configured to: if the first determination result indicates that the interactive operation is allowed to be executed, respond to the interactive operation and send a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein the server generates response information for the confirmation request based on the interactive permission information effective on the server. The second receiving unit is configured to receive response information sent by the server. The second determining unit is configured to determine whether to perform an interactive operation based on the response information.

[0011] In some possible implementations, the confirmation request includes first version information of the interaction permission information that has been activated on the terminal; and The device also includes: The third receiving unit is configured to: if the version represented by the first version information is different from the version represented by the second version information, receive the incremental interactive permission information corresponding to the second version information sent by the server relative to the interactive permission information corresponding to the first version information, wherein the second version information represents the version of the interactive permission information that is effective on the server. The update unit is configured to update the terminal's active interaction permission information based on incremental interaction permission information, and obtain the updated interaction permission information. The third determining unit is configured to: determine whether the interactive operation is allowed to be executed based on the updated interactive permission information, so as to obtain the updated first determining result; The second sending unit is configured to send an updated confirmation request to the server if the updated first confirmation result indicates that the interactive operation is allowed to be executed.

[0012] In some possible implementations, determining whether to perform an interactive operation based on the response information includes: If the response message indicates that execution is permitted, then continue to respond to interactive operations in order to execute the interactive operations; If the response indicates that execution is not allowed, then the already responded interactive operation will be canceled.

[0013] In some possible implementations, the confirmation request includes a request identifier generated by the terminal; The response information is generated in the following way: If the confirmation request indicated by the request identifier has already been processed by the server, a response is generated based on the historical processing results of the confirmation request; and Cancel responded interactive actions, including: Cancel the already responded interactive operation based on the request identifier.

[0014] In some possible implementations, the device further includes: The generation unit is configured to generate a terminal key based on the terminal's device identifier and a non-derivative random seed value within the terminal's trusted execution environment. The encryption unit is configured to encrypt the interactive permission information that is effective on the terminal using a key to obtain encrypted data. The storage unit is configured to: store encrypted data; and The decryption unit is configured to: decrypt encrypted data using a key within a trusted execution environment to obtain the terminal's effective interaction permission information.

[0015] Thirdly, embodiments of this disclosure provide a node interaction system for a hierarchical structure tree, the system comprising a terminal and a server, wherein: The terminal is configured to: receive interactive operations for target nodes in the hierarchical structure tree; determine whether the interactive operation is allowed to be executed based on the interactive permission information effective on the terminal, so as to obtain a first determination result; if the first determination result indicates that the interactive operation is allowed to be executed, respond to the interactive operation, and send a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed. The server is configured to generate a response to the confirmation request based on the interaction permission information that has been activated on the server. The terminal is also configured to: receive response information sent by the server; and determine whether to perform an interactive operation based on the response information.

[0016] In some possible implementations, the confirmation request includes first version information of the interaction permission information that has been activated on the terminal; and The terminal is also configured as follows: If the version represented by the first version information is different from the version represented by the second version information, the interaction permission information corresponding to the second version information sent by the receiving server is the incremental interaction permission information relative to the interaction permission information corresponding to the first version information, wherein the second version information represents the version of the interaction permission information that is effective on the server. Based on the incremental interaction permission information, update the interaction permission information that is effective on the terminal to obtain the updated interaction permission information; Based on the updated interaction permission information, determine whether the interaction operation is allowed to be executed, so as to obtain the updated first determination result; If the updated first confirmation result indicates that the interactive operation can be executed, send an updated confirmation request to the server.

[0017] In some possible implementations, the terminal is specifically configured as follows: If the response message indicates that execution is permitted, then continue to respond to interactive operations in order to execute the interactive operations; If the response indicates that execution is not allowed, then the already responded interactive operation will be canceled.

[0018] In some possible implementations, the confirmation request includes a request identifier generated by the terminal; The response information is generated in the following way: If the confirmation request indicated by the request identifier has already been processed by the server, a response is generated based on the historical processing results of the confirmation request; and The terminal is specifically configured as follows: Cancel the already responded interactive operation based on the request identifier.

[0019] In some possible implementations, the terminal is also configured to: Within the trusted execution environment of the terminal, a key for the terminal is generated based on the terminal's device identifier and a non-derivative random seed value. The terminal's active permission information is encrypted using a key to obtain encrypted data. Store encrypted data; Within a trusted execution environment, encrypted data is decrypted using a key to obtain the terminal's effective interaction permission information.

[0020] Fourthly, embodiments of this disclosure provide an electronic device, including: Memory, used to store computer programs; A processor is configured to execute a computer program stored in the memory, wherein, when the computer program is executed, it implements any embodiment of the node interaction method of the hierarchical structure tree of the first aspect of this disclosure.

[0021] Fifthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any embodiment of the node interaction method of the hierarchical structure tree as described in the first aspect above.

[0022] In a sixth aspect, embodiments of this disclosure provide a computer program product including computer-readable code, which, when executed by a processor, implements the method of any embodiment of the node interaction method of the hierarchical structure tree of the first aspect described above.

[0023] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects: In this disclosure, a dual-channel verification system is implemented for interactive operations by determining whether an interactive operation is allowed based on the terminal and server's respective effective interaction permission information. This ensures the compatibility of the terminal's interactive operation with its currently effective interaction permissions. Once the terminal determines that the interactive operation is allowed based on its effective interaction permission information, it immediately begins responding to the interactive operation without waiting for the verification result from the server. This enables instantaneous response, avoids UI blocking, and thus improves the timeliness of interactive operation responses. Attached Figure Description

[0024] The accompanying drawings, which form part of this disclosure, are used to provide a further understanding of the disclosure and to make other features, objects, and advantages of the disclosure more apparent. The illustrative embodiments of the disclosure, along with their descriptions, are used to explain the disclosure and do not constitute an undue limitation thereof. In the drawings: Figure 1 A flowchart illustrating a node interaction method for a hierarchical structure tree provided in this embodiment of the disclosure; Figure 2 A flowchart of another method for node interaction in a hierarchical structure tree provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of the structure of a node interaction device for a hierarchical structure tree provided in an embodiment of the present disclosure; Figure 4 This is a schematic diagram of a node interaction system of a hierarchical structure tree provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

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

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

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

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

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

[0030] Figure 1 This is a flowchart illustrating a node interaction method for a hierarchical structure tree provided in an embodiment of this disclosure. This method can be applied to terminals such as smartphones, laptops, desktop computers, and portable computers.

[0031] like Figure 1 As shown, the method specifically includes: Step 101: Receive interactive operations for the target node in the hierarchical structure tree.

[0032] In this embodiment, a hierarchical structure tree represents a data set with hierarchical relationships. For example, a hierarchical structure tree can be used to organize and display node data with parent-child relationships, such as an enterprise organizational structure. A hierarchical structure tree can include multiple nodes (e.g., target nodes), each node having a unique node identifier (NodeID) and a path from the root node to that node. Nodes can represent organizational units such as departments, institutions, personnel, and virtual organizational units.

[0033] The target node can be a node in the hierarchical structure tree that is manipulated by objects such as users.

[0034] Interactive operations can be actions performed by users or other objects on nodes, such as clicking, selecting, expanding, searching, and submitting.

[0035] In some alternative implementations, the terminal can capture and receive interactive operations on target nodes in the hierarchical structure tree through an event listening mechanism.

[0036] Step 102: Based on the interaction permission information enabled on the terminal, determine whether the interaction operation is allowed to be executed, so as to obtain the first determination result.

[0037] Interaction permission information can represent the interaction permissions and interaction status for a target node. In some optional implementations, interaction permission information can include permission mask information and interaction policy information. The permission mask information includes first information and second information; the first information represents the visible / hidden state of the target node in the tree data, and the second information represents the interactive display state of the target node; the interaction policy information represents the interaction permissions of the target node. The permission mask information is used to uniformly control the visibility and interaction of nodes (including target nodes), avoiding inconsistencies between display and interaction. The interaction policy information can describe the interaction permissions of nodes (including target nodes), such as whether interactive behavior is allowed or not.

[0038] Here, the interaction strategy information and the permission mask information work together to determine whether a node is interactive, preventing interface bypass.

[0039] In some optional implementations, the permission mask information can be a dictionary structure or a JSON (JavaScript Object Notation) structure. For example, the permission mask information can be defined as a dictionary structure M={v,d,p,l}, where v represents the visibility bit, d represents the disable bit, p represents the placeholder bit, and l represents the lazy loading bit. Each node (including the target node) maintains the ID (identity), version information, and mask bits (i.e., the values ​​of v, d, p, and l) of the permission mask information. The values ​​of v, d, p, and l can be binary bits, such as 0 or 1.

[0040] The first determination result indicates the result determined by the terminal, representing the decision on whether the interactive operation is allowed to be executed.

[0041] In some alternative implementations, the terminal can determine whether the interactive operation is allowed to be executed based on the interaction permission information that is effective locally on the terminal (e.g., stored) to obtain a first determination result.

[0042] Step 103: If the first determination result indicates that the interactive operation is allowed to be executed, respond to the interactive operation and send a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein, the server generates the response information of the confirmation request based on the interactive permission information effective on the server.

[0043] In this embodiment, after the server receives the confirmation request, the server can further determine whether the interactive operation is allowed to be executed based on the interaction permission information that is effective locally on the server (e.g., stored).

[0044] In some optional implementations, the server can also be used to generate and send permission mask information, interaction policy information, and tree data to the terminal to ensure consistency of access control. As an example, the server could be an enterprise application access control backend.

[0045] A confirmation request indicates that the server is requesting confirmation of whether the interactive operation is allowed to be executed.

[0046] The response information can indicate the server's processing result of the confirmation request. As an example, the response information can include the operation permission status (e.g., operation allowed, operation not allowed, timeout, etc.).

[0047] In some alternative implementations, if the first determination result indicates that the interactive operation is allowed to be executed, the terminal can respond to the interactive operation, and the terminal can send a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed.

[0048] In some optional implementations, the confirmation request may include version information of the request identifier and interaction permission information. The request identifier can be used by the server or terminal to trace the processing of the corresponding confirmation request. The version information can be used to determine the effective interaction permission information on the terminal.

[0049] Step 104: Receive the response information sent by the server.

[0050] In this embodiment, after the server generates the response information, it can send the response information to the terminal. Thus, the terminal can receive the response information sent by the server.

[0051] Step 105: Determine whether to perform an interactive operation based on the response information.

[0052] In this embodiment, if the response information indicates that the operation is allowed, the terminal can perform the interactive operation; if the response information indicates that the operation is not allowed, the terminal can interrupt or refuse to perform the interactive operation.

[0053] In some optional implementations of this embodiment, the following method can be used to determine whether to perform an interactive operation based on the response information: The first step is to respond to the interactive operation if the response message indicates that execution is allowed, and then continue to execute the interactive operation.

[0054] Here, if the response indicates that execution is permitted, the terminal can submit UI (User Interface) changes to continue responding to interactive operations. Furthermore, responding to interactive operations can serve as a pre-processing step before executing those operations.

[0055] The second step is to cancel the interactive operation if the response message indicates that execution is not allowed.

[0056] Here, if the response indicates that execution is not allowed, the terminal can perform a UI transaction rollback (e.g., rollbackUI(reqId)) to undo the responded interactive operation. As an example, the terminal can roll back interactive operations such as selection, expansion, and submission caused by the interaction based on the request identifier in the confirmation request, restoring the state before the interactive operation was responded to.

[0057] It is understandable that by canceling the responded interactive operation, it is possible to ensure that the interface and server permission baseline converge in real time (i.e., whether the terminal performs an interactive operation matches the interactive permission information that is effective on the server). When the server confirms that the operation has failed (execution is not allowed), the terminal cancels the responded interactive operation, rolls back the interface changes caused by the interaction, and restores the state before the response interactive operation. In this way, it is possible to ensure the matching of the terminal's interactive operation on the node with the currently effective interactive permissions.

[0058] In some optional implementations, if the response message indicates that execution is not allowed, the terminal can update the locally effective interaction permission information based on the response message. Thus, by updating the interaction permission information, the interface displays "cannot continue / only visible as a placeholder," thereby blocking the current and subsequent interaction operations targeting the target node.

[0059] In some application scenarios of the above-mentioned optional implementation methods, the confirmation request includes a request identifier generated by the terminal.

[0060] The request identifier can be used for server-side deduplication, authorization confirmation, and audit tracing.

[0061] Deduplication and authorization verification refer to the server constructing an idempotent key using a request identifier combined with a session identifier or user identifier. This enables unified processing for identifying duplicate requests and finalizing permissions. Specifically, the server receives a confirmation request from the terminal and extracts the request identifier generated by the terminal. The server combines the request identifier with the session identifier (SessionID) or user identifier (UserID) to construct a unique idempotent key. The server queries the processing record corresponding to this idempotent key: if a historical processing record is found (indicating that the confirmation request has been processed by the server), the server directly reads the historical processing result (including the judgment result and judgment reason) and generates response information based on the historical processing result; if no historical processing record is found, the server performs permission verification on the interactive operation in the confirmation request based on the interaction permission information effective on the server, generates a new processing result, associates and stores this processing result with the idempotent key, and generates response information based on this processing result. Through this operation, the server can ensure that the same business operation (uniquely identified by the request identifier) ​​only takes effect once in scenarios such as retries and network retransmissions, avoiding duplicate verification and inconsistent states.

[0062] Audit traceability refers to the server-side's solidification of key information throughout the entire confirmation request processing chain into structured audit events, supporting post-event reproduction and verification. Specifically, during the generation of response information (including initial processing and returning historical results), the server-side solidifies the following information into audit events: request identifier, session identifier, or user identifier; target node identifier and interaction type involved in the confirmation request; first version information of the interaction permission information effective on the terminal, and second version information of the interaction permission information effective on the server; server-side judgment result (allow / deny, etc.), judgment reason, and timestamp; the server-side persistently stores audit events in chronological order and establishes an index based on request identifier and timestamp; when it is necessary to trace a specific interaction operation, the corresponding audit event can be accurately retrieved through the request identifier, restoring the permission baseline version, judgment logic basis, and processing result at the time of permission judgment. Through this operation, the server can provide complete and tamper-proof operational chain evidence for security auditing, problem localization, and compliance verification, ensuring the uniqueness of operations in complex network environments, the traceability of permission baselines, and the replayability of judgment results.

[0063] Based on this, the response information is generated in the following manner: The first step is to generate response information based on the historical processing results of the confirmation request, if the confirmation request represented by the request identifier has been processed by the server.

[0064] Here, since the confirmation request has already been processed by the server, the server can obtain the historical processing results obtained from processing the confirmation request, and then generate response information based on these historical processing results. For example, after receiving a confirmation request containing a request identifier, the server combines the request identifier with a session identifier (SessionID) or a user identifier (UserID) to construct a unique idempotent key; the server queries the historical processing record database using this idempotent key: if a historical processing record associated with the idempotent key is found (indicating that the confirmation request has been processed by the server), the server reads the fixed judgment result and judgment reason in the historical processing record; the content of the historical processing record comes from the audit event generated when the server first processed the confirmation request; the server encapsulates the read judgment result (indicating whether execution is allowed or not allowed) and judgment reason according to a preset response information data structure; the encapsulated data constitutes the response information, the content of which is consistent with the response information generated when the confirmation request was first processed; the server returns this response information to the terminal. This operation does not re-execute permission verification or risk control judgment throughout the entire process; it only reuses the judgment results and judgment reasons already determined in the historical processing records. The storage and query of historical processing records can ensure that the same confirmation request (uniquely identified by the request identifier) ​​returns completely consistent response information in scenarios such as retransmission and retry.

[0065] Based on this, the following methods can be used to cancel a responded interactive operation: Cancel the already responded interactive operation based on the request identifier.

[0066] In some optional implementations, the corresponding interactive operation can be rolled back according to the request identifier, thereby canceling the already responded interactive operation.

[0067] It is understandable that request identifiers can more accurately cancel responded interactive operations; the server uses request identifiers to identify duplicate confirmation requests, thereby directly returning historical processing results and avoiding duplicate operations and inconsistencies in processing.

[0068] In some optional implementations of this embodiment, the terminal may also perform the following steps: The first step is to generate a key for the terminal within the terminal's Trusted Execution Environment (TEE) based on the terminal's device identifier and a non-derivative random seed value.

[0069] Device identifiers can be unique identifiers for terminal devices, such as IMEI (International Mobile Equipment Identity), OAID (Open Anonymous Identifier), or Android ID (Android system device unique identifier).

[0070] The random seed value can be a device-level random secret seed that is not exported (i.e., cannot be exported) to the TEE.

[0071] The key mentioned above can represent a device-level unique key K_device, derived from KDF (key derivation function). K_device is provided to the encryption / decryption module in a protected form.

[0072] In some alternative implementations, the terminal can derive a key via KDF within the TEE. Specifically, it can use the device unique identifier (DeviceID) as part of the derivation input, combined with the device-level random secret seed (Seed) generated and stored within the TEE, to call KDF within the TEE to derive the device-level unique key (K_device).

[0073] The second step is to use a key to encrypt the interactive permission information that is effective on the terminal, thus obtaining encrypted data.

[0074] In some alternative implementations, the terminal can use a key K_device to encrypt interactive permission information (such as permission mask information in a dictionary structure) to obtain encrypted data.

[0075] The third step is to store the encrypted data.

[0076] In some alternative implementations, the terminal can store encrypted data locally, thereby enabling the use of interactive permission information offline.

[0077] Based on this, before determining whether an interactive operation is allowed to be executed based on the interaction permission information effective on the terminal, the aforementioned execution entity can also decrypt the encrypted data using a key within a trusted execution environment to obtain the interaction permission information effective on the terminal. Therefore, different terminals can have different keys.

[0078] In some optional implementations, the terminal can use the key K_device within the TEE to decrypt the encrypted data and obtain the decrypted data containing the terminal's effective interaction permission information.

[0079] It is understandable that generating keys and performing encryption / decryption operations within a trusted execution environment can improve the security of node interactions; generating keys by combining device identifiers with non-derivative random seed values ​​can further improve the security of node interactions by preventing offline cached interaction permission information from being migrated or decrypted and reused across devices.

[0080] In some cases, the aforementioned terminal can also perform the following steps: The first step is to receive the first permission mask information, the first interaction strategy information, and the tree data of the hierarchical structure tree sent by the server. The permission mask information includes first information and second information. The first information indicates the visible / hidden state of the target node in the tree data, and the second information indicates the interactive display state of the target node. The interaction strategy information indicates the interaction permissions of the target node.

[0081] In this embodiment, the server can be used to generate and send permission mask information (including first permission mask information and second permission mask information), interaction policy information (including first interaction policy information and second interaction policy information), and tree data to the terminal to ensure the consistency of permission control. As an example, the server can be an enterprise-level application permission management backend.

[0082] The permission mask information (including first permission mask information and second permission mask information) comprises first information and second information. The first information indicates the visible / hidden state of the target node in the tree data. The second information indicates the interactive display state of the target node. Here, the permission mask information is used to uniformly control the visibility and interaction of nodes (including target nodes), avoiding inconsistencies between display and interaction.

[0083] In some optional implementations, the permission mask information can be a dictionary structure or a JSON (JavaScript Object Notation) structure. For example, the permission mask information can be defined as a dictionary structure M={v,d,p,l}, where v represents the visibility bit, d represents the disable bit, p represents the placeholder bit, and l represents the lazy loading bit. Each node (including the target node) maintains the ID (identity), version information, and mask bits (i.e., the values ​​of v, d, p, and l) of the permission mask information. The values ​​of v, d, p, and l can be binary bits, such as 0 or 1.

[0084] Interaction policy information (including first interaction policy information and second interaction policy information) can describe the interaction permissions of nodes (including target nodes), such as whether interaction behavior is allowed or not.

[0085] Here, the interaction strategy information and the permission mask information work together to determine whether a node is interactive, preventing interface bypass.

[0086] In some optional implementations, the server can simultaneously send (one implementation of associated sending) the node's interaction strategy information and permission mask information to the terminal to avoid inconsistencies in the terminal's display and interaction with the node, and to prevent unauthorized eavesdropping and interface bypassing.

[0087] A hierarchical structure tree represents a collection of data with hierarchical relationships. For example, a hierarchical structure tree can be used to organize and display node data with parent-child relationships, such as a corporate organizational structure.

[0088] The first piece of information is used to control whether the target node is visible to the user, thus implementing data permission filtering. In some optional implementations, when the permission mask information is defined as M={v,d,p,l}, the first piece of information can be v, which represents visibility. When v=1, the node is visible, and when v=0, the node is hidden.

[0089] The second information is used to control the interactivity of the target node. In some optional implementations, when the permission mask information is defined as M={v,d,p,l}, the second information may include a disable bit d, a placeholder bit p, and a lazy loading bit l. When d=1, the node is disabled; when d=0, it is allowed. When p=1, sensitive content in the node (such as contact information and address) is replaced with preset characters; when p=0, the content in the node is displayed normally. When l=1, the node is lazy loaded to optimize performance; when l=0, the node is loaded normally, i.e., no lazy loading is required.

[0090] The target node can be any node in the hierarchical structure tree. For example, the target node could be a department node, an employee node, or a position node. Each node corresponds to a permission mask and interaction policy information.

[0091] The visibility state indicates whether a node is visible to the user. That is, the visibility state can be used to control the display and hiding of a target node. In some optional implementations, when the permission mask information is defined as M={v,d,p,l}, when v=1, the node's visibility state indicates that the node is visible to the user, and when v=0, the node's visibility state indicates that the node is hidden from the user.

[0092] Interactive display status can be a status identifier representing the interactive characteristics of a node. Here, interactive display status can be used to control the interactive behavior of a target node on the interface, such as disabling or placeholder. When the permission mask information is defined as M={v,d,p,l}, the interactive display status can be determined based on the disable bit d, the placeholder bit p, and the lazy loading bit l. When d=1, the interactive display status indicates disabling; when d=0, the interactive display status indicates allowing use; when p=1, the interactive display status indicates replacing sensitive content in the node with a preset character; when p=0, the interactive display status indicates that the node content is displayed normally; when l=1, the interactive display status indicates that the node is lazy-loaded to optimize performance; when l=0, the interactive display status indicates that the node is loaded normally, i.e., no lazy loading is required.

[0093] Interaction permissions represent the set of operations a user can perform on a node. Here, interaction permissions and permission mask information together control the interactive behavior of the node.

[0094] In some alternative implementations, at least one of the tree data, permission mask information, and interaction policy information can be encrypted and stored on the server and / or the terminal. AES (Advanced Encryption Standard)-256 can be used for this encryption.

[0095] In some alternative implementations, the server can package the permission mask information, interaction policy information, and tree data together and send them to the terminal to send them in a coordinated manner. Alternatively, an identifier can be used to achieve the coordinated sending of the permission mask information, interaction policy information, and tree data.

[0096] The second step is to show or hide the target node in the tree data based on the visibility status indicated by the first information in the first permission mask information.

[0097] In this embodiment, if the first information indicates a display state, then the target node can be displayed; if the first information indicates a hidden state, then the target node can be hidden.

[0098] In some alternative implementations, the first information in the first permission mask information can be obtained by parsing the first permission mask information, and then the visibility state represented by the first information can be determined.

[0099] In some optional implementations of this embodiment, the following approach can be used to control interactive operations on the target node based on the interactive display state represented by the second information in the first permission mask information and the interactive permissions represented by the first interaction strategy information: In response to a click event on the target node, perform the following steps (including steps one through four): Step 1: If the first status bit included in the second information of the first permission mask information is the first preset character, then set the target node to read-only status.

[0100] A click event is an interactive event triggered by a user clicking a target node using touch or a mouse.

[0101] The first status bit can be a bit flag in the permission mask information used to indicate the read-only characteristic of a node. Here, the first status bit can control whether the target node is editable or selectable. When the permission mask information is defined as a dictionary structure M={v,d,p,l}, the first status bit can be the disabled bit d.

[0102] The first preset character can be any predefined character. For example, the first preset character can be 1. When the first status bit is 1, the target node can be disabled, that is, the target node is set to read-only status.

[0103] A read-only state indicates that a node can be viewed but not modified or selected.

[0104] Step 2: If the second status bit included in the second information of the first permission mask information is the first preset character, then replace the target content in the target node with the preset placeholder.

[0105] The second status bit can be a bit identifier in the permission mask information that indicates the placeholder characteristics of the node content. When the permission mask information is defined as a dictionary structure M={v,d,p,l}, the second status bit can be the placeholder bit p.

[0106] The target content can be sensitive information in the target node, such as name, phone number, address, etc.

[0107] Preset placeholders can be predefined characters or images used to hide sensitive information.

[0108] Step 3: If the first interaction strategy information indicates that selection is not allowed, then the selection operation corresponding to the click event is prohibited.

[0109] The selection operation can be the user's action of selecting a node.

[0110] Step 4: If the first status bit is the second preset character, the second status bit is the second preset character, and the first interaction strategy information indicates that selection is allowed, then the selection operation is allowed.

[0111] The second preset character can be another pre-defined character. For example, the second preset character could be 0. When the first status bit is 0, the target node is allowed to be used, meaning the target node is set to a non-read-only state. When the second status bit is 0, there is no need to de-identify the target node; the node information of the target node is displayed.

[0112] In some alternative implementations, after setting the target node to read-only, a grayscale style can be added to the target node, and / or an unclickable event interceptor can be added to block all interactive events.

[0113] It can be understood that when a click event is executed on a target node, differentiated processing is performed based on the first status bit (controlling read-only state), the second status bit (controlling placeholder replacement), and the first interaction strategy information (controlling selection permission) included in the second information of the first permission mask information: when the first status bit is the first preset character, the target node is set to read-only state; when the second status bit is the first preset character, the target content in the target node is replaced with a preset placeholder; when the first interaction strategy information indicates that selection is not allowed, the selection operation corresponding to the click event is prohibited; and the selection operation is only allowed when the first status bit is the second preset character, the second status bit is the second preset character, and the first interaction strategy information indicates that selection is allowed. This constructs an atomic verification chain of the target node's state and permissions under a click event, ensuring consistency between the read-only state, content anonymization, and selection permission control logic. This avoids unauthorized operations on sensitive target nodes (such as triggering selection on read-only target nodes or leaking the original content of target nodes requiring anonymization). Simultaneously, the judgment condition of the preset character improves event processing efficiency and ensures consistency between the visual state and operation permissions of the target node during click interactions.

[0114] In some optional implementations of this embodiment, the following approach can be used to control interactive operations on the target node based on the interactive display state represented by the second information in the first permission mask information and the interactive permissions represented by the first interaction strategy information: In response to the expand event of the target node, perform the following steps (including steps one and two): Step 1: If the first interaction strategy information indicates that expansion is not allowed, then the expansion operation on the target node is prohibited.

[0115] An expand event can be an interactive event where a user triggers a node to expand and view its child nodes.

[0116] The expand operation can be performed to expand a node in order to display the node's child nodes.

[0117] Step two: If the first interaction strategy information indicates that expansion is allowed, then the expansion operation is allowed, and the following steps (including sub-step one and sub-step two) are executed based on the third state bit in the second information: In the first sub-step, if the third status bit is the first preset character, the target node is rendered as an expandable state. After receiving the expand operation for the target node in the expandable state, it is determined whether the terminal has cached the child node data of the target node. If the child node data has been cached, the child node data is loaded and displayed. If the child node data has not been cached, the child node data is requested from the server.

[0118] The third state bit can be a bit identifier in the permission mask information used to indicate the node expansion characteristics. When the permission mask information is defined as a dictionary structure M={v,d,p,l}, the third state bit can be the lazy loading bit l.

[0119] An expandable state can represent a node that has child nodes and is allowed to be expanded.

[0120] Child node data can be data from the child nodes of the target node.

[0121] In sub-step two, if the third status bit is the second preset character, then load and display the child node data.

[0122] Here, the second preset character can be 0. When the third status bit is 0, the child node data can be loaded and displayed directly without starting lazy loading; when the third status bit is 1, it can first determine whether the terminal has cached the child node data of the target node. If the child node data has been cached, the child node data is loaded and displayed. If the child node data has not been cached, the child node data is requested from the server, thereby realizing lazy loading.

[0123] It is understandable that when an expand event is executed on a target node, the system first determines whether the expand operation is allowed based on the first interaction strategy information. If expandability is allowed, a differentiated child node loading strategy is executed based on the third status bit in the second information: when the third status bit is the first preset character, the target node is rendered as expandable, and upon receiving an expand operation for a target node in the expandable state, the system first determines whether the terminal has cached the child node data of the target node. If cached, the data is loaded and displayed; otherwise, the child node data is requested from the server. When the third status bit is the second preset character, the child node data is directly loaded and displayed. This deeply couples expandability control with the child node loading strategy. On the one hand, it avoids unauthorized expand operations through the first interaction strategy information; on the other hand, it switches between lazy loading and preloading through the third status bit. This reduces the initial data loading and memory usage of large hierarchical structure trees, avoids invalid network requests, and ensures logical consistency between the "expandable" visual identifier and the actual loading behavior, improving the terminal's response speed and resource utilization efficiency in complex organizational structure scenarios.

[0124] The third step is to control the interactive operations on the target node after displaying the target node, based on the interactive display status represented by the second information in the first permission mask information and the interactive permissions represented by the first interaction strategy information.

[0125] In this embodiment, interactive operations represent user actions on target nodes, such as clicking, expanding, and dragging. Here, interactive operations are subject to dual control by permission mask information and interaction policy information to ensure operational security and consistency.

[0126] It is understandable that fine-grained permission control is achieved by associating and sending the first permission mask information, the first interaction strategy information, and the tree data of the hierarchical structure tree on the server side. The first permission mask information includes first information indicating the visible / hidden state of the target node and second information indicating the interactive display state of the target node. The first interaction strategy information indicates the interaction permissions of the target node. This extends permission expression from traditional interface layer control to the client rendering and interaction layers, forming an end-to-end consistent permission control scheme. By showing or hiding the target node in the tree data based on the visible / hidden state indicated by the first information in the first permission mask, the user interface ensures that it only presents the organizational structure it has the right to access, avoiding the risk of unauthorized access. After displaying the target node, the interaction operations on the target node are controlled based on the interactive display state indicated by the second information in the first permission mask and the interaction permissions indicated by the first interaction strategy information. This ensures consistent control between the presentation layer and the interaction layer, and to some extent avoids situations where something is displayed but cannot be interacted with, or can be interacted with but is not displayed, thereby improving the consistency of node display and interaction on the terminal.

[0127] In some cases, the terminal can also perform the following steps: The first step is to receive the first version information corresponding to the target node sent by the server, where the first version information corresponds to the first permission mask information and the first interaction strategy information.

[0128] Version information (including first version information and second version information) represents the version number identifier of permission mask information and interaction policy information. Here, version information is used to track changes in permission configuration and enable incremental updates.

[0129] In some optional implementations, a time-to-live (TTL) period can be set for each version information (including first version information and second version information) to control the validity period of cached data and avoid using expired permission mask information and interaction strategy information.

[0130] The second step involves receiving the second version information corresponding to the target node from the server if the target node's permission mask information or interaction policy information is updated. This second version information corresponds to the updated second permission mask information and the updated second interaction policy information of the target node.

[0131] Here, the server can maintain a mapping table between the current hierarchical structure tree and the newly added or updated permission mask information. When adding or updating permission mask information, the node of the newly added or updated permission mask information (i.e., the change node) is determined, a partial refresh is performed along the path of the change node, and a skeleton screen / empty state refresh is triggered. The complexity of determining the change node is O(k).

[0132] Third, if the version represented by the second version information is higher than the version represented by the first version information, then the first permission mask information is updated to the second permission mask information, and the first interaction strategy information is updated to the second interaction strategy information.

[0133] Here, if the version represented by the second version information is higher than the version represented by the first version information, the first permission mask information is updated to the second permission mask information, and the first interaction strategy information is updated to the second interaction strategy information. That is, only the interaction strategy information and permission mask information of the change node are updated synchronously, thereby reducing the overhead of full synchronization, improving the real-time performance of permission changes and system stability. Furthermore, the synchronous update scheme can avoid the problem of inconsistent permission configurations in multi-terminal scenarios.

[0134] It can be understood that by receiving the first version information (corresponding to the first permission mask information and the first interaction policy information) of the target node sent by the server, and receiving the second version information (corresponding to the updated second permission mask information and the updated second interaction policy information) of the target node when the permission mask information or interaction policy information of the target node is updated, the first permission mask information is updated to the second permission mask information and the first interaction policy information is updated to the second interaction policy information only when the version represented by the second version information is higher than the version represented by the first version information. This step establishes an incremental synchronization scheme based on version information, enabling the terminal to accurately identify the scope of changes in the target node's permission configuration, avoiding interface jitter and performance loss caused by a full refresh of the hierarchical structure tree; at the same time, the comparison of version levels ensures the correct permission update sequence, prevents the target node's permission status from being disordered due to network out-of-order or delay, and ensures the consistency between the terminal's permission data and the server, thereby improving the system's stability and user experience smoothness in dynamic permission management scenarios.

[0135] In some cases, the second step described above can be implemented in the following way: The first step is to respond to the first information in the first permission mask information indicating the display state as display, and then display the target node in the tree data.

[0136] In the case where the first information in the first permission mask information indicates that the visibility state is displayed, the terminal can display the target node in the tree data.

[0137] The second step is to respond to the first information in the first permission mask information indicating that the visibility state is hidden, and hide the target node in the tree data.

[0138] In the case where the first information in the first permission mask information indicates that the visibility state is hidden, the terminal can hide the target node in the tree data.

[0139] It is understandable that the explicit branching logic, where the first information in the first permission mask represents the target node in the tree data as either visible or hidden, transforms the display / hiding determination of the target node into a deterministic conditional execution flow. This ensures that the terminal's parsing of the first information is strictly aligned with the server's intent, avoiding incorrect or missed rendering of target nodes due to misjudgment of state values. At the same time, this branching structure makes the display / hiding control logic clear, facilitating the terminal to execute rendering decisions more efficiently, reducing invalid node traversal and rendering resource consumption, and improving the reliability and execution efficiency of the first information in the permission mask in controlling the display / hiding state of the target node.

[0140] It should be noted that, where there is no conflict, the technical features described in different alternative implementations can be included in the same embodiment. For the sake of brevity, they will not be elaborated here.

[0141] Based on the embodiments of this disclosure, the terminal and the server determine whether an interactive operation is allowed to be executed based on their respective effective interaction permission information, thus implementing dual-channel verification for interactive operations. This ensures the compatibility between the terminal's interactive operation on the node and its currently effective interaction permissions. Once the terminal determines that the interactive operation is allowed to be executed based on its effective interaction permission information, it immediately begins to respond to the interactive operation without waiting for the verification result from the server. This enables immediate response, avoids UI blocking, and improves the timeliness of interactive operation responses.

[0142] Figure 2 This is a flowchart illustrating another method for node interaction in a hierarchical structure tree provided in this embodiment of the disclosure. The method is applied to a terminal.

[0143] The confirmation request includes the first version of the interactive permission information that has been enabled on the terminal.

[0144] The first version information can indicate the version of the interactive permission information that is effective locally on the terminal.

[0145] Based on this, such as Figure 2 As shown, before step 101, the method further includes: Step 201: If the version represented by the first version information is different from the version represented by the second version information, receive the incremental interaction permission information corresponding to the second version information sent by the server relative to the interaction permission information corresponding to the first version information, wherein the second version information represents the version of the interaction permission information that is effective on the server.

[0146] In this embodiment, the second version information represents the version of the interaction permission information currently in effect on the server.

[0147] Incremental interaction permission information represents the differences in permission interaction information between the server and the terminal.

[0148] Step 202: Based on the incremental interaction permission information, update the interaction permission information that is effective on the terminal to obtain the updated interaction permission information.

[0149] In this embodiment, incremental interaction permission information can be merged into the interaction permission information that is effective on the terminal to obtain updated interaction permission information.

[0150] Step 203: Based on the updated interaction permission information, determine whether the interaction operation is allowed to be executed, so as to obtain the updated first determination result.

[0151] In this embodiment, the specific implementation of step 203 can be referred to step 102, and will not be repeated here.

[0152] Step 204: If the updated first confirmation result indicates that the interactive operation is allowed to be executed, send an updated confirmation request to the server.

[0153] In this embodiment, the specific implementation of step 204 can refer to step 103, and will not be repeated here.

[0154] It should be noted that, in addition to the contents described above, this embodiment may also include... Figure 1 The corresponding technical features described in the corresponding embodiments, thereby achieving Figure 1 For details on the technical effects of the node interaction method in the hierarchical structure tree shown, please refer to [link / reference needed]. Figure 1 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0155] Based on the embodiments of this disclosure, UI flickering and jitter caused by full refresh can be avoided through version control and incremental updates, reducing transmission traffic and energy consumption. When the server identifies that the interaction permission information has expired, the terminal can merge the incremental mask into the locally effective interaction permission information in a transactional manner without interrupting the user interaction, and automatically trigger the step of re-determining whether the interaction operation is allowed to be executed. This ensures that the interface and the permission baseline (i.e., the interaction permission information effective on the server) can converge and become consistent without the user refreshing. Thus, the matching between the terminal's interaction operation on the node and the currently effective interaction permission can be ensured.

[0156] The following describes the embodiments of this disclosure by way of example. However, it should be noted that the following content is only used to understand the technical solutions of the embodiments of this disclosure and does not constitute a limitation on the protection scope of the embodiments of this disclosure.

[0157] In related technologies, the display and interactive control technology of terminal hierarchical structure trees (such as department trees and organizational structure trees) has the following defects: Inconsistent access control: Mainstream solutions primarily rely on server-side RBAC / ABAC interface access control, with client-side display filtering often being implemented. Version changes for permissions are often delayed, leading to inconsistent states and the risk of interface bypass. Simply relying on interface authentication or "filtering before displaying" methods is insufficient to express complex states such as "visible but disabled," "visible but anonymized," and "visible but lazy-loaded," easily resulting in situations where the interface is visible but the interaction should not be allowed, or where the interaction is bypassed, leading to unauthorized access.

[0158] Offline capabilities are lacking: Permission information requires an internet connection to be obtained each time, making it unavailable offline; initial screen loading time and network load are high. User experience is poor in weak network environments, and error messages lack consistency.

[0159] Performance bottlenecks: In ultra-large-scale organizational structures with more than 10,000 nodes, traditional whole-tree rendering causes UI (User Interface) thread blocking and memory jitter; permission changes trigger whole-tree refresh, resulting in UI jitter and high overhead; and there is a lack of differential rendering and lazy loading mechanisms.

[0160] Security vulnerabilities: Traditional RBAC only filters at the data layer. Clients can bypass the presentation logic by sniffing memory or directly calling the local storage API (Application Programming Interface). It lacks hardware binding and secondary verification. Operations only rely on the results returned by the backend. The interaction layer can be bypassed by memory sniffing / script injection.

[0161] Audit and idempotency deficiencies: The lack of end-to-end audit and idempotent controls can easily lead to inconsistencies in state and difficulties in compliance audits; the retry mechanism is imperfect under network jitter, making it difficult to guarantee the uniqueness of operations.

[0162] Fragmented strategies: The lack of unified node-level state control leads to inconsistent display rules for the same node across different pages / components, resulting in high maintenance costs and a high risk of strategy vulnerabilities.

[0163] In view of this, this solution provides a method and system for interactive control of mobile terminal hierarchical structure tree based on permission mask and dual-channel verification. The following is a detailed description of this solution: 1. The system of permission mask (i.e., the permission mask information mentioned above) and interaction strategy (i.e., the interaction strategy information mentioned above).

[0164] 1.1 Node and data structure definition.

[0165] Hierarchical structure tree: It is composed of nodes in a parent-child hierarchical relationship. Each node is uniquely identified by NodeID and there is a path from the root to the node.

[0166] Basic node fields: NodeID (unique node identifier), NodeType (node ​​type), ParentID (parent node identifier), Name (node ​​name or display field), Version (node ​​permission version number).

[0167] 1.2 Design of permission bitmask (i.e., the permission mask information mentioned above).

[0168] Bit mask M={v,d,p,l}: v (Visible): Visibility bit; d (Disabled): Disabled bit; p (Placeholder): Placeholder for desensitization; l (Lazy): Lazy loading bit; Example of bitwise operation judgment: Therefore, it can be determined that (M&v) == v; Disabled condition: (M&d) == d; Placeholder determination: (M&p) == p; Lazy loading criterion: (M&l) == l; 1.3 Definition of interaction strategy.

[0169] Interaction policy represents "what can be done", and works in conjunction with mask to express "what state to present": CanSelect: Whether selection is allowed; CanExpand: Whether to allow expansion; CanSearch: Whether to allow searching / filtering; CanEdit: Whether editing or accessing details is allowed; DisplayMode: Display mode (Normal / Disabled / Placeholder, etc.); The server organizes the mask and interaction policy into a dictionary structure: MaskDict[NodeID]=(Version,M,Policy); 1.4 Server-side mask generation and distribution.

[0170] The server evaluates each node based on user identity and organizational permission policies and generates M and Policy: Visibility bit v: Based on RBAC / ABAC rules and organizational visibility domain determination, it is set to 1 when the visibility domain is satisfied; Disable bit d: Set to 1 when the node is under control / frozen / the user only has read-only permissions; Placeholder p: Set to 1 when the node contains sensitive information and the user has "visible but de-identified" permission, and set Policy.CanSelect to false at the same time; Lazy loading bit l: Set to 1 when the number of child nodes of this node ChildCount > Threshold (e.g., 50 or a dynamic threshold based on organizational hierarchy); CanExpand: Set to true when v=1 and (l=1 or there are child nodes); set to false when there are no child nodes. Version: Increments when the node's permissions / policies change, to guide partial updates on the client.

[0171] The server compresses and signs the MaskDict (HMAC (Hash-based Message Authentication Code)) and then sends it out via HTTPS (Hypertext Transfer Protocol Secure).

[0172] 2. Local access mechanism.

[0173] 2.1 Local access process.

[0174] Local access control is based on MaskDict. Within the same time slice when a user triggers an interaction event, the authorize function is called to predict the interaction. def authorize(node, M, Policy): if (M&v) == 0: return Deny if (M&d) == d: return Readonly if (M&p) == p: return Placeholder if Policy exists and Policy.CanSelect == false: return Deny return Allow 2.2 Local access control.

[0175] Instant response: Decide whether to allow the next interaction without waiting for network requests, avoiding UI blocking; Anticipate interactions: Predict whether the operation might exceed authority before clicking / submitting, and switch the interface state in advance; Offline availability: When offline or in a weak network, the upper bound of executable interactions is determined by a locally encrypted permission baseline; 3. Dual-channel verification closed loop.

[0176] 3.1 Key fields in the request header.

[0177] Request-ID: An idempotent identifier used for server-side deduplication, authorization, and auditing to ensure that "the same business operation only takes effect once" when retries or callbacks are repeated. Mask-Version: Permission version stamp, used by the server to identify whether the client's permission baseline has expired; 3.2 Dual-channel process.

[0178] Local Pre-check: The client performs interactive pre-checks based on a local encrypted mask dictionary; Remote Confirmation: After a business operation is triggered, a confirmation request is submitted to the server, which makes the final decision. Forced rollback: When the remote confirmation fails, the client uses the Request-ID to drive a UI transaction rollback; Revert to the selected, expanded, submitted states and local temporary changes caused by this interaction using the Request-ID; Immediately after the rollback, call authorize again to re-determine the target node and its critical path nodes; Project the re-determination result as a forced correction of the bitmask M (e.g., disable d=1 or placeholder desensitization p=1). The system will display the reason for the failure and record the audit event. 3.3 Server-side processing logic.

[0179] Use (Session ID, Request ID) or (User ID, Request ID) as idempotent identifiers for deduplication. The Mask-Version, judgment result, and cause are solidified into audit events; When Mask-Version is identified as expired, DeltaMask (incremental mask) is directly sent in the response.

[0180] 4. Hardware-bound encryption mechanism.

[0181] 4.1 Key Derivation.

[0182] Use a unique device identifier (such as at least one of IMEI (International Mobile Equipment Identity) / OAID (Open Anonymous Identifier) ​​ / Android ID (Android System Device Unique Identifier)) as part of the derived input.

[0183] Combined with a device-level random secret seed generated and stored within the TEE (Secure Execution Environment); Within the TEE, call the KDF (key derivation function) to derive the device-level unique key K_device; Seed does not produce a TEE; K_device is provided to the encryption / decryption module in a protected form. 4.2 Encrypted storage and invalidation handling.

[0184] The local mask dictionary MaskDict is encrypted, stored, and its integrity is verified using K_device; Achieve "one device, one key" at the physical layer, making offline cache unable to be migrated or decrypted and reused across devices; When the device environment changes or decryption / verification fails, the client enters controlled degradation (e.g., forcibly modifying the interface and restricting interaction with d=1 or p=1). 5. Silent hot update and differential rendering.

[0185] 5.1 Silent Hot Update (DeltaMask).

[0186] Atomized seamless merging: Merge DeltaMask into the local MaskDict in a transactional manner, and update Mask-Version and related metadata; Automatic re-determination: After merging, the authorize logic is automatically triggered to re-determine the permissions of the current interface and interaction; Coordination with rollback: If the operation is rejected, the client first rolls back, and then performs merging and re-determination; 5.2 Path Hash.

[0187] Path Hash Definition: Calculates a hash for a node path (a sequence of NodeIDs from the root to a node) or a subtree digest; On-demand synchronization: The client carries the key Path Hash when confirming remotely or synchronizing in the background; After comparing the path digests, the server only sends the DeltaMasks for the relevant paths. The client then merges them locally and triggers a re-determination of the authorization function. 5.3 Differential rendering engine.

[0188] Maintain a mapping table Map[ID]->(Version, M) between currentTree and newMask; When a new dictionary is received, calculate Diff: Set = {ID | state(currentTree[ID]) != state(newMask[ID])}; Only local refresh is performed along the path of the changed node and skeleton screen / empty state refresh is triggered, with a complexity of O(k); 6. Lazy loading deterministic control.

[0189] 6.1 Determine the logic.

[0190] When a node satisfies (M&l) == l, the client determines it to be a lazy-loaded node; The server assigns 1 bit to each node based on the size of its child nodes (e.g., ChildCount > Threshold). 6.2 Triggering timing.

[0191] Loading is initiated only when the user triggers the "expand" action on the node; Do not load it on the first screen or in advance when it is not necessary; 6.3 Loading strategy.

[0192] Prioritize using existing client data (such as cached data in the current session or already loaded sublists); If the match fails, request the server to retrieve the child node and update the mask and strategy of that node in the response. Exception safety: When l=1 and the network request fails or times out, the node's placeholder / expandable state remains unchanged, and the node is retried in the background using an exponential backoff or queue retry strategy; 7. Auditing and Logs.

[0193] 7.1 Audit Fields.

[0194] The server records audit events based on the Request-ID and context fields, forming a traceable chain; Audit logs include: timestamp, sessionId, userId, nodeId, action, geo; 7.2 Privacy protection.

[0195] De-identify and hierarchically store logs, and clearly define the retention period.

[0196] Record Request-ID, Mask-Version, node path summary, failure reason and rollback action both locally and on the server.

[0197] It should be noted that, in addition to the contents described above, this embodiment may also include the technical features described in the above embodiments, thereby achieving the technical effect of the node display and interaction method of the hierarchical structure tree shown above. Please refer to the above description for details. For the sake of brevity, it will not be elaborated here.

[0198] Based on the embodiments disclosed herein, by coordinating masking and policies, composite states such as "visible but desensitized" and "visible but disabled" are achieved to avoid leakage of sensitive information. A dual-channel verification closed loop defends against unauthorized results caused by sniffing / tampering of client memory data and blocks illegal operations caused by directly requesting interfaces from the client. A one-machine-one-key mechanism using a TEE-derived key achieves physical-level "one-machine-one-key," preventing offline cache from being migrated or decrypted and reused across devices. Rendering and interaction are uniformly determined by `authorize`, reducing the probability of "visible but not clickable / clickable but not viewable" vulnerabilities. A forced rollback mechanism ensures real-time convergence of interface and server permission baselines, avoiding state inconsistencies. Path hash synchronization ensures the client only updates changed paths, maintaining overall tree structure consistency. Offline encrypted caching makes first-screen loading independent of the network, reducing first-screen latency. The differential rendering engine only updates differential nodes, avoiding redrawing the entire tree and reducing UI jitter. The lazy loading mechanism only retrieves nodes marked as 'l' when the user expands them. Child nodes reduce memory and network overhead; path hash synchronization reduces transmission traffic and energy consumption, avoiding UI flickering and jitter caused by full refresh; controlled availability is provided with locally encrypted permission baselines when offline or in weak network conditions; local access control provides millisecond-level interactive feedback, improving user experience; silent hot updates complete permission baseline updates without interrupting user interaction; forced rollback and friendly prompts ensure consistent error handling, improving user experience; Request-ID and Mask-Version enable end-to-end auditing, making all operations traceable; idempotent processing based on Request-ID ensures that "the same business operation only takes effect once"; server-side solidified audit events include permission version and judgment results, supporting post-event review; masks and policies serve as a single data source, ensuring consistent display rules for the same node across different pages / components; bitmasks use bitwise operation logic and can be extended with other attribute bits (such as audit bits, secondary confirmation bits, etc.); permission changes automatically trigger differential updates and re-judgments, reducing manual intervention. Therefore, by using permission mask driving, dual-channel verification, hardware binding encryption, and differential rendering, an end-to-end consistent, offline available, tamper-resistant, and high-performance mobile terminal hierarchical structure tree interaction control system was constructed, systematically solving the security, consistency, performance, and user experience issues of existing technologies.

[0199] Figure 3 This is a schematic diagram of a node interaction device for a hierarchical structure tree provided in an embodiment of the present disclosure. The node interaction device for the hierarchical structure tree includes: The first receiving unit 301 is configured to receive interactive operations for target nodes in the hierarchical structure tree; The first determining unit 302 is configured to: determine whether the interactive operation is allowed to be executed based on the interactive permission information effective on the terminal, so as to obtain the first determining result; The first sending unit 303 is configured to: if the first determination result indicates that the interactive operation is allowed to be executed, respond to the interactive operation and send a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein the server generates response information for the confirmation request based on the interactive permission information effective on the server. The second receiving unit 304 is configured to receive response information sent by the server. The second determining unit 305 is configured to determine whether to perform an interactive operation based on the response information.

[0200] In some possible implementations, the confirmation request includes first version information of the interaction permission information that has been activated on the terminal; and The device also includes: The third receiving unit (not shown in the figure) is configured to: if the version represented by the first version information is different from the version represented by the second version information, receive the incremental interactive permission information of the interactive permission information corresponding to the second version information sent by the server relative to the interactive permission information corresponding to the first version information, wherein the second version information represents the version of the interactive permission information that is effective on the server. The update unit (not shown in the figure) is configured to update the terminal's active interaction permission information based on the incremental interaction permission information to obtain the updated interaction permission information. The third determining unit (not shown in the figure) is configured to: determine whether the interactive operation is allowed to be executed based on the updated interactive permission information, so as to obtain the updated first determining result; The second sending unit (not shown in the figure) is configured to send an updated confirmation request to the server if the updated first confirmation result indicates that the interactive operation is allowed to be executed.

[0201] In some possible implementations, determining whether to perform an interactive operation based on the response information includes: If the response message indicates that execution is permitted, then continue to respond to interactive operations in order to execute the interactive operations; If the response indicates that execution is not allowed, then the already responded interactive operation will be canceled.

[0202] In some possible implementations, the confirmation request includes a request identifier generated by the terminal; The response information is generated in the following way: If the confirmation request indicated by the request identifier has already been processed by the server, a response is generated based on the historical processing results of the confirmation request; and Cancel responded interactive actions, including: Cancel the already responded interactive operation based on the request identifier.

[0203] In some possible implementations, the device further includes: The generation unit (not shown in the figure) is configured to generate a key for the terminal based on the terminal's device identifier and a non-derivative random seed value within the terminal's trusted execution environment. The encryption unit (not shown in the figure) is configured to encrypt the interactive permission information that is effective on the terminal using a key to obtain encrypted data; The storage unit (not shown in the figure) is configured to: store encrypted data; and The decryption unit (not shown in the figure) is configured to: decrypt encrypted data using a key within a trusted execution environment to obtain the terminal's effective interaction permission information.

[0204] The node interaction device of the hierarchical structure tree provided in this embodiment can execute the corresponding steps of the node interaction methods of the hierarchical structure trees described above, thereby achieving the technical effects of the node interaction methods of the hierarchical structure trees described above. The node interaction device of the hierarchical structure tree and the node interaction methods of the hierarchical structure tree can refer to and reference each other in specific implementation and technical effects. For the sake of brevity, they will not be elaborated here.

[0205] Figure 4 This is a schematic diagram of a node interaction system for a hierarchical structure tree provided in an embodiment of the present disclosure. The node interaction system for the hierarchical structure tree includes a terminal 401 and a server 402, wherein: Terminal 401 is configured to: receive interactive operations for target nodes in a hierarchical structure tree; determine whether the interactive operation is allowed to be executed based on the interactive permission information effective on terminal 401, so as to obtain a first determination result; if the first determination result indicates that the interactive operation is allowed to be executed, respond to the interactive operation and send a confirmation request to server 402 for server 402 to determine whether the interactive operation is allowed to be executed. The server-side 402 is configured to generate a response message for the confirmation request based on the interaction permission information that has been activated by the server-side 402. Terminal 401 is also configured to: receive response information sent by server 402; and determine whether to perform an interactive operation based on the response information.

[0206] In some possible implementations, the confirmation request includes first version information of the interaction permission information that has been activated on terminal 401; and Terminal 401 is also configured as follows: If the version represented by the first version information is different from the version represented by the second version information, the interaction permission information corresponding to the second version information sent by the server 402 is the incremental interaction permission information relative to the interaction permission information corresponding to the first version information, wherein the second version information represents the version of the interaction permission information that the server 402 has enabled. Based on the incremental interaction permission information, update the interaction permission information that is effective in terminal 401 to obtain the updated interaction permission information; Based on the updated interaction permission information, determine whether the interaction operation is allowed to be executed, so as to obtain the updated first determination result; If the updated first confirmation result indicates that the interactive operation can be executed, send an updated confirmation request to the server via 402.

[0207] In some possible implementations, terminal 401 is specifically configured as follows: If the response message indicates that execution is permitted, then continue to respond to interactive operations in order to execute the interactive operations; If the response indicates that execution is not allowed, then the already responded interactive operation will be canceled.

[0208] In some possible implementations, the confirmation request includes a request identifier generated by terminal 401; The response information is generated in the following way: If the confirmation request indicated by the request identifier has already been processed by the server with a 402 response, a response message is generated based on the historical processing results of the confirmation request; and Terminal 401 is specifically configured as follows: Cancel the already responded interactive operation based on the request identifier.

[0209] In some possible implementations, terminal 401 is also configured to: Within the trusted execution environment of terminal 401, a key for terminal 401 is generated based on the device identifier of terminal 401 and a non-derivative random seed value. The key is used to encrypt the interactive permission information that is effective on terminal 401, resulting in encrypted data. Store encrypted data; Within a trusted execution environment, encrypted data is decrypted using a key to obtain the interaction permission information that has been activated by terminal 401.

[0210] The node interaction system of the hierarchical structure tree provided in this embodiment can execute the corresponding steps of the node interaction methods of the hierarchical structure trees described above, thereby achieving the technical effects of the node interaction methods of the hierarchical structure trees described above. The node interaction system of the hierarchical structure tree and the node interaction methods of the hierarchical structure tree can refer to and reference each other in terms of specific implementation and technical effects. For the sake of brevity, they will not be elaborated here.

[0211] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. Figure 5The illustrated electronic device 500 includes at least one processor 501, a memory 502, at least one network interface 504, and other user interfaces 503. The various components in the electronic device 500 are coupled together via a bus system 505. It is understood that the bus system 505 is used to implement communication between these components. In addition to a data bus, the bus system 505 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 5 The general designated all buses as Bus System 505.

[0212] The user interface 503 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0213] It is understood that the memory 502 in this embodiment of the present disclosure may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 502 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0214] In some implementations, memory 502 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 5021 and application program 5022.

[0215] The operating system 5021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 5022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 5022.

[0216] In this embodiment, by calling the program or instructions stored in memory 502, specifically the program or instructions stored in application program 5022, processor 501 executes the method steps provided in each method embodiment, including, for example: Receive interactive operations for target nodes in the hierarchical structure tree; Based on the interaction permission information enabled on the terminal, determine whether the interaction operation is allowed to be executed, so as to obtain the first determination result; If the first determination result indicates that the interactive operation is allowed to be executed, the system responds to the interactive operation and sends a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein, the server generates the response information of the confirmation request based on the interactive permission information that is effective on the server. Receive response information sent by the server; The decision to perform an interactive action is based on the response information.

[0217] The methods disclosed in the above embodiments of this disclosure can be applied to or implemented by processor 501. Processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in processor 501. The processor 501 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 502. Processor 501 reads the information in memory 502 and, in conjunction with its hardware, completes the steps of the above method.

[0218] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described above, or combinations thereof.

[0219] For software implementation, the techniques described herein can be implemented by units that perform the functions described above. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or external to the processor.

[0220] The electronic device provided in this embodiment may be as follows: Figure 5 The electronic device shown can execute all the steps of the node interaction methods of the various hierarchical structure trees described above, thereby achieving the technical effects of the node interaction methods of the various hierarchical structure trees described above. For details, please refer to the relevant descriptions above. For the sake of brevity, it will not be elaborated here.

[0221] This disclosure also provides a storage medium (computer-readable storage medium). The storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0222] When one or more programs in the storage medium can be executed by one or more processors to implement the node interaction method of the hierarchical structure tree executed on the electronic device side.

[0223] The processor described above is used to execute a node interaction program for a hierarchical structure tree stored in memory to implement the following steps of a node interaction method for a hierarchical structure tree executed on the electronic device side: Receive interactive operations for target nodes in the hierarchical structure tree; Based on the interaction permission information enabled on the terminal, determine whether the interaction operation is allowed to be executed, so as to obtain the first determination result; If the first determination result indicates that the interactive operation is allowed to be executed, the system responds to the interactive operation and sends a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein, the server generates the response information of the confirmation request based on the interactive permission information that is effective on the server. Receive response information sent by the server; The decision to perform an interactive action is based on the response information.

[0224] Furthermore, the computer program product provided in this disclosure embodiment may include computer-readable code that, when executed on a device, causes a processor in the device to implement the following steps of a hierarchical structure tree node interaction method executed on the electronic device side: Receive interactive operations for target nodes in the hierarchical structure tree; Based on the interaction permission information enabled on the terminal, determine whether the interaction operation is allowed to be executed, so as to obtain the first determination result; If the first determination result indicates that the interactive operation is allowed to be executed, the system responds to the interactive operation and sends a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein, the server generates the response information of the confirmation request based on the interactive permission information that is effective on the server. Receive response information sent by the server; The decision to perform an interactive action is based on the response information.

[0225] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0226] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0227] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0228] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A node interaction method for a hierarchical structure tree, characterized in that, The method is applied to a terminal, and the method includes: Receive interactive operations for target nodes in the hierarchical structure tree; Based on the interaction permission information enabled by the terminal, determine whether the interaction operation is allowed to be executed, so as to obtain a first determination result; If the first determination result indicates that the interactive operation is allowed to be executed, the system responds to the interactive operation and sends a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; wherein, the server generates the response information of the confirmation request based on the interactive permission information that is effective on the server. Receive the response information sent by the server; Based on the response information, determine whether to execute the interactive operation.

2. The method according to claim 1, characterized in that, The confirmation request includes the first version information of the interaction permission information that the terminal has activated; as well as Before receiving the response information sent by the server, the method further includes: If the version represented by the first version information is different from the version represented by the second version information, receive the incremental interaction permission information corresponding to the second version information sent by the server relative to the interaction permission information corresponding to the first version information, wherein the second version information represents the version of the interaction permission information that is effective by the server. Based on the incremental interaction permission information, the effective interaction permission information of the terminal is updated to obtain the updated interaction permission information. Based on the updated interaction permission information, determine whether the interaction operation is allowed to be executed, so as to obtain the updated first determination result; If the updated first confirmation result indicates that the interactive operation is allowed to be executed, an updated confirmation request is sent to the server.

3. The method according to claim 1, characterized in that, Determining whether to execute the interactive operation based on the response information includes: If the response information indicates that execution is permitted, then continue to respond to the interactive operation to execute the interactive operation; If the response information indicates that execution is not allowed, then the already responded interactive operation is cancelled.

4. The method according to claim 3, characterized in that, The confirmation request includes a request identifier generated by the terminal; The response information is generated in the following manner: If the confirmation request represented by the request identifier has been processed by the server, the response information is generated based on the historical processing results of the confirmation request; as well as The cancellation of the already responded interactive operation includes: Based on the request identifier, the already responded interactive operation is revoked.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Within the trusted execution environment of the terminal, a key for the terminal is generated based on the terminal's device identifier and a non-derivative random seed value. The key is used to encrypt the interaction permission information that is effective on the terminal to obtain encrypted data. Store the encrypted data; and Before determining whether the interactive operation is allowed to be executed based on the interaction permission information effective on the terminal, the method further includes: Within the trusted execution environment, the encrypted data is decrypted using the key to obtain the interaction permission information that is effective for the terminal.

6. A node interaction system for a hierarchical structure tree, characterized in that, The system includes a terminal and a server, wherein: The terminal is configured to: receive interactive operations for target nodes in the hierarchical structure tree; determine whether the interactive operation is allowed to be executed based on the interactive permission information effective on the terminal, so as to obtain a first determination result; if the first determination result indicates that the interactive operation is allowed to be executed, respond to the interactive operation, and send a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed. The server is configured to generate response information for the confirmation request based on the interaction permission information that is effective on the server. The terminal is also configured to: receive the response information sent by the server; and determine whether to perform the interactive operation based on the response information.

7. The system according to claim 6, characterized in that, The confirmation request includes the first version information of the interaction permission information that the terminal has activated; and The terminal is also configured to: If the version represented by the first version information is different from the version represented by the second version information, receive the incremental interaction permission information corresponding to the second version information sent by the server relative to the interaction permission information corresponding to the first version information, wherein the second version information represents the version of the interaction permission information that is effective by the server. Based on the incremental interaction permission information, the effective interaction permission information of the terminal is updated to obtain the updated interaction permission information. Based on the updated interaction permission information, determine whether the interaction operation is allowed to be executed, so as to obtain the updated first determination result; If the updated first confirmation result indicates that the interactive operation is allowed to be executed, an updated confirmation request is sent to the server.

8. The system according to claim 6, characterized in that, The terminal is specifically configured as follows: If the first determination result indicates that the interactive operation is allowed to be executed, respond to the interactive operation and send a confirmation request to the server for the server to determine whether the interactive operation is allowed to be executed; If the response information indicates that execution is permitted, then continue to respond to the interactive operation to execute the interactive operation; If the response information indicates that execution is not allowed, then the already responded interactive operation is cancelled.

9. The system according to claim 8, characterized in that, The confirmation request includes a request identifier generated by the terminal; The response information is generated in the following manner: If the confirmation request represented by the request identifier has been processed by the server, the response information is generated based on the historical processing results of the confirmation request; and The terminal is specifically configured as follows: Based on the request identifier, the already responded interactive operation is revoked.

10. The system according to any one of claims 6-9, characterized in that, The terminal is also configured to: Within the trusted execution environment of the terminal, a key for the terminal is generated based on the terminal's device identifier and a non-derivative random seed value. The key is used to encrypt the interaction permission information that is effective on the terminal to obtain encrypted data. Store the encrypted data; Within the trusted execution environment, the encrypted data is decrypted using the key to obtain the interaction permission information that is effective for the terminal.

Images