Method and system for collaborative management of graphics rendering and text editing permissions

Abstract

The present application relates to the technical field of graphics rendering and text editing, and particularly relates to a method for collaborative management of permissions for graphics rendering and text editing. By deploying a unified permission verification intermediate layer, an operation instruction of a user on a target composite object is obtained, a rendering and editing operation type is synchronously analyzed and a permission verification result is queried, an operation control token is generated by consistency comparison, and a differentiated operation execution strategy is issued to a rendering engine and an editor according to permission identification information in the token. The present application realizes collaborative permission management and control of rendering and editing based on the same token, and improves operation consistency and security.

Description

Technical Field

[0001] This invention relates to the field of graphics rendering and text editing technology, and in particular to a method and system for collaborative management of permissions for graphics rendering and text editing. Background Technology

[0002] In applications that integrate graphics rendering and text editing, such as online design tools, rich text editors, or interactive whiteboard systems, simultaneous rendering operations on visual elements (such as shapes and images) and editing operations on text content (such as fonts, paragraphs, and links) are typically involved. In existing technologies, the rendering engine and text editor run as independent modules, each maintaining its own independent permission verification system. When a user performs an operation on a composite object containing both a rendering area and a text editing area, the rendering engine and editor receive the operation instructions, query the corresponding permission data, and then independently execute the allow or deny operation. This separate permission management architecture is a common and conventional practice in implementation.

[0003] However, this conventional approach has significant drawbacks. Firstly, the validation results for rendering and editing permissions may be inconsistent. For example, the rendering engine might allow modification of graphic colors, while the text editor might refuse to modify associated text due to insufficient permissions. This results in the composite object being updated at the graphic level but blocked at the text level, causing inconsistent interface states or confusion regarding the effectiveness of certain operations. Secondly, because each operation requires independent permission queries and logical judgments in two separate modules, the overall response time increases, and there is a lack of a unified coordination mechanism to ensure that the two modules understand and execute the same operation command synchronously. When operations involve complex permission dependencies (such as differences in read / write restrictions for the same composite object by different user roles), this separate validation method is more prone to permission vulnerabilities or misjudgments, failing to guarantee the synergy and consistency of permission control between graphics rendering and text editing. Summary of the Invention

[0004] This invention provides a method and system for collaborative management of graphics rendering and text editing permissions, which can solve the problems in the prior art.

[0005] A first aspect of the present invention provides a method for collaborative management of graphics rendering and text editing permissions, comprising: Obtain user commands for operations on a target composite object in the canvas, wherein the target composite object includes a rendering area and a text editing area; Deploy a unified permission verification middleware layer between the rendering engine and the editor, and route the operation instructions to the unified permission verification middleware layer; The unified permission verification middleware synchronously parses the rendering operation type and text editing operation type corresponding to the operation instruction, and queries the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain the unified permission verification conclusion. An operation control token is generated based on the unified permission verification result. The operation control token includes permission identification information and operation type identification information. Based on the permission identification information in the operation control token, differentiated operation execution strategies are issued to the rendering engine and the editor respectively. The rendering engine performs rendering control on the rendering area according to the corresponding operation execution strategy, and the editor performs editing control on the text editing area according to the corresponding operation execution strategy, so that the rendering engine and the editor can collaboratively perform permission management based on the same operation control token.

[0006] In one optional embodiment, a unified permission verification middleware layer is deployed between the rendering engine and the editor, and the operation instructions are routed to the unified permission verification middleware layer, including: The interface feature difference information is obtained by analyzing the instruction receiving interface features of the rendering engine and the editor. Based on the interface feature difference information, a unified permission verification middleware is inserted between the rendering engine and the editor. The input port and output port of the unified permission verification middleware are configured. The input port receives the operation instructions, and the output port includes a rendering output sub-port and an editing output sub-port. A permission verification logic template is loaded in the unified permission verification intermediate layer. The permission verification logic template includes rendering operation verification rules and editing operation verification rules. Establish a first communication link between the unified permission verification middleware layer and the rendering engine, and a second communication link between the unified permission verification middleware layer and the editor; Based on the link status information of the first communication link and the second communication link, and the permission verification logic template, the routing rules of the unified permission verification intermediate layer are configured so that the operation instruction enters the unified permission verification intermediate layer through the input port according to the routing rules, and is routed to the corresponding instruction receiving interface through the rendering output sub-port or the editing output sub-port according to the operation type identifier corresponding to the operation instruction.

[0007] In one optional embodiment, the unified permission verification intermediate layer synchronously parses the rendering operation type and text editing operation type corresponding to the operation instruction, including: Extract the semantic information of the operation instruction, and identify the operation category to which the operation instruction belongs based on the semantic information. The operation category includes rendering operation category and editing operation category. When the operation instruction belongs to the rendering operation category, the operation instruction is further subdivided according to the rendering operation classification rules to obtain the rendering operation type; When the operation instruction belongs to the operation category of editing operation, the operation instruction is further subdivided according to the editing operation classification rules to obtain the text editing operation type; The rendering operation type and the text editing operation type are structurally encapsulated to obtain operation type description information, which includes operation type identifier and operation scope identifier. The operation type description information is output to the permission query module of the unified permission verification intermediate layer, so that the permission query module can query the corresponding rendering permission verification result and editing permission verification result according to the operation type identifier and the operation scope identifier respectively.

[0008] In one optional embodiment, the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type are queried respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain a unified permission verification conclusion, including: Based on the rendering operation type, query the rendering permission configuration information corresponding to the rendering area; based on the text editing operation type, query the editing permission configuration information corresponding to the text editing area. The rendering permission configuration information and the editing permission configuration information are compared in terms of permission status to detect the status difference information between the rendering permission configuration information and the editing permission configuration information; The state difference information is used to determine conflicts according to the preset permission consistency rules. When the state difference information meets the conflict conditions in the permission consistency rules, permission conflict marker information is generated. When the state difference information does not meet the conflict condition, permission fusion information is generated based on the rendering permission configuration information and the editing permission configuration information. The permission conflict marker information or the permission fusion information is output as the unified permission verification conclusion to the conclusion generation module of the unified permission verification intermediate layer, so that the conclusion generation module controls the generation logic of subsequent operation control tokens based on the unified permission verification conclusion.

[0009] In an optional embodiment, an operation control token is generated based on the unified permission verification conclusion. The operation control token includes permission identification information and operation type identification information, including: Parse the permission status information in the unified permission verification conclusion to obtain the rendering permission status identifier and the editing permission status identifier; A permission identifier field is generated based on the rendering permission status identifier and the editing permission status identifier, and an operation type identifier field is generated based on the rendering operation type and the text editing operation type; The permission identifier field and the operation type identifier field are written into a token data structure. The token data structure includes a token header area and a token payload area. The token header area stores the permission identifier field, and the token payload area stores the operation type identifier field. Configure time-limited attribute information for the operation control token, the time-limited attribute information including the token's effective time and the token's expiration time; The operation control token configured with the timeliness attribute information is output to the permission control distribution module, so that the permission control distribution module distributes the corresponding operation control strategy to the rendering engine and the editor according to the permission identifier field and the operation type identifier field.

[0010] In one optional embodiment, based on the permission identification information in the operation control token, differentiated operation execution strategies are issued to the rendering engine and the editor respectively, including: Parse the permission identifier field in the operation control token to obtain the rendering operation permission status corresponding to the rendering engine and the editing operation permission status corresponding to the editor. A rendering operation execution strategy is generated based on the rendering operation permission status. The rendering operation execution strategy includes a set of allowed operations and a set of prohibited operations. An editing operation execution policy is generated based on the editing operation permission status, and the editing operation execution policy includes a set of allowed editing operations and a set of prohibited editing operations; The rendering operation execution strategy is encapsulated into a rendering control instruction package, and the editing operation execution strategy is encapsulated into an editing control instruction package. The rendering control instruction package contains the rendering operation permission status, and the editing control instruction package contains the editing operation permission status. The rendering control instruction package is sent to the rendering engine through the first communication link, and the editing control instruction package is sent to the editor through the second communication link, so that the rendering engine performs rendering operation filtering according to the rendering control instruction package, and the editor performs editing operation filtering according to the editing control instruction package.

[0011] In one optional embodiment, the rendering engine performs rendering control on the rendering area according to a corresponding operation execution strategy, and the editor performs editing control on the text editing area according to a corresponding operation execution strategy, enabling the rendering engine and the editor to collaboratively perform permission management based on the same operation control token, including: The rendering engine receives the rendering control instruction packet and performs permission filtering on the rendering operation requests input to the rendering area according to the set of allowed operations and the set of prohibited operations to obtain the rendering filtering result. The editor receives the editing control instruction package and performs permission filtering on the editing operation requests input to the text editing area according to the allowed editing operation set and the prohibited editing operation set, and obtains the editing filtering result; The rendering filtering result and the editing filtering result are synchronously verified to obtain state consistency information; When the state consistency information indicates that both the rendering filter result and the editing filter result are in an allowed state, the rendering operation request and the editing operation request are executed. When the state consistency information indicates that either the rendering filter result or the editing filter result is in a prohibited state, the corresponding operation request is blocked, and the operation blocking status information is fed back to the unified permission verification intermediate layer to update the permission identification information in the operation control token.

[0012] A second aspect of the present invention provides a system for collaborative management of graphics rendering and text editing permissions, comprising: The instruction acquisition unit is used to acquire user operation instructions for a target composite object in the canvas, wherein the target composite object includes a rendering area and a text editing area. The permission routing unit is used to deploy a unified permission verification middleware layer between the rendering engine and the editor, and to route the operation instructions to the unified permission verification middleware layer. The permission verification unit is used by the unified permission verification middle layer to synchronously parse the rendering operation type and text editing operation type corresponding to the operation instruction, and query the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain the unified permission verification conclusion. The token generation unit is used to generate an operation control token based on the unified permission verification conclusion. The operation control token includes permission identification information and operation type identification information. The strategy execution unit is used to issue differentiated operation execution strategies to the rendering engine and the editor respectively based on the permission identification information in the operation control token. The rendering engine performs rendering control on the rendering area according to the corresponding operation execution strategy, and the editor performs editing control on the text editing area according to the corresponding operation execution strategy, so that the rendering engine and the editor cooperate to perform permission management based on the same operation control token.

[0013] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0014] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0015] A unified permission verification middleware layer completely eliminates operational conflicts caused by asynchronous permission rules between the rendering engine and the editor. Synchronous parsing and consistency comparison mechanisms ensure that every operation receives completely consistent authorization judgments across both rendering and editing dimensions, preventing system anomalies caused by the separation of visual and text permissions. The operation control token atomically transmits the verification results to the execution end, providing a solid benchmark for the issuance of differentiated strategies. Based on the same operation control token, the rendering engine and editor each obtain execution strategies adapted to their own functional characteristics. The rendering area focuses on graphic display transformations, while the text editing area focuses on character modification, ensuring global permission consistency while retaining professional processing capabilities, enabling seamless integration of composite graphic and text objects. Dual encoding of permission identifiers and operation types supports individual authorization for specific operations, refining control granularity; differentiated strategies collaboratively improve system response efficiency. The rendering engine and editor do not need to perform repeated verifications, reducing interaction rounds and resource consumption. The unified verification middleware layer handles all verification logic, reducing coupling; when a user operates, the system quickly completes permission judgments and synchronously activates both processes, maintaining real-time consistency. Consistency checks intercept failed operations to prevent unauthorized modifications; differentiated policies allow for different permissions to be set for graphics and text, adapting to changing needs. The overall solution is implemented solely through software architecture optimization, resulting in low cost and high portability. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a method for collaborative management of permissions for graphics rendering and text editing. Figure 2 This is a flowchart illustrating the logic of permission verification and distribution. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0019] Figure 1 This is a flowchart illustrating the method for collaborative management of graphics rendering and text editing permissions according to an embodiment of the present invention.

[0020] Methods for collaborative management of graphics rendering and text editing permissions include: Obtain user commands for operations on a target composite object in the canvas, wherein the target composite object includes a rendering area and a text editing area; Deploy a unified permission verification middleware layer between the rendering engine and the editor, and route the operation instructions to the unified permission verification middleware layer; The unified permission verification middleware synchronously parses the rendering operation type and text editing operation type corresponding to the operation instruction, and queries the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain the unified permission verification conclusion. An operation control token is generated based on the unified permission verification result. The operation control token includes permission identification information and operation type identification information. Based on the permission identification information in the operation control token, differentiated operation execution strategies are issued to the rendering engine and the editor respectively. The rendering engine performs rendering control on the rendering area according to the corresponding operation execution strategy, and the editor performs editing control on the text editing area according to the corresponding operation execution strategy, so that the rendering engine and the editor can collaboratively perform permission management based on the same operation control token.

[0021] In one optional embodiment, a unified permission verification middleware layer is deployed between the rendering engine and the editor, and the operation instructions are routed to the unified permission verification middleware layer, including: The interface feature difference information is obtained by analyzing the instruction receiving interface features of the rendering engine and the editor. Based on the interface feature difference information, a unified permission verification middleware is inserted between the rendering engine and the editor. The input port and output port of the unified permission verification middleware are configured. The input port receives the operation instructions, and the output port includes a rendering output sub-port and an editing output sub-port. A permission verification logic template is loaded in the unified permission verification intermediate layer. The permission verification logic template includes rendering operation verification rules and editing operation verification rules. Establish a first communication link between the unified permission verification middleware layer and the rendering engine, and a second communication link between the unified permission verification middleware layer and the editor; Based on the link status information of the first communication link and the second communication link, and the permission verification logic template, the routing rules of the unified permission verification intermediate layer are configured so that the operation instruction enters the unified permission verification intermediate layer through the input port according to the routing rules, and is routed to the corresponding instruction receiving interface through the rendering output sub-port or the editing output sub-port according to the operation type identifier corresponding to the operation instruction.

[0022] In one specific implementation, the rendering engine and the editor often employ different technical architectures and interface specifications. The rendering engine is typically designed based on a graphics library interface, and its command receiving interface is characterized by receiving data structures containing graphics rendering elements such as vertex coordinates, texture mapping, and lighting parameters. Specific interface characteristics include interface call protocol type, data encapsulation format, command priority identifier, and callback mechanism type. The editor's command receiving interface, on the other hand, focuses on text processing capabilities, receiving data structures containing editing elements such as cursor position, text content, formatting attributes, and selection range. Its interface characteristics encompass text encoding methods, editing event types, undo / redo mechanism identifiers, and collaborative editing protocols.

[0023] To achieve unified management of the two types of interfaces, a deep analysis of the instruction receiving interface characteristics of the rendering engine and the editor is required. This analysis is accomplished through interface probing technology, specifically using interface reflection to obtain interface signature information, including parameter type sequences, return value types, and exception handling mechanisms. For the rendering engine, method signatures related to graphics operations are extracted, identifying interface feature identifiers for categories such as drawing instructions, transformation instructions, and state setting instructions. For the editor, method signatures related to text operations are extracted, identifying interface feature identifiers for categories such as insert instructions, delete instructions, and formatting instructions. By comparing and analyzing the parameter structure, call sequence, and state dependencies of the two types of interfaces, interface feature differences are obtained. This difference information includes comparison results across three dimensions: interface protocol differences, data format differences, and calling convention differences.

[0024] Based on the differences in interface characteristics, a unified permission verification middleware layer is inserted into the data path between the rendering engine and the editor. The middleware layer is deployed using a proxy interception model, adding an interception node to the existing command transmission path. This node is located between the user's command initiator and the rendering engine / editor receiver. The insertion of the middleware layer does not modify the original code logic of the rendering engine and editor; instead, it redirects the command flow that would normally go directly to the rendering engine or editor to the middleware layer by configuring the system's command routing table.

[0025] The input port of the unified permission verification middleware layer is configured as a general command receiving port. This port is designed as a universal interface compatible with multiple command encapsulation formats, capable of recognizing and receiving various operation commands for target composite objects. After entering the input port, the operation commands first undergo command unpacking to extract core elements such as operation type identifier, target object identifier, and operation parameter set. The output port configuration is differentiated based on interface feature differences, including two types of dedicated ports: rendering output sub-ports and editing output sub-ports. The rendering output sub-port adapts to the rendering engine's interface specification, converting the general command format into a graphics command format that the rendering engine can recognize. The conversion process includes data structure mapping, parameter type conversion, and interface protocol adaptation. The editing output sub-port adapts to the editor's interface specification, converting the general command format into an editing command format that the editor can recognize. The conversion process includes text encoding conversion, editing event encapsulation, and format attribute mapping.

[0026] The loading of the permission verification logic template provides the middleware with the basis for permission determination. The permission verification logic template is built using rule engine technology and contains two core rule sets: rendering operation verification rules and editing operation verification rules. Rendering operation verification rules define permission constraints for graphics rendering operations. The rule structure includes operation type matching conditions, user role determination conditions, and resource access restriction conditions. Specifically, for drawing operations, the rules define the user role types allowed to perform the operation, such as creator, collaborator, and viewer roles, and also define the range of rendering resources that the operation can access, such as specific layers or specific canvas areas. For transformation operations, the rules define permission boundaries for geometric transformations, such as scaling range, rotation angle limits, and translation distance constraints. Editing operation verification rules define permission constraints for text editing operations. The rule structure includes editing action type matching conditions, editing range restriction conditions, and content modification permission conditions. For insertion operations, the rules define the user permission level allowed for inserting content, as well as the format type restrictions for insertable content. For deletion operations, the rules define author authentication conditions for allowing deletion of content, and the time window limit for deletion operations.

[0027] A first communication link is established between the unified permission verification middleware layer and the rendering engine. This link employs a bidirectional data channel design. The forward channel transmits permission-verified rendering commands from the middleware layer to the rendering engine, while the reverse channel sends status feedback information from the rendering engine back to the middleware layer. The establishment process of the first communication link includes three phases: link initialization, handshake verification, and parameter negotiation. In the link initialization phase, the middleware layer sends a link establishment request to the rendering engine, which includes the middleware layer's identity, protocol version information, and communication parameter configurations. In the handshake verification phase, the rendering engine verifies the legitimacy of the middleware layer's identity. Upon successful verification, it returns an acknowledgment response, which includes the rendering engine's interface version information, a list of supported command types, and status feedback mechanism configurations. In the parameter negotiation phase, the middleware layer and the rendering engine agree on configurations for parameters such as communication timeout duration, data packet size limits, and error retransmission strategies.

[0028] A second communication link is established between the unified permission verification middleware layer and the editor. This link also adopts a bidirectional data channel design, with the forward channel transmitting editing commands and the reverse channel transmitting editor status information. The establishment process of the second communication link is similar to that of the first communication link, including link initialization, authentication, and protocol negotiation. Considering the real-time requirements of the editor, the second communication link adopts a shorter timeout setting and a finer data transmission granularity in parameter configuration to ensure that the response latency of editing operations meets user experience requirements.

[0029] After the communication link is established, the link status information of the first and second communication links is obtained. This link status information includes parameters such as link connection status, data transmission rate, link latency, and link reliability metrics. The link connection status indicates whether the link is currently in a normal communication state; status values ​​include connected, disconnected, and reconnected. The data transmission rate reflects the link's throughput capacity and is calculated by statistically analyzing the amount of data transmitted per unit time. The link latency is obtained by measuring the time interval between the issuance of a command from the intermediate layer and the receipt of an acknowledgment response; this parameter directly affects the real-time performance of the operation response. The link reliability metrics are obtained through a comprehensive evaluation of indicators such as packet loss rate and number of erroneous retransmissions.

[0030] Based on the link status information of the first and second communication links, and the permission verification logic template, routing rules for the unified permission verification middleware layer are configured. The routing rules define the distribution logic of operation instructions in the middleware layer. Rule configuration includes elements such as routing condition determination, target port selection, instruction format conversion, and exception handling mechanisms. Routing condition determination is based on the operation type identifier in the operation instruction. The operation type identifier is obtained by parsing the instruction header information, and the identifier value includes rendering-type operation identifiers and editing-type operation identifiers. When the operation type identifier is a rendering-type operation identifier, the routing rule marks the instruction as needing to be routed to the rendering engine. At this time, the routing rule further checks the link status information of the first communication link. If the link status is connected and the link latency is lower than a preset threshold, the instruction is sent to the rendering engine via the rendering output sub-port. When the operation type identifier is an editing-type operation identifier, the routing rule marks the instruction as needing to be routed to the editor. The routing rule checks the link status information of the second communication link, and after meeting the link availability conditions, sends the instruction to the editor via the editing output sub-port.

[0031] The routing rules also integrate permission verification logic templates, performing permission verification before instruction routing. The specific execution process is as follows: After an operation instruction enters the unified permission verification middleware layer via the input port, it first triggers the permission verification process. This process loads the corresponding verification rules based on the operation type identifier; rendering operations are loaded with rendering operation verification rules, and editing operations are loaded with editing operation verification rules. The permission verification process extracts user identity information, target object information, and operation parameter information from the operation instruction and matches them with the permission constraints in the verification rules. If the matching result indicates permission is allowed, the operation instruction continues with subsequent routing; if the matching result indicates permission is denied, the middleware layer generates a permission denial response and returns it to the operation instruction initiator via a reverse channel, simultaneously terminating the routing of the instruction.

[0032] For composite instructions containing mixed operation types, the routing rules employ an instruction splitting strategy, dividing the composite instruction into rendering sub-instructions and editing sub-instructions. The splitting process is based on the set of operation parameters in the operation instruction. Parameters related to graphic rendering elements are assigned to the rendering sub-instruction's parameters, and parameters related to text editing elements are assigned to the editing sub-instruction's parameters. The split rendering and editing sub-instructions each carry the split set of operation parameters and a shared operation transaction identifier. This transaction identifier is used to associate different execution parts of the same composite operation during execution by the rendering engine and editor. Rendering sub-instructions are routed to the rendering engine's instruction receiving interface via the rendering output sub-port, and editing sub-instructions are routed to the editor's instruction receiving interface via the editing output sub-port.

[0033] The routing rule's exception handling mechanism covers various exception scenarios, including link anomalies, permission verification anomalies, and command format anomalies. When a connection interruption is detected in the first or second communication link, the routing rule triggers a link recovery process, which includes link reconnection attempts, backup link switching, and enabling the command cache queue. When an anomaly occurs in the rule matching process within the permission verification logic template, the exception handling mechanism records the anomaly details, continues command routing using the default permission policy, and simultaneously sends an anomaly alarm to the management end. When the format of an operation command does not conform to the general command format specification defined by the middle layer, the routing rule attempts to repair the command format. The repair process includes filling in missing fields, correcting erroneous fields, and format version conversion. If the repair fails, the routing request for the command is rejected, and a format error response is returned.

[0034] With the above configuration, operation commands enter the unified permission verification middle layer through the input port according to the routing rules. Inside the middle layer, a series of processing steps are completed, including operation type identification, permission verification, target port selection, and command format adaptation. Finally, based on the operation type identifier corresponding to the operation command, the command is routed to the corresponding command receiving interface through the rendering output sub-port or editing output sub-port, thereby realizing unified command distribution and permission control for the rendering engine and the editor.

[0035] In one optional embodiment, the unified permission verification intermediate layer synchronously parses the rendering operation type and text editing operation type corresponding to the operation instruction, including: Extract the semantic information of the operation instruction, and identify the operation category to which the operation instruction belongs based on the semantic information. The operation category includes rendering operation category and editing operation category. When the operation instruction belongs to the rendering operation category, the operation instruction is further subdivided according to the rendering operation classification rules to obtain the rendering operation type; When the operation instruction belongs to the operation category of editing operation, the operation instruction is further subdivided according to the editing operation classification rules to obtain the text editing operation type; The rendering operation type and the text editing operation type are structurally encapsulated to obtain operation type description information, which includes operation type identifier and operation scope identifier. The operation type description information is output to the permission query module of the unified permission verification intermediate layer, so that the permission query module can query the corresponding rendering permission verification result and editing permission verification result according to the operation type identifier and the operation scope identifier respectively.

[0036] In one specific implementation, upon receiving a user's operation command on a target composite object in the canvas, the unified permission verification middleware layer needs to perform in-depth parsing of the operation command to accurately identify the rendering operation type and text editing operation type it contains. Since the target composite object simultaneously contains both rendering and text editing areas, a single user operation command may trigger operation requirements for both areas simultaneously. Therefore, a complete operation command parsing mechanism is needed to ensure accurate extraction and classification of operation semantic information.

[0037] Extracting semantic information from operations is the foundation of the entire parsing process. Once an operation instruction enters the unified permission verification middleware layer, its data structure is first deconstructed. Operation instructions typically exist in structured data form, containing core information such as instruction type fields, target object identifier fields, operation parameter fields, and user identifier fields. By extracting and parsing these fields, the basic semantic features of the operation instruction can be obtained. For example, an operation instruction may contain action identifiers such as "modify," "zoom," "drag," "input," and "delete," which constitute the core of the operation's semantic information. Simultaneously, the operation instruction also carries scope information, indicating whether the operation targets a rendering area, a text editing area, or the entire area of ​​a composite object. Using natural language processing techniques or a predefined semantic mapping table, these action identifiers and scope information are converted into standardized operation semantic descriptors.

[0038] Based on the extracted semantic information of the operations, the system needs to identify and determine the operation category. The identification process follows pre-configured operation category determination rules. This rule base defines the determination conditions for rendering and editing operation categories. Rendering operations typically involve the visual control of graphic elements, including but not limited to shape transformation, color adjustment, transparency setting, filter effect application, and layer order adjustment. Editing operations mainly focus on the creation, deletion, modification, and querying of text content, including character insertion, character deletion, text selection, format adjustment, and paragraph layout. By matching the extracted semantic information of the operations with these determination conditions, the operation category to which the operation instruction belongs can be determined. For some complex scenarios, an operation instruction may simultaneously possess the characteristics of both rendering and editing operations. In this case, the system will mark the instruction as a mixed-category operation and further subdivide it into rendering and editing types in subsequent processes.

[0039] Once an operation command is identified as a rendering operation category, it needs to be further subdivided according to the rendering operation classification rules. The rendering operation classification rules are a multi-level classification system that refines rendering operations from coarse-grained classifications to specific operation types. This classification system first divides rendering operations into several main dimensions, such as geometric transformation, visual attribute, special effects processing, and layer management. Under the geometric transformation dimension, it is further subdivided into specific types such as translation, rotation, scaling, and skewing. Under the visual attribute dimension, it is subdivided into types such as fill color modification, border style adjustment, transparency control, and shadow effect settings. Under the special effects processing dimension, it is subdivided into types such as blur effect application, sharpening effect application, and color filter application. Under the layer management dimension, it is subdivided into types such as layer up, layer down, layer on top, and layer on bottom. By analyzing the action and parameter features in the semantic information of the operation, the system maps the operation command to a specific location in this multi-dimensional classification system, thereby obtaining an accurate rendering operation type identifier. For example, when an operation instruction includes a "scaling" action and is applied to a graphic bounding box, the rendering operation type is determined to be "geometric scaling operation" through rule matching.

[0040] Similarly, when an operation command is identified as an editing operation category, the text editing operation type is further subdivided according to the editing operation classification rules. The editing operation classification rules also adopt a multi-dimensional classification architecture. The main dimensions include content operation, formatting operation, selection operation, and navigation operation. Under the content operation dimension, it is subdivided into character insertion, character deletion, character replacement, text pasting, and text cutting operations; under the formatting operation dimension, it is subdivided into font setting, font size adjustment, text bolding, text italics, text color modification, and paragraph alignment operations; under the selection operation dimension, it is subdivided into single character selection, word selection, paragraph selection, and full-text selection; under the navigation operation dimension, it is subdivided into cursor movement, scrolling, and navigation. Through in-depth analysis of the text-related parameters in the operation command, such as cursor position, selection range, and formatting parameters, the operation is mapped to a specific node in the editing operation classification rule, resulting in a clear text editing operation type. For example, when an operation command carries cursor position information and new character data, its text editing operation type is determined to be "character insertion operation."

[0041] After identifying rendering and text editing operation types, the system needs to structurally encapsulate this information to generate unified operation type descriptions. This structural encapsulation process organizes the scattered operation type data into a standardized data structure containing several key fields. The operation type identifier field uniquely identifies the specific operation type using a hierarchical coding method. For example, rendering operations use "R" as a prefix, and editing operations use "E" as a prefix, followed by a numerical code indicating the specific type, such as "R-01-03" representing "geometric transformation - scaling operation". The operation scope identifier field clarifies the scope of the operation, indicating whether it applies to the entire object, a specific layer, a specific text paragraph, or a selected area. Furthermore, the operation type description includes a priority identifier to determine the processing order when multiple operation types exist; a dependency identifier to indicate whether the operation depends on the results of other operations; and a mutual exclusion identifier to indicate which operation types it conflicts with. This structural encapsulation transforms potentially scattered and inconsistently formatted operation type information into standardized descriptive data, facilitating subsequent processing by the permission query module.

[0042] The generated operation type description information is then output to the permission query module of the unified permission verification middleware. The permission query module is a dedicated component responsible for permission information retrieval and matching, internally maintaining a permission rule base and a permission mapping table. Upon receiving the operation type description information, the permission query module first locates the corresponding permission check rule in the permission rule base based on the operation type identifier. For each rendering operation type, the permission rule base defines the required permission level, applicable user role range, and possible restrictions, such as time limits and resource limits, for each specific rendering operation. Based on the current user's identity information, role information, and user group information, combined with the operation type identifier and operation scope identifier, the permission query module searches the permission mapping table for the user's permission configuration items within the specified scope for that rendering operation type. The query process employs a multi-level indexing mechanism: first, it quickly locates the user's permission configuration based on the user identifier; then, it filters out relevant permission items based on the operation type identifier; and finally, it performs precise matching based on the operation scope identifier to obtain the rendering permission verification result.

[0043] For text editing operations, the permission query module performs a similar query process, but based on the permission rules related to the editing operation. These rules are often more detailed, considering not only the operation type itself but also factors such as the sensitivity level of the text content, the document's collaboration status, and the locking status of the editing history. The permission query module uses a multi-condition joint query to comprehensively evaluate the user's execution permission for that text editing operation type, obtaining the editing permission verification result. Both permission verification results are returned in a structured format, including permission status (allowed, prohibited, conditionally allowed), permission level, and description of the restrictions, providing an accurate data foundation for subsequent permission consistency comparisons.

[0044] The entire parsing process transforms raw operation commands into structured operation type descriptions, and the permission query module performs parallel queries for rendering and editing permissions. This synchronous parsing mechanism ensures that the unified permission verification middleware can simultaneously obtain both types of permission verification results within a single command processing flow, laying a solid foundation for collaborative permission management between the rendering engine and the editor. Through deep extraction of operation semantics, multi-dimensional operation classification, standardized information encapsulation, and efficient permission queries, the system can accurately identify user intent, precisely determine permission boundaries, and effectively support fine-grained permission management needs in complex object scenarios.

[0045] In one optional embodiment, the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type are queried respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain a unified permission verification conclusion, including: Based on the rendering operation type, query the rendering permission configuration information corresponding to the rendering area; based on the text editing operation type, query the editing permission configuration information corresponding to the text editing area. The rendering permission configuration information and the editing permission configuration information are compared in terms of permission status to detect the status difference information between the rendering permission configuration information and the editing permission configuration information; The state difference information is used to determine conflicts according to the preset permission consistency rules. When the state difference information meets the conflict conditions in the permission consistency rules, permission conflict marker information is generated. When the state difference information does not meet the conflict condition, permission fusion information is generated based on the rendering permission configuration information and the editing permission configuration information. The permission conflict marker information or the permission fusion information is output as the unified permission verification conclusion to the conclusion generation module of the unified permission verification intermediate layer, so that the conclusion generation module controls the generation logic of subsequent operation control tokens based on the unified permission verification conclusion.

[0046] In one specific implementation, during the permission verification process, the unified permission verification middleware layer needs to query permission configuration information for both rendering operation types and text editing operation types. For rendering operation types, the unified permission verification middleware layer retrieves the rendering permission configuration information bound to the rendering area from the permission configuration database. This configuration information records the permission status for different rendering operations, including status indicators such as allowed, prohibited, and restricted. The permission configuration database adopts a multi-dimensional index structure, using operation type, user role, and object identifier as a composite index key to ensure that the query response time is controlled within 10 milliseconds. When querying rendering permission configuration information, the unified permission verification middleware layer parses the rendering operation type field in the operation instruction, combines the value of this field with the current user's role identifier and the unique identifier of the target composite object, and sends a query request to the permission configuration database. The rendering permission configuration information returned by the permission configuration database adopts a structured data format, including fields such as operation type code, permission status identifier, constraint condition set, and effective time range.

[0047] For text editing operations, the unified permission verification middleware also retrieves the editing permission configuration information bound to the text editing area from the permission configuration database. The permission configuration for the text editing area employs an independent configuration strategy, which considers factors such as the sensitivity level of the text content, user role relationships in collaborative editing scenarios, and editing history. The editing permission configuration information includes detailed permission items such as editing mode permissions, format modification permissions, content deletion permissions, and annotation addition permissions. When querying the editing permission configuration information, the unified permission verification middleware also needs to obtain the metadata information of the text editing area, including the owner identifier, sharing status identifier, and version control information of the text block. This metadata information, together with the editing permission configuration information, constitutes a complete editing permission configuration information data structure.

[0048] After obtaining the rendering permission configuration information and the editing permission configuration information, the unified permission verification middleware initiates a permission status comparison process. The comparison process uses a field-by-field comparison, sequentially comparing the permission status identifiers in the two types of permission configuration information. When the permission status identifier for a certain operation in the rendering permission configuration information is "allowed," while the corresponding operation's permission status identifier in the editing permission configuration information is "prohibited," the comparison module records this status difference information. Status difference information is represented using a difference vector, where each dimension of the vector corresponds to a specific permission item, and the dimension value represents the difference type. Difference types include completely identical, conflict between allowed and prohibited, conflict between allowed and restricted, and conflict between prohibited and restricted. The comparison module iterates through all permission items and summarizes the detected difference information into a status difference information set.

[0049] After the set of state difference information is generated, the unified permission verification middleware layer calls the conflict determination module to determine conflicts in the state difference information. The conflict determination module maintains a set of preset permission consistency rules, which define the conflict conditions corresponding to various types of state difference information. The permission consistency rules are represented using a condition-action pattern, with each rule containing a conditional expression and a corresponding processing action. Typical conflict conditions include: rendering permission is allowed but editing permission is prohibited; editing permission is allowed but rendering permission is restricted, and the constraints logically contradict the editing operation; both parties have restricted permissions, but the constraint sets have irreconcilable conflicts, etc. The conflict determination module matches each difference item in the set of state difference information with the conflict conditions in the set of permission consistency rules, using a pattern matching algorithm to calculate the similarity between the difference item and the conflict condition. When the similarity exceeds a preset threshold of 0.85, the difference item is considered to meet the conflict condition.

[0050] When a conflict-prone item is detected in the status difference information, the conflict determination module generates permission conflict marker information. The permission conflict marker information uses a structured data format and includes fields such as conflict type code, conflict details description, involved permission item identifiers, and conflict severity level. The conflict type code uses a three-digit encoding method, with the first digit indicating the major category of the conflict and the last two digits indicating the specific sub-type. The conflict details description field records the specific manifestation of the conflict in natural language, facilitating subsequent conflict handling and user prompts. The involved permission item identifier field lists all participating permission items in array form, with each permission item identifier including the permission item name, its permission configuration type, and permission status value. The conflict severity level field uses a four-level classification, including fatal conflict, severe conflict, general conflict, and minor conflict; this level affects the selection of subsequent conflict handling strategies.

[0051] When the state difference information does not meet the conflict conditions, the unified permission verification middleware initiates the permission fusion process. The permission fusion process integrates rendering permission configuration information and editing permission configuration information based on a permission priority strategy. The permission priority strategy defines the permission state selection rules in non-conflict situations, including the least permission principle, the maximum permission principle, the rendering priority principle, and the editing priority principle. The least permission principle requires that when there are differences in the permission states of the two types of permission configuration information, the more restrictive permission state is selected as the fusion result. The maximum permission principle selects the more lenient permission state as the fusion result. The rendering priority principle and the editing priority principle take rendering permission configuration information or editing permission configuration information as the basis, respectively, and prioritize the adoption of the specific type of permission configuration when differences exist.

[0052] The permission fusion module processes the differences in the status difference information set item by item according to the selected permission priority strategy. For each difference, the fusion module extracts the permission status value of the corresponding permission item from the rendering permission configuration information and the editing permission configuration information, and applies the permission priority strategy to determine the fused permission status value. The fused permission status value, along with the permission item identifier, applicable scope identifier, constraint set, and other information, is recorded in the permission fusion information data structure. The permission fusion information uses the same data format as the permission configuration information to ensure that subsequent modules can seamlessly process the fusion result. For permission items that do not differ in the status difference information set, the permission fusion module directly copies the original permission configuration information into the permission fusion information, keeping the configuration of these permission items unchanged.

[0053] During the permission merging process, the merging module needs to handle the merging of constraint sets with special care. Constraints in rendering permission configuration information and editing permission configuration information may use different representations. The merging module first standardizes the format of the constraints, converting constraints of different formats into a unified internal representation. After standardization, the merging module logically merges the two sets of constraints, using logical AND or logical OR operations to combine the constraints. The merging strategy is determined based on the permission priority strategy: the least privilege principle corresponds to the logical AND operation, requiring both types of constraints to be satisfied simultaneously; the maximum privilege principle corresponds to the logical OR operation, requiring only that either type of constraint be satisfied.

[0054] Regardless of whether permission conflict flags or permission fusion information are generated, the unified permission verification middleware outputs them as unified permission verification conclusions to the conclusion generation module. The unified permission verification conclusion uses a standardized data encapsulation format, including fields such as conclusion type identifier, conclusion content data, generation timestamp, and verification process identifier. The conclusion type identifier distinguishes between permission conflict conclusions and permission fusion conclusions. The conclusion content data field includes permission conflict flags or permission fusion information depending on the conclusion type. The generation timestamp records the generation time of the unified permission verification conclusion for subsequent audit tracing and cache management. The verification process identifier records the intermediate processing steps involved in this permission verification, facilitating problem localization and process optimization.

[0055] After receiving the unified permission verification conclusion, the conclusion generation module determines the subsequent operation control token generation logic based on the conclusion type identifier. When the conclusion type is a permission conflict conclusion, the conclusion generation module calls the conflict handling logic, and determines whether to generate an operation control token and its specific content based on the conflict severity level and conflict type in the permission conflict flag information. For fatal and severe conflicts, the conclusion generation module directly generates an operation control token containing a denial identifier to prevent subsequent operations from being executed. For general and minor conflicts, the conclusion generation module may generate an operation control token containing a warning identifier, allowing the operation to be executed in restricted mode, while sending a permission conflict warning message to the user. When the conclusion type is a permission fusion conclusion, the conclusion generation module calls the normal token generation logic, and generates an operation control token containing the corresponding permission identifier based on the fused permission status in the permission fusion information, ensuring that the rendering engine and editor can execute operations according to the unified permission configuration.

[0056] like Figure 2 The diagram shown illustrates the logic flowchart for permission verification and distribution.

[0057] In an optional embodiment, an operation control token is generated based on the unified permission verification conclusion. The operation control token includes permission identification information and operation type identification information, including: Parse the permission status information in the unified permission verification conclusion to obtain the rendering permission status identifier and the editing permission status identifier; A permission identifier field is generated based on the rendering permission status identifier and the editing permission status identifier, and an operation type identifier field is generated based on the rendering operation type and the text editing operation type; The permission identifier field and the operation type identifier field are written into a token data structure. The token data structure includes a token header area and a token payload area. The token header area stores the permission identifier field, and the token payload area stores the operation type identifier field. Configure time-limited attribute information for the operation control token, the time-limited attribute information including the token's effective time and the token's expiration time; The operation control token configured with the timeliness attribute information is output to the permission control distribution module, so that the permission control distribution module distributes the corresponding operation control strategy to the rendering engine and the editor according to the permission identifier field and the operation type identifier field.

[0058] In one specific implementation, after the unified permission verification middleware completes the permission comparison and obtains the unified permission verification conclusion, it needs to convert the conclusion into a transferable and executable operation control token. This token needs to carry not only permission determination information but also operation type information so that the rendering engine and the editor can perform differentiated operations based on the same credential.

[0059] The unified permission verification conclusion includes a comparison of the rendering permission verification result and the editing permission verification result. This information is stored in a structured form within the verification conclusion data body. Before generating the operation control token, the verification conclusion needs to be deeply parsed to extract the core permission status information. Specifically, the parsing module reads the permission judgment result for the rendering operation from the unified permission verification conclusion data structure. This result may be represented as a status enumeration value such as "Allow," "Deny," or "Partially Allow." Simultaneously, the permission judgment result for the text editing operation is extracted from the same data structure. This result also exists in a standardized status enumeration form. After parsing, the permission judgment result for the rendering operation is mapped to a rendering permission status identifier, and the permission judgment result for the text editing operation is mapped to an editing permission status identifier. These two identifiers use a standardized encoding method, such as binary bit representation, where a specific bit value represents a specific permission status, or a predefined status code representation, where integer values ​​correspond to different permission levels.

[0060] After obtaining the rendering permission status flag and the editing permission status flag, this flag information needs to be encapsulated into a token-recognizable field format. The generation of the permission flag field needs to consider information compression and scalability. A bit-field combination method can be used to merge the rendering permission status flag and the editing permission status flag into the same field according to a preset bit offset. For example, if a 32-bit integer is used to represent the permission flag field, the lower 16 bits can be allocated to the rendering permission status flag, and the higher 16 bits to the editing permission status flag. Each flag can be further subdivided into permission level bits, operation range bits, and constraint condition bits. In the specific implementation, assume the rendering permission status flag is... The edit permission status is indicated as follows: Then the permission identifier field It can be represented as "will" and The combination of bitwise operations ensures that the two independent permission status information can be separated without loss during subsequent parsing.

[0061] Generated in parallel with the permission identifier field is the operation type identifier field, which needs to carry information about both the rendering operation type and the text editing operation type. Rendering operation types may include various types such as drawing graphics, applying filters, and adjusting layer properties, each of which can be represented by a unique identifier code. Text editing operation types cover operations such as inserting text, deleting text, modifying styles, and adjusting layout, also presented in the form of identifier codes. The construction of the operation type identifier field adopts a composite encoding strategy, concatenating or combining the rendering operation type identifier and the text editing operation type identifier according to the format specified in the protocol. One implementation method is to use segmented encoding, dividing the operation type identifier field into an operation domain type segment and an operation subtype segment. The operation domain type segment indicates whether the current operation belongs to the rendering domain or the editing domain, while the operation subtype segment refines the specific operation type. Another implementation method is to use an enumeration array, storing the identifier codes of all operation types participating in the current composite operation sequentially into the array structure. Each element of the array corresponds to an operation type identifier, and specific operation type information can be quickly located through array indexing.

[0062] After generating the permission identifier field and operation type identifier field, these fields need to be written into a predefined token data structure. This token data structure uses a partitioned storage design, containing two logical partitions: a token header area and a token payload area. The token header area is specifically used to store frequently accessed fields with high security requirements; the permission identifier field is placed in this area. The header area uses a fixed-length storage format to ensure fast reading and verification. Specifically, in addition to the permission identifier field, the header area may also include a token version number field, an encryption algorithm identifier field, and a checksum field. The permission identifier field typically occupies the first few bytes of the header area, and its storage offset and length information are explicitly defined in the token protocol specification. The token payload area is used to store the operation type identifier field and other auxiliary information. This area uses a variable-length design, dynamically adjusting the storage space according to the complexity of the operation type. The operation type identifier field in the payload area can be organized as key-value pairs or a nested structure, depending on the hierarchical complexity of the operation type information. During the writing process, the byte sequence of the permission identifier field is first written to the specified offset position in the token header area, and then the serialized data of the operation type identifier field is written to the token payload area. After the writing operation is completed, the integrity of the entire token data structure is checked to ensure that the data has not been truncated or damaged.

[0063] After the token data structure is populated, the operation control token needs to be configured with expiration attribute information to prevent the token from being held for a long time or illegally reused. The expiration attribute information includes two timestamp parameters: the token's effective time and the token's expiration time. The token's effective time indicates when the token can be accepted and executed by the rendering engine and editor, usually set to the token's generation time or a later time to accommodate clock synchronization delays in distributed systems. The token's expiration time indicates when the token will no longer be valid; an expired token, even if intact in its data structure, will be rejected by the permission verification mechanism. The expiration duration setting needs to consider both the expected completion time of the operation and security requirements. For rendering operations with high real-time requirements, the expiration duration can be set to several seconds to tens of seconds; for operations that may involve complex editing processes, the expiration duration can be extended to several minutes. The configuration of the expiration attribute information is achieved by writing specific timestamp fields into the token data structure. These timestamp fields are usually stored in fixed locations in the token header or payload area. The timestamps use standardized time representation formats, such as Unix timestamps or ISO 8601 format, to ensure consistent understanding of time information across different system components. When writing the validity period attribute, the token generation module obtains the current system time as the base time. The token takes effect at the time set to ,in This is the activation delay; the token expiration time is set to... ,in This is the validity period. These two timestamp values ​​are serialized and written to the corresponding fields of the token data structure.

[0064] After configuring the validity period attributes, the generated operation control token needs to be transmitted to the permission control distribution module for further distribution. The process of outputting the fully configured operation control token to the permission control distribution module involves token encapsulation and transmission. Token data can be serialized into a byte stream or structured object and transmitted to the permission control distribution module via shared memory, message queues, or network communication. Before transmission, the token data can be signed or encrypted to enhance its tamper-proof properties during transmission. Upon receiving the operation control token, the permission control distribution module first performs a preliminary check on the token's integrity and validity, including verifying the checksum in the token header, checking if the validity period attributes are within a valid range, and confirming the correct format of the permission identifier field and the operation type identifier field. After successful verification, the permission control distribution module determines which target components need to receive the operation control policy based on the permission identifier field and the operation type identifier field in the token. Specifically, by parsing the rendering permission status identifier and editing permission status identifier in the permission identifier field, the distribution module determines which operation control policy the rendering engine and the editor should each receive. If the rendering permission status indicates "allowed," an allowance policy configuration is distributed to the rendering engine; if it indicates "denied" or "restricted," a restriction policy configuration is distributed. Simultaneously, based on the information in the operation type identifier field, the distribution module appends the policy parameters corresponding to the specific operation type to the distribution message, enabling the rendering engine and editor to adjust their execution behavior according to the operation type. This differentiated distribution mechanism based on a unified token achieves consistency between the rendering engine and the editor at the permission control level, ensuring that the permission status of composite objects remains synchronized in graphics rendering and text editing operations, avoiding inconsistencies that may arise from two subsystems independently determining permissions in traditional architectures.

[0065] In one optional embodiment, based on the permission identification information in the operation control token, differentiated operation execution strategies are issued to the rendering engine and the editor respectively, including: Parse the permission identifier field in the operation control token to obtain the rendering operation permission status corresponding to the rendering engine and the editing operation permission status corresponding to the editor. A rendering operation execution strategy is generated based on the rendering operation permission status. The rendering operation execution strategy includes a set of allowed operations and a set of prohibited operations. An editing operation execution policy is generated based on the editing operation permission status, and the editing operation execution policy includes a set of allowed editing operations and a set of prohibited editing operations; The rendering operation execution strategy is encapsulated into a rendering control instruction package, and the editing operation execution strategy is encapsulated into an editing control instruction package. The rendering control instruction package contains the rendering operation permission status, and the editing control instruction package contains the editing operation permission status. The rendering control instruction package is sent to the rendering engine through the first communication link, and the editing control instruction package is sent to the editor through the second communication link, so that the rendering engine performs rendering operation filtering according to the rendering control instruction package, and the editor performs editing operation filtering according to the editing control instruction package.

[0066] In one specific implementation, upon receiving the operation control token, the unified permission verification middleware layer needs to perform detailed parsing of the permission identifier field to determine the operation permission status for different execution components. The permission identifier field typically uses structured encoding, containing multiple binary bits or enumerated values, with each bit segment corresponding to different permission dimensions for the rendering engine and editor. During parsing, the rendering permission portion of the identifier field is first extracted, which may include permission status for operations such as scaling, rotation, translation, and color adjustment. Through bitmask operations or field matching mechanisms, the rendering permission portion is mapped to a rendering operation permission status, which clearly identifies the current user's scope of operation permissions for the rendering area. Simultaneously, the editing permission portion of the identifier field is extracted, which covers permission information for editing operations such as text insertion, deletion, formatting adjustments, and style modifications. Using the same parsing mechanism, the editing permission portion is converted into an editing operation permission status, reflecting the user's authorized scope of operations for the text editing area.

[0067] After obtaining a rendering operation permission status, a specific rendering operation execution strategy needs to be generated based on this status. The core of the rendering operation execution strategy lies in establishing clear boundaries between the allowed and prohibited operation sets. The allowed operation set includes all rendering operation types that the user can legally execute under the current permission status. For example, when a user has read-only permissions, the allowed operation set might include operations that do not change the graphic content, such as canvas scaling, view panning, and layer display switching; when the user has edit permissions, the allowed operation set expands to include content-modifying operations such as moving, transforming, color modification, and adding effects to graphic objects. The prohibited operation set explicitly lists the rendering operation types that are not allowed under the current permission status. For example, under read-only permissions, the prohibited operation set includes all operations involving modification of graphic content; under partial edit permissions, it might prohibit sensitive graphic deletion, layer structure adjustment, and other advanced operations. The definitions of these two sets need to ensure completeness and mutual exclusivity, meaning that any rendering operation type must belong to one and only one set, avoiding ambiguities in permission determination.

[0068] For editing operation permission status, corresponding editing operation execution policies also need to be generated. The construction logic of the editing operation execution policy is similar to that of the rendering operation execution policy, but the focus is on the operation classification in the text editing domain. The set of allowed editing operations is determined according to the editing operation permission status, and may include basic operations such as viewing text content, cursor positioning, and text selection. With editing permissions, it may also include content editing operations such as character input, text deletion, paragraph formatting adjustment, font style modification, and hyperlink insertion. The set of prohibited editing operations includes editing operations that are not allowed to be executed under the current permissions. For example, all content modification operations may be prohibited in read-only mode, and advanced editing functions such as format clearing, batch replacement, and macro command execution may be prohibited in restricted editing mode. The granular design of the editing operation execution policy needs to consider the actual functional modules of the text editor to ensure that the policy can cover all operation entry points provided by the editor, including multiple triggering methods such as keyboard input, right-click menu, toolbar buttons, and shortcut keys.

[0069] After the strategy is generated, the rendering operation execution strategy needs to be encapsulated into a rendering control instruction package. The rendering control instruction package uses a structured data format and typically includes an instruction header, permission status field, operation set field, and verification field. The instruction header identifies the type and version information of the instruction package, ensuring that the rendering engine can correctly identify and parse it. The permission status field directly embeds the raw value of the rendering operation's permission status, serving as the basis for the rendering engine to quickly determine permissions. The operation set field contains a detailed list of allowed and prohibited operations; operation types can be represented using enumeration values, opcodes, or operation identifiers, ensuring that the rendering engine can accurately match user-triggered operations with the definitions in the strategy. The verification field typically contains a digital signature or hash value to ensure that the instruction package has not been tampered with during transmission, maintaining the security of permission control. The encapsulation process may also add metadata such as timestamps and token identifiers to facilitate subsequent auditing, traceability, and anomaly diagnosis.

[0070] The editing operation execution strategy also needs to be encapsulated as an editing control instruction package. The structure of the editing control instruction package should be consistent with that of the rendering control instruction package, including an instruction header, a permission status field, an operation set field, and a validation field. The permission status field embeds the editing operation permission status, and the operation set field contains the complete definition of the allowed and prohibited editing operations. Since text editor operations may involve finer-grained classifications, such as distinguishing between character-level editing, word-level editing, paragraph-level editing, and formatting-level editing, the operation set field of the editing control instruction package needs to support hierarchical or grouped representations to facilitate accurate matching by the editor based on the actual triggered editing operation. The encapsulation of the instruction package also needs to consider the editor's parsing capabilities, ensuring that the data format is compatible with the editor's interface protocol to avoid strategy application failures due to format mismatches.

[0071] After the instruction package is encapsulated, it needs to be sent to its respective execution component through an independent communication link. A unified permission verification middleware layer maintains a first communication link and a second communication link. The first communication link is dedicated to communication with the rendering engine, and the second communication link is dedicated to communication with the editor. This isolation design of the communication links ensures that the rendering control instruction package and the editing control instruction package will not interfere with each other during transmission, and also facilitates differentiated performance optimization and security hardening of different communication links. When sending the rendering control instruction package to the rendering engine through the first communication link, communication mechanisms such as message queues, remote procedure calls, or event buses may be used to ensure that the instruction package is delivered to the rendering engine in a timely and reliable manner. After receiving the rendering control instruction package, the rendering engine parses the rendering operation permission status and operation set information within it, updates its internal permission state machine, and performs rendering operation filtering accordingly.

[0072] During the execution of rendering operation filtering, the rendering engine listens for all user actions triggered on the rendering area, including mouse clicks, drags, wheel zooms, and keyboard shortcuts. For each triggered operation, the rendering engine first identifies its operation type and then queries the operation set definition in the rendering control instruction package. If the operation type belongs to the allowed operation set, the rendering engine executes the corresponding rendering logic normally and updates the canvas display state; if the operation type belongs to the prohibited operation set, the rendering engine blocks the execution of the operation, possibly sending an insufficient permission message to the user interface or simply ignoring the operation request. The implementation of the rendering operation filtering mechanism needs to be integrated at the rendering engine's operation scheduling level to ensure that all operation entry points are constrained by the policy, preventing bypassing permission checks through unconventional means.

[0073] Simultaneously, an editing control instruction package is sent to the editor via a second communication link. Upon receiving the package, the editor parses the editing operation permission status and operation set information, updating its internal permission control module. During the execution of the editing operation filtering, the editor intercepts all user editing operations on the text editing area, including keyboard input, clipboard operations, drag-and-drop operations, and menu command triggers. For each editing operation request, the editor identifies its operation type, queries the operation set definition in the editing control instruction package, and determines whether the operation belongs to the allowed editing operation set. If the operation is allowed, the editor executes the corresponding text modification logic, updating the text content and display status; if the operation is prohibited, the editor prevents its execution, possibly informing the user of the current permission restrictions through visual feedback or a prompt message. The implementation of the editing operation filtering needs to cover all editing capability modules of the editor, including basic text input, formatting toolbars, right-click context menus, shortcut key mappings, and other multiple operation entry points, ensuring comprehensive and consistent permission control.

[0074] Through the differentiated operation execution strategy distribution and filtering mechanism described above, the rendering engine and editor can independently execute permission control within their respective functional domains. Simultaneously, their control logic originates from the same operation control token, ensuring consistency in permission determination. This architectural design allows different functional areas of composite objects to respond to a unified permission policy, avoiding permission conflicts such as operations allowed in the rendering area but prohibited in the text area, or vice versa, ensuring consistent user experience and predictable system behavior.

[0075] In one optional embodiment, the rendering engine performs rendering control on the rendering area according to a corresponding operation execution strategy, and the editor performs editing control on the text editing area according to a corresponding operation execution strategy, enabling the rendering engine and the editor to collaboratively perform permission management based on the same operation control token, including: The rendering engine receives the rendering control instruction packet and performs permission filtering on the rendering operation requests input to the rendering area according to the set of allowed operations and the set of prohibited operations to obtain the rendering filtering result. The editor receives the editing control instruction package and performs permission filtering on the editing operation requests input to the text editing area according to the allowed editing operation set and the prohibited editing operation set, and obtains the editing filtering result; The rendering filtering result and the editing filtering result are synchronously verified to obtain state consistency information; When the state consistency information indicates that both the rendering filter result and the editing filter result are in an allowed state, the rendering operation request and the editing operation request are executed. When the state consistency information indicates that either the rendering filter result or the editing filter result is in a prohibited state, the corresponding operation request is blocked, and the operation blocking status information is fed back to the unified permission verification intermediate layer to update the permission identification information in the operation control token.

[0076] In one specific implementation, after receiving the rendering control instruction packet from the unified permission verification middleware, the rendering engine first parses the instruction packet to extract the operation control token carried within. This operation control token contains two types of operation scope definitions: a set of allowed operations and a set of prohibited operations. The set of allowed operations explicitly lists the types of rendering operations that can be executed within the current token's scope, such as specific operation type identifiers like geometric transformations, texture updates, lighting parameter adjustments, and viewport transformations. The set of prohibited operations marks unexecutable operation types in the form of a blacklist, such as highly sensitive operations like shader code modification, rendering pipeline reconstruction, and direct framebuffer access. When a user initiates a rendering operation request in the rendering area of ​​the canvas, the request carries an operation type identifier. The rendering engine matches this identifier against both the set of allowed and prohibited operations. The matching process uses a hash table fast lookup mechanism, using the requested operation type identifier as a key to search the allowed set. If the search is successful and the operation type does not appear in the prohibited set, an allowed identifier is generated; if the operation type exists in the prohibited set or is not in the allowed set, a prohibited identifier is generated. This dual matching mechanism ensures the integrity of permission filtering and avoids permission vulnerabilities caused by judging a single set. The rendered filtering results are presented in a structured data format, including operation type identifier, filter status identifier, timestamp information, and complete parameter information of the operation request, providing complete data support for subsequent synchronous verification.

[0077] Simultaneously, the editor receives an editing control instruction package generated from the same operation control token. This package contains a set of allowed editing operations and a set of prohibited editing operations. The set of allowed editing operations defines the types of operations that can be performed within the text editing area, including common editing operations such as character input, text deletion, format modification, paragraph adjustment, and style application. The set of prohibited editing operations restricts operation types with potential security risks, such as rich text script injection, cross-domain content referencing, and embedding external resources. When a user initiates an editing operation request in the text editing area, the editor executes a permission filtering process similar to that of the rendering engine. Specifically, the editor maintains an operation type mapping table, mapping user interactions to standardized editing operation type identifiers. This identifier is then submitted to the permission filtering module for bidirectional matching between the allowed and prohibited editing operation sets. The matching logic employs a priority strategy: first, it checks the prohibited editing operation set; if the operation type is in the blacklist, a prohibited identifier is directly generated; if it is not in the blacklist, it further checks the allowed editing operation set, determining the final filtering result based on whether it matches the allowed list. The edited filter results also include an operation type identifier, a filter status identifier, a timestamp, and specific parameters of the edit operation, such as the edit location, the scope of modification, and the content of the operation.

[0078] After the rendering and editing filtering results are generated, a synchronization verification process is triggered to verify the consistency of their states. This synchronization verification mechanism is executed by a dedicated state coordination module. This module receives the filtering result data streams from the rendering engine and the editor, extracts the filtering state identifiers from both, and performs a logical comparison. State consistency information is generated through logical operations. The specific judgment rule is: the state consistency information is marked as fully allowed only if both the rendering filtering result's state identifier and the editing filtering result's state identifier are allowed. In the actual implementation, the allowed state is represented by the Boolean value `true`, and the prohibited state is represented by the Boolean value `false`. State consistency information is obtained through a logical AND operation. In addition to the state identifiers themselves, the synchronization verification module also compares the timestamp information of the two filtering results to ensure that they are judged based on the same token version and time range, preventing timing inconsistencies caused by token updates. If a timestamp deviation exceeding a preset threshold, such as more than 100 milliseconds, is detected, a token re-verification process is triggered, requiring the rendering engine and editor to re-obtain the latest operation control token and repeat the permission filtering process.

[0079] When the state consistency information indicates that both the rendering filter result and the editing filter result are in an allowed state, it means that the current user operation has execution permissions in both the rendering area and the text editing area. At this time, the state coordination module sends operation permission signals to both the rendering engine and the editor. After receiving the permission signal, the rendering engine submits the user's rendering operation request to the graphics rendering pipeline and processes it according to the standard rendering process. The rendering pipeline executes stages such as vertex shading, rasterization, fragment shading, and depth testing in sequence, and finally updates the rendering result to the framebuffer and presents it in the rendering area of ​​the canvas. Simultaneously, after receiving the permission signal, the editor submits the editing operation request to the text processing engine. The text processing engine executes the corresponding processing logic according to the type of editing operation. For example, for character input operations, it inserts characters at the cursor position and updates the document object model; for format modification operations, it updates the style properties of the target text area and triggers a view redraw. After the operation is completed, the rendering engine and the editor generate operation execution result information, which includes the operation status code, execution timestamp, affected area range, and a snapshot of the object state after the operation. This information is then sent back to the state coordination module for auditing and logging.

[0080] When the state consistency information indicates that either the rendering filter result or the editing filter result is in a prohibited state, it means that the current operation violates at least one permission policy, and an operation blocking process needs to be executed. The operation blocking determination adopts a conservative principle, meaning that as long as a prohibited marker exists in either the rendering filter result or the editing filter result, the entire operation request will not be executed. Specifically, the blocking mechanism is as follows: when a prohibited state is detected, the state coordination module immediately sends an operation termination command to the rendering engine and the editor. After receiving the termination command, the rendering engine removes the pending rendering operation request from the rendering queue, does not submit it to the rendering pipeline, and displays an insufficient permission prompt message to the user in the interface layer. Similarly, the editor cancels the pending editing operation request from the operation queue, prevents the text processing engine from modifying the document object model, and displays a permission-restricted feedback message in the editing interface. Simultaneously with the operation blocking execution, the state coordination module generates operation blocking state information, which records in detail the blocked operation type, blocking reason, blocking timestamp, and detailed permission verification results.

[0081] The operation blocking status information is then fed back to the unified permission verification middleware layer to trigger the token update mechanism. Upon receiving the operation blocking status information, the unified permission verification middleware layer first analyzes the reason for the blocking to determine whether the permission identifier information of the operation control token needs to be adjusted. If the reason for the blocking is that the user's operation exceeds the permission range defined by the current token, the middleware layer keeps the token unchanged and only records the blocking event for subsequent analysis. If the reason for the blocking is that the permission definition of the token itself does not match the actual business needs, such as permission upgrade requirements due to workflow status changes, the middleware layer triggers a permission recalculation process. The recalculation process obtains the latest user role information, the latest object status attributes, and the latest configuration of business rules, re-executes rendering permission verification and editing permission verification, and generates updated unified permission verification conclusions. Based on the new verification conclusions, the middleware layer regenerates the operation control token, updates the allowed operation set, prohibited operation set, allowed editing operation set, and prohibited editing operation set, and sends updated control instruction packages to the rendering engine and editor. The updated token takes effect immediately, and the rendering engine and editor use the new token to filter subsequent operation requests, ensuring real-time synchronization between permission control policies and business status. The entire process forms a closed-loop control mechanism. Through the collaborative work of the rendering engine, editor, and unified permission verification middleware, it ensures that the graphics rendering area and the text editing area maintain consistency and synchronization of permission execution under the same operation control token.

[0082] A second aspect of the present invention provides a system for collaborative management of graphics rendering and text editing permissions, comprising: The instruction acquisition unit is used to acquire user operation instructions for a target composite object in the canvas, wherein the target composite object includes a rendering area and a text editing area. The permission routing unit is used to deploy a unified permission verification middleware layer between the rendering engine and the editor, and to route the operation instructions to the unified permission verification middleware layer. The permission verification unit is used by the unified permission verification middle layer to synchronously parse the rendering operation type and text editing operation type corresponding to the operation instruction, and query the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain the unified permission verification conclusion. The token generation unit is used to generate an operation control token based on the unified permission verification conclusion. The operation control token includes permission identification information and operation type identification information. The strategy execution unit is used to issue differentiated operation execution strategies to the rendering engine and the editor respectively based on the permission identification information in the operation control token. The rendering engine performs rendering control on the rendering area according to the corresponding operation execution strategy, and the editor performs editing control on the text editing area according to the corresponding operation execution strategy, so that the rendering engine and the editor cooperate to perform permission management based on the same operation control token.

[0083] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0084] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0085] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0086] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for collaborative management of graphics rendering and text editing permissions, characterized in that, include: Obtain user commands for operations on a target composite object in the canvas, wherein the target composite object includes a rendering area and a text editing area; Deploy a unified permission verification middleware layer between the rendering engine and the editor, and route the operation instructions to the unified permission verification middleware layer; The unified permission verification middleware synchronously parses the rendering operation type and text editing operation type corresponding to the operation instruction, and queries the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain the unified permission verification conclusion. An operation control token is generated based on the unified permission verification result. The operation control token includes permission identification information and operation type identification information. Based on the permission identification information in the operation control token, differentiated operation execution strategies are issued to the rendering engine and the editor respectively, including: Parse the permission identifier field in the operation control token to obtain the rendering operation permission status corresponding to the rendering engine and the editing operation permission status corresponding to the editor. A rendering operation execution strategy is generated based on the rendering operation permission status. The rendering operation execution strategy includes a set of allowed operations and a set of prohibited operations. An editing operation execution policy is generated based on the editing operation permission status, and the editing operation execution policy includes a set of allowed editing operations and a set of prohibited editing operations; The rendering operation execution strategy is encapsulated into a rendering control instruction package, and the editing operation execution strategy is encapsulated into an editing control instruction package. The rendering control instruction package contains the rendering operation permission status, and the editing control instruction package contains the editing operation permission status. The rendering control instruction package is sent to the rendering engine through the first communication link, and the editing control instruction package is sent to the editor through the second communication link, so that the rendering engine performs rendering operation filtering according to the rendering control instruction package, and the editor performs editing operation filtering according to the editing control instruction package; The rendering engine performs rendering control on the rendering area according to a corresponding operation execution strategy, and the editor performs editing control on the text editing area according to a corresponding operation execution strategy, enabling the rendering engine and the editor to collaboratively perform permission management based on the same operation control token, including: The rendering engine receives the rendering control instruction packet and performs permission filtering on the rendering operation requests input to the rendering area according to the set of allowed operations and the set of prohibited operations to obtain the rendering filtering result. The editor receives the editing control instruction package and performs permission filtering on the editing operation requests input to the text editing area according to the allowed editing operation set and the prohibited editing operation set, and obtains the editing filtering result; The rendering filtering result and the editing filtering result are synchronously verified to obtain state consistency information; When the state consistency information indicates that both the rendering filter result and the editing filter result are in an allowed state, the rendering operation request and the editing operation request are executed. When the state consistency information indicates that either the rendering filter result or the editing filter result is in a prohibited state, the corresponding operation request is blocked, and the operation blocking status information is fed back to the unified permission verification intermediate layer to update the permission identification information in the operation control token.

2. The method according to claim 1, characterized in that, Deploying a unified permission verification middleware layer between the rendering engine and the editor, and routing the operation instructions to the unified permission verification middleware layer, includes: The interface feature difference information is obtained by analyzing the instruction receiving interface features of the rendering engine and the editor. Based on the interface feature difference information, a unified permission verification middleware is inserted between the rendering engine and the editor. The input port and output port of the unified permission verification middleware are configured. The input port receives the operation instructions, and the output port includes a rendering output sub-port and an editing output sub-port. A permission verification logic template is loaded in the unified permission verification intermediate layer. The permission verification logic template includes rendering operation verification rules and editing operation verification rules. Establish a first communication link between the unified permission verification middleware layer and the rendering engine, and a second communication link between the unified permission verification middleware layer and the editor; Based on the link status information of the first communication link and the second communication link, and the permission verification logic template, the routing rules of the unified permission verification intermediate layer are configured so that the operation instruction enters the unified permission verification intermediate layer through the input port according to the routing rules, and is routed to the corresponding instruction receiving interface through the rendering output sub-port or the editing output sub-port according to the operation type identifier corresponding to the operation instruction.

3. The method according to claim 1, characterized in that, The unified permission verification middleware synchronously parses the rendering operation type and text editing operation type corresponding to the operation instruction, including: Extract the semantic information of the operation instruction, and identify the operation category to which the operation instruction belongs based on the semantic information. The operation category includes rendering operation category and editing operation category. When the operation instruction belongs to the rendering operation category, the operation instruction is further subdivided according to the rendering operation classification rules to obtain the rendering operation type; When the operation instruction belongs to the operation category of editing operation, the operation instruction is further subdivided according to the editing operation classification rules to obtain the text editing operation type; The rendering operation type and the text editing operation type are structurally encapsulated to obtain operation type description information, which includes operation type identifier and operation scope identifier. The operation type description information is output to the permission query module of the unified permission verification intermediate layer, so that the permission query module can query the corresponding rendering permission verification result and editing permission verification result according to the operation type identifier and the operation scope identifier respectively.

4. The method according to claim 3, characterized in that, The rendering permission verification results for the rendering operation type and the editing permission verification results for the text editing operation type are queried respectively. The rendering permission verification results and the editing permission verification results are then compared for consistency to obtain a unified permission verification conclusion, including: Based on the rendering operation type, query the rendering permission configuration information corresponding to the rendering area; based on the text editing operation type, query the editing permission configuration information corresponding to the text editing area. The rendering permission configuration information and the editing permission configuration information are compared in terms of permission status to detect the status difference information between the rendering permission configuration information and the editing permission configuration information; The state difference information is used to determine conflicts according to the preset permission consistency rules. When the state difference information meets the conflict conditions in the permission consistency rules, permission conflict marker information is generated. When the state difference information does not meet the conflict condition, permission fusion information is generated based on the rendering permission configuration information and the editing permission configuration information. The permission conflict marker information or the permission fusion information is output as the unified permission verification conclusion to the conclusion generation module of the unified permission verification intermediate layer, so that the conclusion generation module controls the generation logic of subsequent operation control tokens based on the unified permission verification conclusion.

5. The method according to claim 1, characterized in that, An operation control token is generated based on the unified permission verification result. The operation control token includes permission identification information and operation type identification information, including: Parse the permission status information in the unified permission verification conclusion to obtain the rendering permission status identifier and the editing permission status identifier; A permission identifier field is generated based on the rendering permission status identifier and the editing permission status identifier, and an operation type identifier field is generated based on the rendering operation type and the text editing operation type; The permission identifier field and the operation type identifier field are written into a token data structure. The token data structure includes a token header area and a token payload area. The token header area stores the permission identifier field, and the token payload area stores the operation type identifier field. Configure time-limited attribute information for the operation control token, the time-limited attribute information including the token's effective time and the token's expiration time; The operation control token configured with the timeliness attribute information is output to the permission control distribution module, so that the permission control distribution module distributes the corresponding operation control strategy to the rendering engine and the editor according to the permission identifier field and the operation type identifier field.

6. A system for collaborative management of graphics rendering and text editing permissions, used to implement the method as described in any one of claims 1-5, characterized in that, include: The instruction acquisition unit is used to acquire user operation instructions for a target composite object in the canvas, wherein the target composite object includes a rendering area and a text editing area. The permission routing unit is used to deploy a unified permission verification middleware layer between the rendering engine and the editor, and to route the operation instructions to the unified permission verification middleware layer. The permission verification unit is used by the unified permission verification middle layer to synchronously parse the rendering operation type and text editing operation type corresponding to the operation instruction, and query the rendering permission verification result corresponding to the rendering operation type and the editing permission verification result corresponding to the text editing operation type respectively. The rendering permission verification result and the editing permission verification result are compared for consistency to obtain the unified permission verification conclusion. The token generation unit is used to generate an operation control token based on the unified permission verification conclusion. The operation control token includes permission identification information and operation type identification information. The strategy execution unit is used to issue differentiated operation execution strategies to the rendering engine and the editor respectively based on the permission identification information in the operation control token. The rendering engine performs rendering control on the rendering area according to the corresponding operation execution strategy, and the editor performs editing control on the text editing area according to the corresponding operation execution strategy, so that the rendering engine and the editor cooperate to perform permission management based on the same operation control token.

7. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 5.

Images