Dynamic function menu generation method and device, equipment and medium

Abstract

The invention relates to the technical field of data security, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a dynamic function menu generation method, device, equipment and medium, which comprises the following steps: acquiring an access request containing equipment type information sent by a user terminal, analyzing an authentication state of a user account and an associated license state, and sending the access request to the user terminal; and generating a dynamic session context defining function access qualification and an interface rendering strategy, loading a function menu strategy model containing function item set and permission mapping, determining a target permission level, matching a target function item subset with a rendering strategy, and generating and sending a function menu instance to the user terminal. The dynamic session context is generated in real time in combination with the user authentication state and the license state, linkage of permission judgment and interface rendering is driven, the function menu has the capacity of dynamic switching according to the session state, menu generation and accurate issuing based on actual authorization and the equipment environment are achieved, and unauthorized access is effectively avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, and in particular to a dynamic function menu generation method and device, equipment and a storage medium. BACKGROUND

[0002] In the current information system architecture, the generation of function menus and the permission control mechanism mostly rely on static role configuration, and the system usually renders function menus based on preset role permissions after user login. However, this static authorization mechanism has significant limitations, especially when the user session state changes or the license state changes, the menu content cannot be adjusted in time, which may cause the user to still access the function items that he or she has no right to use after the authentication state is invalid, and there is a risk of unauthorized access. In addition, the lack of real-time permission binding mechanism based on login state makes it possible for an attacker to maintain the original menu access ability once the session is hijacked or the token is stolen, causing system security risks.

[0003] In the field of financial technology business, financial institutions need to strictly control the menu content in the user interface, for example, in the asset management, account setting, risk assessment and other modules, different levels of accounts correspond to different operation ranges. The current mainstream financial systems generally use the method of regularly updating the permission configuration file for control, which cannot dynamically respond to changes in user login state and immediate changes in license state, and is prone to problems such as authorization failure lag, operation content out of range, etc., which adversely affects compliance management.

[0004] In the field of medical and health business, doctors, nurses, patients and other different roles need to access different types of function items, such as electronic medical record viewing, prescription issuing, hospital management, etc. Due to the high sensitivity of medical data, existing systems mostly use static menu configuration methods, and lack dynamic menu rendering mechanisms based on user identity authentication state and device type. Once the user login state expires or the license is invalid, the system cannot block the access path in time, and may still display function entries related to the original permissions, which poses a potential risk of information leakage.

[0005] In addition, the menu rendering logic in existing systems generally has the problems of complex interaction and slow response. For example, the traditional multi-level drop-down menu design often requires multiple clicks by the user to expand the target function item, which has a long interaction path and poor experience, especially on mobile terminals, which seriously affects user efficiency.

[0006] The existing technology also generally lacks automation in license management. Most systems rely on manual review of license expiration dates, lack real-time verification mechanisms for license status, and cannot automatically restrict function access when the license expires, which can lead to continued user operation in an invalid authorization state and pose a risk to security and compliance. SUMMARY

[0007] The main purpose of the present application is to provide a dynamic function menu generation method, device, equipment and storage medium, aiming at solving the technical problems that the prior art cannot realize real-time dynamic generation and permission linkage control of function menu based on user authentication state and license state, resulting in static menu content, lagging permission update, and over-reach access and compliance risk.

[0008] To achieve the above purpose, the present application provides a dynamic function menu generation method, comprising:

[0009] Obtaining an access request sent by a user terminal carrying device type information;

[0010] In response to the access request, the authentication state of the user account is parsed, and the license state associated with the user account is obtained;

[0011] According to the authentication state, the license state and the device type information, a dynamic session context for defining function access qualification and interface rendering strategy is generated;

[0012] Load the function menu strategy model corresponding to the rendering strategy of the associated function item set and different permission levels;

[0013] Based on the dynamic session context, the target permission level is determined in the function menu strategy model, and the corresponding target function item subset and target rendering strategy are matched according to the target permission level;

[0014] The target function item subset is processed through the target rendering strategy to generate a function menu instance;

[0015] The function menu instance is sent to the user terminal.

[0016] Further, to achieve the above purpose, the present application provides a dynamic function menu generation device, comprising:

[0017] An access analysis module for obtaining an access request sent by a user terminal carrying device type information;

[0018] An identity verification module for parsing the authentication state of a user account in response to the access request, and obtaining the license state associated with the user account;

[0019] A session context generation module for generating a dynamic session context for defining function access qualification and interface rendering strategy according to the authentication state, the license state and the device type information;

[0020] The strategy model loading module is configured to load a function menu strategy model corresponding to a rendering strategy of a function item set associated with different permission levels;

[0021] The permission mapping module is configured to determine a target permission level in the function menu strategy model based on the dynamic session context, and match a target function item subset and a target rendering strategy corresponding to the target permission level;

[0022] The menu generation module is configured to process the target function item subset by using the target rendering strategy to generate a function menu instance.

[0023] The menu transmission module is configured to send the function menu instance to the user terminal.

[0024] Further, to achieve the above-mentioned purpose, the present application also provides a computer device, which comprises a memory, a processor, and a dynamic function menu generation program stored in the memory and executable on the processor, and the dynamic function menu generation program implements the steps of the dynamic function menu generation method when executed by the processor.

[0025] Further, to achieve the above-mentioned purpose, the present application also provides a computer readable storage medium, which stores a dynamic function menu generation program, and the dynamic function menu generation program implements the steps of the dynamic function menu generation method when executed by a processor.

[0026] Beneficial effects: The present application relates to the technical field of data security, and can be applied to business scenarios such as financial technology and medical health. A dynamic function menu generation method, device, equipment and medium are disclosed, which comprise: obtaining an access request sent by a user terminal and carrying device type information; responding to the access request to parse an authentication state of a user account and obtain a license state associated with the user account; generating a dynamic session context for defining function access qualification and interface rendering strategy according to the authentication state, the license state and the device type information; loading a function menu strategy model containing a function item set associated with a permission level mapping; determining a target permission level based on the dynamic session context and matching a target function item subset and a target rendering strategy; processing the target function item subset by using the target rendering strategy to generate a function menu instance; and sending the function menu instance to the user terminal. The present application generates a dynamic session context in real time by combining a user authentication state and a license state, drives the linkage of permission judgment and interface rendering, enables the function menu to have the ability of dynamic switching according to the session state, and thus realizes menu generation and accurate delivery based on actual authorization and device environment, effectively avoids unauthorized access, and improves access compliance and terminal interaction experience. BRIEF DESCRIPTION OF DRAWINGS

[0027] The application will be further described below in conjunction with the accompanying drawings and embodiments, in which:

[0028] Figure 1 An application environment diagram of the generation method of the dynamic function menu in an embodiment of the application;

[0029] Figure 2 A flow diagram of the generation method of the dynamic function menu in an embodiment of the application;

[0030] Figure 3 A function module diagram of the preferred embodiment of the generation device of the dynamic function menu of the application;

[0031] Figure 4 A structure diagram of the computer device in an embodiment of the application;

[0032] Figure 5 Another structure diagram of the computer device in an embodiment of the application. DETAILED DESCRIPTION

[0033] It should be understood that the specific embodiments described herein are merely intended to explain the application and are not intended to limit the application.

[0034] The generation method of the dynamic function menu provided by the embodiments of the application can be applied in an application environment as shown in Figure 1 , wherein the user terminal communicates with the server through the network. The server can obtain the access request carrying the device type information sent by the user terminal through the user terminal; respond to the access request to parse the authentication state of the user account and obtain the license state associated with the user account; generate a dynamic session context for defining the function access qualification and the interface rendering strategy according to the authentication state, the license state and the device type information; load a function menu strategy model containing an associated function item set and a permission level mapping; determine the target permission level based on the dynamic session context, and match out the target function item subset and the target rendering strategy; apply the target rendering strategy to process the target function item subset to generate a function menu instance; and send the function menu instance to the user terminal. The application generates a dynamic session context in real time by combining the user authentication state and the license state, drives the linkage of the permission judgment and the interface rendering, enables the function menu to have the ability of dynamic switching according to the session state, and thus realizes the menu generation and accurate delivery based on the actual authorization and the device environment, effectively avoids the unauthorized access, and improves the access compliance and the terminal interaction experience. The user terminal can be but is not limited to various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices. The server can be realized by an independent server or a server cluster composed of multiple servers. The application will be described in detail below through specific embodiments.

[0035] Please refer to Figure 2 , Figure 2 The flowchart of an embodiment of the method for generating a dynamic function menu provided by the present application. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described can be performed in an order different from that shown here.

[0036] As Figure 2 shown, the method for generating a dynamic function menu provided by the present application includes the following steps:

[0037] S10, obtaining an access request carrying device type information sent by a user terminal;

[0038] In this embodiment, in order to establish a precise function adaptation process for different device states and network environments, it is first necessary to receive an access request from a user terminal from a communication level, which is encapsulated in a data structure of a network transmission protocol, usually in the form of a request data packet of a protocol such as HTTP, HTTPS or WebSocket. The access request contains encrypted payloads, which internally contain field data representing device environment information.

[0039] In the process of receiving the request data, the request data packet received by the network layer needs to be forwarded to the parsing module through a reverse proxy or an access gateway, and the parsing module internally deploys standard decryption algorithm modules such as TLS protocol decryptor and symmetric key decryptor. The decrypted plaintext data structure contains multiple fields, including a user agent string field and a network connection information field.

[0040] The user agent string field is an identifier generated by a browser, App SDK or system bottom layer, which reflects the operating system type, kernel version, browser information or running environment label of the user terminal. For example, in the Android system, the "Mozilla / 5.0 (Linux; Android 10; SM-G973F)" string can be obtained, while in the iOS system, it may be represented as "Mozilla / 5.0 (iPhone; CPU iPhone OS13_5 like Mac OS X)".

[0041] The network connection information field represents the network state of the current user terminal, including connection type (such as Wi-Fi, 4G, 5G), bandwidth range, delay estimate, etc. This field is usually collected by the SDK when calling system APIs, such as calling Android's ConnectivityManager or iOS's Network.framework.

[0042] After decryption and parsing of the above fields, a signature verification operation needs to be performed on the user agent string field. This verification process uses a predefined hash algorithm (such as SHA-256) to calculate a string digest value and compares it with the signature value stored by the access control system to ensure that the data has not been tampered with.

[0043] Subsequently, by performing keyword parsing and pattern matching operations on the user agent string, information such as operating system type, device model identification, screen size parameters, and device brand can be extracted and mapped to generate a uniform format device type identifier. This identifier is usually encoded using a 32-bit or 64-bit structure within the system, with each bit or segment representing a different device attribute label, facilitating subsequent device-level policy matching.

[0044] To further enhance the uniqueness of device identification, device hardware feature codes need to be collected from the terminal. This feature code is obtained by calling the hardware information interface exposed by the terminal operating system, such as Build.SERIAL, Settings.Secure.ANDROID_ID in the Android system, or identifierForVendor in iOS, forming a unique identifier based on the hardware layer.

[0045] The device type identifier and hardware feature code are combined to form a composite device identifier, which is fused through splicing, hashing, or salted encryption to ensure stability and unforgeability in different network environments and device models.

[0046] Finally, the network connection information field is associated with the composite device identifier for analysis, generating a device type information object. This object structure contains fields such as device category, running environment type, terminal capability label, and network adaptation level, which are used to support subsequent permission determination and interface rendering adaptation.

[0047] A pre-processing module can be injected into the front-end App or web page to collect system information and network status of the user terminal locally and send it along with the network request. Alternatively, a unified TLS decryption and field extraction logic can be implemented in the backend access layer, and the device information generation can be completed by internal services.

[0048] In the device type identifier generation segment, multiple regular expression matching templates can be set to adapt to the naming rules of different manufacturer device models. In the device hardware feature code fusion, elliptic curve encryption algorithms can also be used to enhance the security of the identifier, or timestamps and key salts can be used to form one-time device authentication identifiers.

[0049] For the extraction of network connection information, a dynamic sampling mechanism can be set up to report network delay, bandwidth changes and signal quality at the client end on a regular basis, and historical samples are aggregated for evaluation to form a stable network capability label, thereby enhancing the timeliness and accuracy of device type information.

[0050] Example: In the medical health business field, terminal devices used by patients may include self-service machines, mobile apps or home health monitoring devices. Whether a graphical interface is supported can be determined according to the device model, and whether a real-time remote consultation menu can be loaded can be determined through network status, so as to avoid misloading of video diagnosis and treatment entry under low bandwidth conditions and improve the accuracy of patient operation.

[0051] In the financial technology business field, the terminal type determines whether the user can access complex data visualization tools. For example, a desktop browser can render multidimensional data graphs, while low-performance mobile devices should be downgraded to static card menus. Supporting automatic adjustment of display strategies according to hardware features ensures smooth access to basic account management functions on low-end devices, improving the coverage and user experience of financial services.

[0052] The present embodiment realizes high-precision identification of device type information in user terminal access requests through signature verification of user agent strings, device hardware feature code collection and network connection state extraction operations. The identification result provides structured input data for subsequent dynamic menu matching and permission determination, ensuring the adaptability of rendering strategies and the accuracy of access control, and avoiding the menu mismatch and function failure problems caused by inaccurate device identification in traditional methods.

[0053] S20, in response to the access request, parsing the authentication state of the user account and obtaining the license state associated with the user account;

[0054] In the present embodiment, when the system receives an access request initiated by a user terminal and completes the parsing of device type information, it needs to further extract data content related to the user's identity to identify whether the current visitor has been authenticated and determine whether the scope of his available service permissions is still in an effective state.

[0055] The access request usually contains an embedded session token, which is used to identify the login status and authorization of the current access user. The session token is generally generated through a token-based authentication mechanism, such as the Access Token in OAuth 2.0, the JWT (JSON Web Token) format token, or a platform-defined encrypted token. The system extracts the session token in the service gateway or authentication module and parses its internal structure fields. Common structures include user unique identifier, login timestamp, validity period marker, permission summary, and digital signature fields.

[0056] After extracting the token, the digital signature attached to it needs to be verified, usually using asymmetric encryption algorithms such as RSA or ECC. The system hashes the entire content of the token except the signature field and uses the public key to verify whether the signature and the digest are consistent. If the verification is passed and the current system time does not exceed the valid time range embedded in the token, the session is determined to be in a valid state.

[0057] After parsing the user unique identifier in the token, the identity authentication database is accessed through the identifier to perform a query operation to obtain the user's permission level information and session active state in the current system. For example, the query fields can include the organization to which the account belongs, the role label, whether it is a temporary account, and whether there is a risk control marker. The queried permission level and session state value are combined to form an authentication state object, which will be used for subsequent permission level matching and interface rendering judgment.

[0058] In addition to the authentication state, the status of the user's license also needs to be further clarified. The license is an independent authorization marker for function access range and time limit, usually generated and stored by the license management service module. The system accesses the interface provided by the service module, constructs and sends a license query request containing the user's unique identifier. The license management module finds the user's corresponding license record according to the request and returns response data containing the effective timestamp, invalid timestamp, and authorized function range list parameters.

[0059] After receiving the response, the system compares the current time with the effective timestamp and invalid timestamp to determine whether the license is in an active state. If it is within the valid period, the authorized function range is extracted to construct a license state object, which contains at least the validity period determination result and the function authorization range. The authentication state object and the license state object will be used as inputs to participate in dynamic context generation.

[0060] The token signature verification logic can be implemented by configuring the token verification module of the server, supporting fast decoding and verification of JWT structure, and also integrating symmetric algorithms such as HMAC-SHA256 to realize lightweight authentication. After parsing the user identifier, the permission level and session state can be quickly found through the cache layer (such as Redis), and centralized authentication systems such as LDAP or OAuth server can also be accessed for synchronous verification.

[0061] In the license status query process, the RESTful API interface can be used to communicate with the license center service, and the interface design should support asynchronous response and fault tolerance mechanism. In the acquisition of the authorized function range, a function classification system based on module classification can be set up, such as three levels of basic module, enhanced module and advanced module, and the function tag set can be filtered according to the current authorized information of the user.

[0062] For enterprise multi-account scenarios, the user identifier can be mapped to the enterprise ID and the organization-level authorization parameters can be attached to realize unified license control of enterprise internal accounts. When comparing the license validity period, a clock bias tolerance threshold can also be introduced to adapt to the timestamp consistency problem under cross-regional deployment.

[0063] Example: In the medical health business scenario, the doctor account and the nurse account have different function access permissions. Through token parsing, it can be confirmed that the current login identity belongs to a doctor, but if its license is limited to the basic module and is not authorized for the advanced image processing module, the system can prevent it from accessing the advanced image analysis interface based on the license status, preventing illegal operation of the diagnosis and treatment equipment or illegal viewing of high sensitivity data.

[0064] In the financial technology business scenario, the system administrator may have completed the login authentication, but his license has expired. If only the authentication state is relied on, he will still be granted access to the back-end management function. By detecting the license status and finding that it has expired, the system can dynamically adjust the function menu structure, and the sensitive operation entry will be taken off the shelf, preventing expired accounts from performing batch fund operations and avoiding the risk of abuse of authority.

[0065] The embodiment realizes double-state analysis by combining the token information carried in the access request and the independent license management module. The system can accurately identify the login state and authorized ability of the current user, avoiding the problem of function overreach or authority failure caused by relying only on the authentication state for access control in the traditional mode. This process improves the timeliness control and fine-grained differentiation ability of function authority, ensures that different users can only access the function modules within their legal authorized range, and enhances the compliance guarantee ability of the platform.

[0066] S30, according to the authentication state, the license state and the device type information, generating a dynamic session context for defining function access eligibility and interface rendering strategy;

[0067] In the present embodiment, the authentication status, license status and device type information respectively represent the identity validity of the user in the current session, the authorization boundary and the capability limitation of the terminal used. These three types of information constitute the key parameter set when the user interacts with the platform, and their logical relationship is: the authentication status determines whether to allow entering the interaction stage, the license status further limits the available range of functions, and the device type information is used for interface adaptation and interaction complexity management.

[0068] The authentication status contains a permission level identifier and a session active flag. The permission level identifier can be derived from the role configuration in the unified permission control system (such as administrator, ordinary user, read-only visitor, etc.), which is used to control the range of visible function items. The session active flag is usually of Boolean type, indicating whether the current login state is active, which can be maintained through a heartbeat mechanism or token refresh mechanism.

[0069] The license status includes an authorized function list and an expiration flag. The authorized function list points to the specific function number or label that the user is allowed to access, which is usually bound to the account ID in the license management service. The expiration flag is a timestamp or a lifetime parameter, which is used to control the availability of function authorization in the time dimension.

[0070] The device type information contains a device classification identifier and a screen display parameter. The device classification identifier is used to distinguish the operating system and physical form of the access device, such as PC, tablet, mobile terminal, vehicle terminal, etc., to guide the selection of interface structure. The screen display parameter includes screen size, resolution, DPI, supported input methods (touch, mouse, voice), etc., which is used to determine whether the interface elements are scalable, whether the layout needs to be folded, and other rendering strategy adjustments.

[0071] After comprehensive analysis of the three types of information, the system can filter the authorized function list based on the permission level identifier, retaining only the function set that is actually allowed to access in the current login session, generating a function access qualification set. Then, the system determines the basic layout mode based on the device classification identifier, for example, using a card layout for mobile terminals and a tree menu layout for PC terminals. Further combined with the screen display parameter to calculate the responsive breakpoint, which is used to determine the adaptive behavior of the interface layout, such as whether the menu is folded, whether the icon is displayed, whether the multi-layer structure is supported, etc.

[0072] The interaction complexity level is set through the session active flag and the screen parameter. For example, in a large-screen touch device and active session, high-complexity interaction logic (such as multi-finger operation, sliding trigger, etc.) can be enabled; while in a low-resolution device or non-active session, it is limited to basic button operation or read-only display.

[0073] The system writes the above generated data structure into the function access qualification field, layout mode field, responsive breakpoint field, interaction complexity field and time control field respectively, and finally forms a complete context data structure body. The data structure body is used to drive the subsequent menu permission matching and interface rendering strategy generation.

[0074] The function access qualification set can be filtered in the preconfigured function mapping table by the permission level identifier as the filtering condition, and the function tag set matching the current permission level is returned. The layout mode field can use JSONSchema or XML structure to represent the preset layout template, and select through device classification identifier mapping. The responsive breakpoint field can use the logical structure of CSS media query, such as defining 720px, 1024px, 1440px as the boundary line, and generating a boolean label according to the screen width.

[0075] The generation of the interaction complexity field can be realized by introducing a multi-factor decision model, which inputs the screen type (touch screen or non-touch screen), resolution level, and input capability recognized by the system, and outputs a complexity level such as basic, enhanced, and advanced. The time control field usually records the end time of the token validity period, or sets it to the absolute timestamp of the session validity failure.

[0076] The above fields can be standardized into data structures using structure encapsulation tools, such as protobuf, thrift or platform-defined structure definition language. The context data structure can be stored in thread local variable (ThreadLocal) or bound to the session object (Session) for subsequent process reading.

[0077] Example: In the medical health business scenario, the screen size of the mobile ward round terminal is limited and needs to operate quickly, the system can identify the mobile terminal based on the device classification identifier, and configure the card interface and single-column function menu in the dynamic context; combined with the senior permission level of the doctor account and the activated graphic report viewing license, only the corresponding function entrance is reserved and the touch optimized interaction strategy is adapted to ensure that the doctor can quickly call the necessary functions in the ward environment.

[0078] In the financial technology business scenario, the background operation personnel performs customer service operation through the PC terminal, the system identifies the device classification as desktop, and generates high permission access qualification according to its authentication state. Combined with the limited operation types in its license, the dynamic context can prohibit the display of part of the high-risk function entrance to avoid over-authorization behavior; at the same time, according to the wide screen display parameter, the multi-column menu layout is enabled to improve the multi-task processing efficiency, which meets the high-frequency interface switching demand in the financial operation scene.

[0079] The embodiment constructs a dynamic context environment based on authentication status, license status and device type information, so that the function access qualification and interface rendering strategy can accurately bind the user identity, authorization boundary and terminal capability, avoiding the risk of disconnection between function display and permission authorization in the traditional static rendering mode. The system realizes dynamic distribution of function level and adaptive adaptation of interface level, which improves access security and optimizes user interaction experience on different devices.

[0080] S40, load the function menu strategy model of the rendering strategy corresponding to the associated function item set and different permission levels;

[0081] In the embodiment, the function menu strategy model refers to a model structure for describing the mapping relationship between a plurality of function items and permission levels, and simultaneously contains a set of interface rendering strategies corresponding thereto. The model is usually stored and managed in the form of a structured configuration file, and its key components include function item set definition, permission level mapping table, rendering strategy identifier system and the like. In the loading stage, the system needs to perform legality verification, structure analysis and memory instantiation on the configuration file.

[0082] Firstly, a pre-stored function menu strategy model configuration file is accessed, which can adopt JSON, YAML or other structured analysis formats, and is deployed in a distributed configuration center or a local cache directory. The configuration file contains a function item set, each function item is described by a unique identifier, a function label and an interaction type, such as “FUNC_VIEW_PATIENT_RECORD”, “FUNC_EDIT_TRANSACTION” and the like, the label field is used to support interface display name internationalization, and the interaction type field is used to determine the use of buttons, menu items, icons or pop-up windows for interface rendering.

[0083] After accessing the configuration file, the digital signature and version compatibility of the file need to be verified to prevent loading failure or permission mismatch due to man-in-the-middle tampering, version inconsistency or system rollback. The digital signature can be verified using symmetric key or asymmetric public key mechanism, and the version compatibility is determined by comparing the version number in the configuration file with the compatible version range declared in the running environment.

[0084] After verification, the model structure description data is parsed. The model structure description data includes function item set definition and permission level mapping table. The function item set definition is a complete description of all platform-supported function items, each function item needs to be marked with a unique function item identifier, and is accompanied by supported interaction forms and visual element identifiers. The permission level mapping table is the core component of the permission control system, which lists the corresponding relationship between each permission level identifier, the function item subset identifier allowed to access and the rendering strategy identifier.

[0085] The permission level mapping table realizes the fast lookup function by constructing a mapping structure, which is generally a hash mapping table or a prefix tree structure, wherein the permission level identifier is the key, and the value is an array of structure bodies containing the function item subset identifier and the rendering strategy identifier, which is used to support one-to-many access relationship. At the same time, the conflict processing rules during permission level inheritance or merging are supported, for example, whether to cover the next level of permission is identified by a priority field, or multiple subset identifiers are combined through strategy merging logic.

[0086] After the above parsing operation is completed, the system constructs a function menu strategy model instance, which is a memory level data structure, contains function item set definition and associated mapping two parts, and provides an interface for downstream calling. Finally, the instance is loaded into the runtime memory, usually stored in the thread context or mounted in the global strategy control container, for function permission matching and rendering strategy scheduling stage calling.

[0087] The function menu strategy model configuration file can be deployed on a distributed configuration platform, such as Nacos, Apollo, Zookeeper, etc., which is convenient for unified loading and dynamic hot updating in a multi-instance environment. The digital signature verification process can use the HMAC-SHA256 algorithm, and the version compatibility strategy can define the minimum version number and the maximum supported version number interval, which is used to judge whether the current running environment meets the loading conditions.

[0088] In the function item set definition structure, the interaction form can be further refined into types such as static display, dynamic trigger, asynchronous loading, etc., and additional behavior labels such as "critical_action", "requires_confirmation" are added, which are used for further adaptation of rendering strategy. The permission level mapping table can support multi-language annotations and permission policy label extension fields to improve the model semantic description ability.

[0089] During the model instance construction process, the mapping relationship between the permission level and the function item subset can be cached as a local hot path to reduce the parsing burden of each request. For high concurrency scenarios, a read-only copy switching mechanism can be introduced after the model is loaded, and the memory hot replacement is performed after the strategy update is completed to ensure the stability of online services.

[0090] Example: In the medical health business field, different role users such as attending physicians, nurses, and patients have different function permission sets in the system. By loading the function menu strategy model, the medical record editing and diagnosis viewing functions can be enabled for doctors, the basic nursing record function can be opened for nurses, and only the self-service query module can be opened for patients, and based on mobile devices, simplified rendering configuration is performed to adapt to the mobile ward review system.

[0091] In the field of financial technology business, the customer manager, risk controller and system administrator have obvious differences in permission level. The system matches different permission levels with menu function subsets by loading strategy model, for example, the customer manager can only access the customer information input module, the risk controller can access the credit audit module, and the administrator has the system parameter configuration permission. The interface layout uses multi-level menu structure due to desktop devices, which improves the operation efficiency of complex tasks and reduces the probability of misoperation.

[0092] The embodiment forms a decoupled management system for permission control and interface rendering of function items through a structured function menu strategy model. The system completes configuration legality verification and structure analysis during loading process, and instantiates the model to the runtime environment, providing data support for subsequent permission matching and dynamic rendering. This design avoids the problem of hard coding of permission control, improves the flexibility of strategy adjustment, and ensures the consistency of menu behavior and interface display under different permission levels, thereby enhancing the controllability and consistency of user experience of the system.

[0093] S50, determining a target permission level in the function menu strategy model based on the dynamic session context, and matching a corresponding target function item subset and target rendering strategy according to the target permission level;

[0094] In the embodiment, the dynamic session context is a data structure composed of multiple fields such as permission level, function access qualification and interface adaptation parameter. The system locates the target permission level in the function menu strategy model according to the content, and obtains the function item subset and its corresponding rendering strategy that the interface should display.

[0095] In the specific operation process, first, the session validity period marker field in the dynamic session context is extracted, which is used to determine whether the current context is expired. This field is usually stored in standard timestamp format, such as Unix timestamp or ISO 8601 format, and compared with the current system time to determine whether it is invalid. If it is valid, the permission level identifier is extracted, which is a core field in the dynamic session context that represents the user's function access range. Its value can be a string, a number or a hierarchical code, such as "ROLE_1", "L3_USER", etc.

[0096] After extracting the permission level identifier, the system uses the identifier as a key to search in the associated mapping table of the function menu strategy model. The mapping table uses permission level as index and stores corresponding function item subset identifier and rendering strategy identifier, and realizes fast positioning through hash structure. If a matching item is found, the target function item subset identifier and the target rendering strategy identifier are returned.

[0097] The system uses a function item subset identifier to index in the function item set definition of the function menu strategy model, extracts a group of function item entries corresponding to the identifier. Each entry includes a function name, a trigger behavior, interface binding information, and a security policy tag, which can be directly inserted as a menu element into a subsequent interface layout module.

[0098] Next, the system accesses a pre-stored rendering strategy library, which stores various layout configurations, interaction definitions, and visual parameter sets indexed by rendering strategy identifiers. The target rendering strategy is retrieved using the target rendering strategy identifier as a query condition. The strategy includes parameters such as the structure mode of menu display, component hierarchy, trigger animation, and style template.

[0099] Finally, the system combines the target function item subset with the target rendering strategy to generate a structured matching result object, which is used in the subsequent menu instance generation stage. The object contains function item data references and corresponding rendering configurations, which are important data bases for subsequent menu container construction and style application.

[0100] The system can use a cache warm-up mechanism to load commonly used permission levels, their corresponding function item subsets, and rendering strategy identifiers into memory during service initialization, reducing runtime query delays. Permission level identifiers can be generated in combination with JWT token or OAuth2 scope coding rules to adapt to distributed authentication architectures.

[0101] The function item subset identifier can be in the form of a multi-tag combination to support dynamic function splicing, such as "TX_VIEW+TX_EDIT" to combine the complete interaction functions of the transaction module. The rendering strategy identifier can pre-set a basic template and allow additional overlay parameters based on device type to achieve consistent cross-platform interface control.

[0102] In a multi-language system, function item entries and rendering strategies can be managed separately through language packs and style theme packs, dynamically loaded through region settings and theme configurations, to avoid affecting menu consistency due to regional differences.

[0103] This embodiment extracts permission levels from dynamic session context and matches function items and rendering strategies in the strategy model, allowing the system to adapt and accurately configure user menu structures in real time. Without hard-coded permission logic or redundant front-end configuration, the system ensures that menu permissions and authentication status are closely coupled. Through independent mapping structures and rendering strategy isolation mechanisms, the system ensures consistent and controllable switching of function display and interface performance under different permission levels, effectively avoiding function overreach and display misplacement, improving interaction security and adaptability.

[0104] S60, processing the target function item subset through the target rendering strategy to generate a function menu instance;

[0105] In this embodiment, after the target permission level is matched, the system takes the obtained target function item subset and the target rendering strategy as inputs to enter the generation phase of the function menu instance. The processing logic of this phase arranges the interface, registers the interaction, and constructs the vision of the function item based on the structured rendering rule, so as to form a menu data structure that can be correctly recognized, parsed, and displayed by the user terminal.

[0106] The rendering strategy is usually composed of multiple sub-configurations, including layout mode configuration, interaction strategy configuration, and visual style configuration. The layout mode configuration is used to define the arrangement mode of the menu elements in the view, which can include grid mode, list mode, tree structure, or responsive column, etc.; each mode configuration contains parameters such as logical arrangement order, maximum display level, and sub-menu nesting rule. The system instantiates the menu container component according to the configuration, which constitutes the skeleton of the menu view, such as building a framework structure containing the main menu area and the folded menu area.

[0107] Then the system injects the function item elements in the target function item subset into the constructed basic menu layout, each function item element is composed of function identification, display name, icon path, jump target, and state flag. The injection operation is performed according to the region mapping rule, slot index, and hierarchical grouping mode set by the layout configuration, ensuring that all function items can be accurately rendered and the order is clear.

[0108] After completing the structure embedding, the system registers various event listeners based on the interaction strategy configuration content, common events include click expansion, sliding response, focus switching, hover prompt, and shortcut key mapping, etc. This configuration determines the way and response logic of user interaction with the menu, such as whether to support keyboard shortcut operation, whether to enable expansion animation, whether to record the recently accessed items, etc.

[0109] Finally, the system reads the visual style configuration and applies the style template to the embedded function items and container structure, the style content includes font settings, icon style, color scheme, margin spacing, shadow effect, and interaction feedback animation, etc. After applying the style, the entire menu structure is serialized into a data object, and the registered event response and style control are bound to the object, finally forming a menu component instance that can be executed by the client rendering engine.

[0110] The system can build a menu container based on the front-end component framework such as Vue or React, and use the virtual DOM mechanism to reuse and update the layout template. The layout mode configuration can be defined in YAML or JSON form and pulled remotely, supporting version management and rollback. The target function item injection process can be completed through data-driven slot rendering, combined with the visibility flag of the function item to control whether to display it under the current device type.

[0111] Interaction strategy configuration can be adapted based on platform differences, such as enabling slide triggering and floating prompt closing on mobile, and enabling keyboard event monitoring and multi-layer folding and expanding on desktop. Visual styles can support theme switching, allowing users to select different color schemes or font size templates, and dynamically reference the corresponding style sheets when constructing menu instances.

[0112] For low-performance terminals, a streamlined mode rendering strategy can be used to load only the main function items and first-level submenus to avoid terminal freezes or crashes due to complex layouts or excessive rendering levels.

[0113] This embodiment associates a subset of target function items with a target rendering strategy, dynamically constructing a well-structured, interactive, and visually unified function menu instance based on user permissions and device environment. This process does not rely on front-end hard coding, decoupling function items from interface presentation. Function item content, arrangement order, interaction logic, and presentation style can all be controlled and dynamically updated by the back-end, thereby meeting the needs of rapid business evolution, rapid permission switching, and device compatibility optimization, improving the system's scalability, maintainability, and user experience.

[0114] S70: Send the function menu instance to the user terminal.

[0115] In this embodiment, after constructing the function menu instance, the system needs to send it in a format suitable for parsing by the user terminal. This process involves not only network transmission but also data encapsulation before transmission and protocol compatibility design after transmission. To ensure that the function menu instance can be displayed normally on different devices, the system performs structured encapsulation on the function menu instance before sending it, generating a menu delivery object that contains the menu data structure, style reference information, interaction event mapping, and rendering identifiers.

[0116] This menu delivery object is typically encapsulated using a lightweight data exchange format, such as JSON or Protobuf. During the encapsulation process, the system assigns a unique rendering identifier to each menu component, allowing the user terminal to quickly build a component tree. Redundant fields are compressed and intermediate state data is removed to reduce data volume and transmission bandwidth consumption. Menu style references are connected to the terminal's local style cache via path markers to avoid duplicate loading. Interaction event mapping uses serialized function binding to ensure that the client can reconstruct the complete interaction logic upon receiving the menu instance.

[0117] To improve the transmission security and data integrity, the system adopts a two-way authentication mechanism and an end-to-end encryption protocol to complete the delivery task. Before sending, the menu delivery object is signed by the server signature algorithm, and is sent to the user terminal in an encrypted connection based on the TLS protocol. The sending process is uniformly scheduled by the access layer gateway, supporting dynamic queuing and transmission scheduling based on device identification, network environment and service priority.

[0118] After receiving the menu delivery object, the user terminal first performs integrity check and signature verification, then parses the menu component instance according to the delivery format, loads it into the local interface engine for dynamic rendering, and rebuilds the event binding relationship, so that the final displayed menu has complete structure, interactive function and style consistency.

[0119] The sending of the function menu instance can be realized in various technical ways, such as through the WebSocket to realize the push mechanism of persistent connection, or through the short connection pull mechanism based on RESTful API, or through the Server Push mechanism based on HTTP / 2 to actively issue from the server.

[0120] For business scenarios with high real-time requirements, the system can choose the WebSocket channel for transmission, send the menu delivery object as a JSON string, and combine the ACK reply mechanism to ensure successful transmission. After the terminal device receives the data, it calls the local JavaScript interpreter or front-end rendering engine to rebuild the menu component.

[0121] For low-power mobile terminals, a lightweight binary protocol such as MessagePack can be used to compress and encode the menu delivery object, combined with a content fragmentation strategy for on-demand delivery, reducing the amount of data loaded at one time and adapting to network fluctuations and bandwidth limitations.

[0122] To enhance the fault tolerance of the terminal, the menu delivery object can add a check field, a rendering failure fallback structure and an expiration timestamp. When the client cannot normally parse or render the menu instance, it can automatically return to the last stable version or call the emergency rendering template, improving system availability.

[0123] This embodiment realizes efficient, secure and structured delivery of interface content from the backend to the frontend by encapsulating, signing and encrypting the function menu instance before transmitting it to the user terminal. The dynamic adaptation of the transmission mechanism and the structural decoupling design enable the same function menu instance to be correctly received, parsed and displayed by different types of terminal devices. In this way, not only the flexibility of menu permission rendering is enhanced, but also the loading speed of the interface and the stability of the system are significantly improved, while avoiding the problems of interface misrendering or permission disclosure caused by data loss or man-in-the-middle attacks.

[0124] The present invention relates to the field of data security technology and can be applied to business scenarios such as financial technology and medical health. A method, apparatus, device and medium for generating a dynamic function menu are disclosed, including: obtaining an access request carrying device type information sent by a user terminal; parsing the authentication status of the user account in response to the access request and obtaining the license status associated with the user account; generating a dynamic session context for defining function access qualifications and interface rendering strategies based on the authentication status, license status and device type information; loading a function menu strategy model containing a mapping of a set of associated function items to permission levels; determining a target permission level based on the dynamic session context, and matching a target subset of function items and a target rendering strategy; applying the target rendering strategy to process the target subset of function items to generate a function menu instance; and sending the function menu instance to the user terminal. The present invention generates a dynamic session context in real time by combining the user authentication status and the license status, driving the linkage between permission judgment and interface rendering, so that the function menu has the ability to dynamically switch according to the session status, thereby realizing menu generation and precise distribution based on actual authorization and device environment, effectively avoiding unauthorized access, and improving access compliance and terminal interaction experience.

[0125] In one embodiment, the above step S10 includes:

[0126] S101, receiving an encrypted network request data packet transmitted by a user terminal;

[0127] S102, decrypting the encrypted network request data packet to obtain a plaintext protocol data unit;

[0128] S103, extracting a user agent character string and a network environment identifier from the plaintext protocol data unit;

[0129] S104, verifying the integrity signature of the user agent character string;

[0130] S105, generating a device type identifier based on the verified user agent character string;

[0131] S106, collecting a device hardware feature code of the user terminal;

[0132] S107, associating the device type identifier with the device hardware feature code to generate a composite device identifier;

[0133] S108: Determine device type information based on the network environment identifier and the composite device identifier.

[0134] In this embodiment, to realize the terminal type awareness and context adaptive rendering mechanism, a complete terminal identification link needs to be built, and the device identity and running environment are accurately extracted through the data field carried in the access request. In the starting stage of the operation process, the system receives the network request data packet sent by the user terminal through the application layer listening interface, and the data packet is in an encrypted state, usually encapsulated using TLS or a custom transport layer encryption protocol, to avoid request content hijacking or tampering in public networks or untrusted environments.

[0135] After receiving the data packet, the system passes it to the network processing module for decryption operation. The decryption method dynamically selects symmetric or asymmetric key system according to the encryption algorithm identifier in the request, and calls the corresponding decryption engine to complete the plaintext recovery. After successful decryption, the plaintext protocol data unit is obtained, which is a structured content usually containing user agent string, network parameter field, authentication identifier, port information and timestamp.

[0136] The user agent string is extracted from the plaintext data unit, which usually follows the User-Agent syntax structure and identifies the operating system version, browser type, device manufacturer and other parameters of the current terminal. The system performs integrity check on the string, which includes verifying its attached digital signature field or comparing with the registered signature template library on the server. After passing the integrity verification, the user agent content is parsed, and the device type identifier is generated according to the predefined regular pattern or structure mapping rule, such as "mobile-android-large" or "pad-ios-retina".

[0137] In order to improve the accuracy of device identification, the system also calls additional channels or callback interfaces from the terminal request to collect device hardware feature codes. The hardware feature codes include but are not limited to device unique identifier (such as IMEI, Android ID, UUID), screen resolution, hardware serial number, GPU model, etc. These fields are collected through the terminal device calling local SDK or access interface in the browser runtime environment, and are uploaded with the request after encryption processing.

[0138] After receiving the device type identifier and device hardware feature code on the server, the system performs binding logic to generate a composite device identifier. This identifier is a non-reversible hybrid fingerprint that uniquely identifies the physical device individual currently accessed, and has stability and anti-fake properties. The generation method includes hash aggregation, salt encryption or clustering matching based on weighted similarity.

[0139] Further, the system makes multi-dimensional determination in combination with a network environment identifier. The network environment identifier comes from the network layer field in the request, such as the IP address segment, the network access mode identifier (such as WiFi, 4G, 5G), the APN parameter, the network service provider code, etc. The system obtains the network capability boundary of the access scene by analyzing these parameters.

[0140] Finally, the composite device identifier generated above is structurally bound with the network environment identifier to form device type information for subsequent context calculation. The device type information not only embodies the physical form characteristics of the device, but also reflects its access capability and network transmission characteristics, has cross-terminal consistency and dynamic adaptation capability, and can be used as one of the basic conditions for constructing session rendering strategies and function access strategies.

[0141] The embodiment establishes a full-link analysis mechanism from the access entry to the device recognition by encrypted receiving, structural decryption, field analysis, hardware feature collection, identity signature verification and network environment analysis of the terminal access request, and realizes high-precision restoration and context binding of the device type information. The mechanism breaks through the limitation of the traditional static identification method based on User-Agent, which can only roughly judge the terminal category, and can accurately capture the device running environment and user behavior characteristics while ensuring the transmission security and data integrity, thereby providing a data basis for subsequent dynamic rendering strategies. This way effectively improves the service consistency and response intelligence of the system in complex network conditions and heterogeneous terminals, and reduces the risk of menu display errors, function shielding or permission boundary problems caused by cross-device compatibility.

[0142] In one embodiment, the above step S20 includes:

[0143] S201, extracting session token data from the access request;

[0144] S202, verifying the digital signature and validity period of the session token data;

[0145] S203, when the digital signature and validity period verification are passed, parsing the user identity identifier from the session token data;

[0146] S204, querying an identity authentication database using the user identity identifier to obtain an account permission level and a session state value;

[0147] S205, combining the account permission level and the session state value to generate an authentication state;

[0148] S206, accessing an application programming interface of a license management system and sending a query request containing the user identity identifier;

[0149] S207, receiving a response data packet of the license management system, and parsing a license validity timestamp and an authorized range parameter in the response data packet;

[0150] S208, generating a license state value based on a comparison result of a current system time and the license validity timestamp;

[0151] S209, generating a license state by associating the authorized range parameter and the license state value.

[0152] In the embodiment, when the service end processes the access request of the user terminal, the security credential information related to the user identity needs to be extracted in the authentication path first. The session token embedded in the access request is usually attached to the Authorization field in the HTTP request header or embedded in a specific field in the request parameter body. The session token is constructed in the JWT (JSON Web Token) format or binary Token encapsulation mode, which contains the signature field, validity period, user ID, session context and other content fields, and has the transmission security and convenient disassembly.

[0153] The system extracts the token from the request and transmits it to the security verification module for integrity and timeliness verification. The integrity verification mainly verifies whether the digital signature content bound by the signature field is consistent with the signature generated by the service end key system, and the verification algorithm usually adopts HMAC-SHA256 or RSA-SHA512, to ensure that the session token is not modified in the transmission process. The validity period verification is performed by comparing the exp field in the token with the current system time to determine whether the token is in the valid time window.

[0154] After verification, the system further parses the user identity identifier field in the token, which is generally an internal user identifier (such as UID or UUID) and not a user account name, to prevent security risks caused by weak identification predictability. After parsing, the identity identifier is used as an index key to access the identity authentication database.

[0155] The identity authentication database is usually a relational database or a high-performance KV storage system, which stores the permission level information and the current session state value of each user. The permission level may be divided into multiple levels, such as "administrator", "ordinary user", "visitor", etc., to identify the accessible function range. The session state value reflects whether the user is currently in a valid login state, whether it is frozen, logged out or abnormally exited. The system generates an authentication state by combining the two fields, which is used to judge whether the menu structure can be loaded and whether the operation visibility needs to be limited.

[0156] At the same time of generating the authentication state, the system also needs to check the state of the function license bound under the user account. For this purpose, the system calls the external interface provided by the license management system, constructs a query request containing the user identity identifier, and sends it to the license management platform. The license management system usually runs in a microservice structure, and returns a response data packet containing multiple fields such as license effective timestamp, expiration timestamp, authorization scope, license identifier, issuing agency, etc. after accepting the request.

[0157] The system parses the returned data packet and obtains the effective timestamp field therein. By logically comparing the current system time with the effective timestamp, it is determined whether the license is within the effective period. If the current time is earlier than the effective time, or later than the expiration time, it means that the license is invalid or has expired; otherwise, it is valid. The comparison result is used to construct the license state value. The license state value is defined by enumeration, such as "valid", "about to expire", "invalid", etc.

[0158] Further, the system structurally associates the authorization scope parameter with the aforementioned generated state value to generate the license state. The authorization scope parameter is used to indicate the user's use permission on a specific system function or module, such as "menu configuration module available", "export function limited", etc. The final generated license state not only expresses the time effectiveness of the license, but also indicates the applicable boundary and permission coverage of the license in different function modules.

[0159] The authentication state and the license state are combined and transmitted to the subsequent dynamic session context construction process, which is used to dynamically determine the user function access qualification and interface response strategy, and to provide precise, real-time, and secure personalized function menu content for the user terminal.

[0160] The embodiment establishes a joint determination mechanism that integrates user authentication state and license state by signature and validity period verification of the session token, user identity extraction and permission level query, session state synthesis and license information linkage analysis, which can accurately identify the actual function availability and session legality of the user at the current time point, and avoid the compliance risk that the traditional static permission control still retains the operation entry in the login state loss or license expiration scenario. The mechanism introduces license effective time judgment and authorization scope binding logic, which not only realizes real-time monitoring of the user session state, but also ensures the dynamic adjustment ability of function access qualification, provides data basis for intelligent pruning of function menu, and effectively improves the security management and control ability and service personalization ability of the system in a multi-role, multi-license, and multi-terminal environment.

[0161] In one embodiment, the above step S30 comprises:

[0162] S301, parse the authentication state to obtain the permission level identifier and the session active flag;

[0163] S302, extract the authorized function list and the validity period flag in the license state;

[0164] S303, analyze the device type information to obtain the device classification identifier and the screen display parameter;

[0165] S304, filter the authorized function list according to the permission level identifier to generate a function access qualification set;

[0166] S305, determine the base layout mode based on the device classification identifier, determine the responsive breakpoint according to the screen display parameter, and set the interaction complexity level based on the session active flag;

[0167] S306, create a context data structure containing a function access qualification field, a layout mode field, a responsive breakpoint field, an interaction complexity field, and a time control field;

[0168] S307, write the function access qualification set into the function access qualification field, write the base layout mode into the layout mode field, write the responsive breakpoint into the responsive breakpoint field, write the interaction complexity level into the interaction complexity field, and write the validity period flag into the time control field to obtain a written context data structure;

[0169] S308, generate a dynamic session context based on the written context data structure.

[0170] In this embodiment, after the system receives the authentication state, the license state, and the device type information, it first needs to parse the authentication state to obtain the core identifiers representing the user's permission level and the session state. The authentication state is usually composed of a permission level identifier and a session active flag. The permission level identifier is an internal system-defined level enumeration field, which can be expressed in the form of an integer or a string to represent different user levels, such as "LEVEL_ADMIN" and "LEVEL_VIEWER". The session active flag is a Boolean type or a state enumeration field, which is used to indicate whether the current session is in an active state, such as whether it has timed out, whether it has been frozen, whether it has a conflict with a remote login, etc.

[0171] After parsing the authentication state, the system continues to extract two key components in the license state, namely the authorized function list and the validity period flag. The authorized function list is a structured set that lists all function module identifier codes corresponding to the user's license, and the data structure can be an array, a set, or a bitmap compression structure. The validity period flag is composed of the effective time, the expiration time, and the current check state of the license, which supports the judgment of time control strategies in the subsequent context.

[0172] The processing of device type information also requires detailed analysis, including both device classification identifiers and screen display parameters. Device classification identifiers are used to indicate the type of device in the system's preset classification system, such as "PHONE", "TABLET", "DESKTOP", "SMARTTV", etc., which determines the adaptable rendering layout strategy. Screen display parameters usually include resolution, aspect ratio, pixel density, etc., which are derived from user agent parsing results, device hardware characteristics, or front-end visual window measurement results. The system determines the responsive breakpoints for screen adaptation through these parameters and defines interface response rules triggered in different resolution intervals.

[0173] After completing the decomposition of all original data, the system begins to calculate the function access qualification set based on these data. This operation is achieved by filtering the permission level identifier and the authorized function list. The filtering rules are usually executed according to the corresponding matrix of permission levels and function modules, for example, the permission level "LEVEL_USER" can only access functions F1 and F2, and the filtered set is the intersection result of {F1, F2}, ensuring that the generated access set is strictly controlled by the intersection of permission levels and license ranges.

[0174] Next, the system uses the device classification identifier to determine the basic layout mode. This mode is a pre-defined interface structure configuration template, such as "COMPACT_LAYOUT", "GRID_LAYOUT", "FLUID_LAYOUT", etc., which determines the layout organization of the main menu, content area, and interactive controls. The system calculates breakpoint values based on screen display parameters, which are used to select whether to enable horizontal scrolling, folded menus, or mobile styles. The breakpoint values are mapped through configuration files or media queries, conforming to responsive design specifications. At the same time, combined with the session active marker, set the interaction complexity level, if the user is in an active login state, more complex interactive functions such as dragging and asynchronous loading can be assigned; if in a low active state, limit the interaction depth to reduce performance consumption.

[0175] All calculation results are used to construct a context data structure containing five types of fields: function access qualification field, layout mode field, responsive breakpoint field, interaction complexity field, and time control field. The system assigns values to each field in the write operation to ensure the integrity of the structure and the semantic consistency between fields. The write process needs to perform field mapping rules, field type checking, and structure checking to ensure that the data format conforms to the expected structure body definition, such as JSON structure or Protocol Buffer definition.

[0176] After the data structure is completed, the final dynamic session context can be generated based on the structure. The context serves as a basic data source for subsequent function menu instance generation, interface rendering logic distribution, permission verification, and dynamic control strategy, supporting the entire system to make response behavior decisions for different terminals and different identity users, ensuring the accuracy of interface presentation, the real-time nature of access control, and the adaptability of resource rendering.

[0177] The embodiment dynamically constructs a context data structure with multi-dimensional decision basis on the server by structurally integrating user permission levels, license authorization ranges, and device environment features, effectively solving the problems of delayed updates, unauthorized access, and layout mismatch caused by the separation of traditional interface response and permission control logic. By introducing access qualification filtering logic, layout template selection logic, and responsive breakpoint calculation mechanisms, the system has the ability to accurately issue content, flexibly combining function visibility and interface response strategies for different users, different devices, and different license states, thereby ensuring the continuity of user operation experience, the security of data access, and the rendering quality of terminal adaptation, and constructing a rendering context generation mechanism with high scalability and real-time performance.

[0178] In one embodiment, the above step S40 includes:

[0179] S401, access the pre-stored function menu strategy model configuration file;

[0180] S402, verify the digital signature and version compatibility of the function menu strategy model configuration file;

[0181] S403, when the verification is passed, parse the function menu strategy model configuration file to obtain model structure description data;

[0182] S404, extract the function item set definition from the model structure description data;

[0183] S405, parse the permission level mapping table in the model structure description data, the permission level mapping table containing permission level identifiers, corresponding function item subset identifiers, and rendering strategy identifiers;

[0184] S406, according to the permission level mapping table, generate an associated mapping of permission level identifiers and function item subset identifiers, and rendering strategy identifiers;

[0185] S407, construct a function menu strategy model instance containing the function item set definition and the associated mapping;

[0186] S408, load the function menu strategy model instance to the runtime memory.

[0187] In this embodiment, starting from the access operation of the function menu strategy model configuration file, the configuration file is usually stored in a structured format (such as JSON, YAML, Protocol Buffer, etc.) in the configuration resource path of the server side, with a unique version number and an encrypted signature field. During the access process, the system first locates the physical path or service address of the target configuration file according to the function menu strategy model identification required by the current running environment, and completes the file reading or remote request operation.

[0188] After the file is obtained, the system verifies the digital signature and version compatibility of the configuration file. Signature verification is used to confirm that the file content has not been tampered with, and its mechanism can be based on performing a hash operation on the file body and signing it with the system private key, and the client uses the matching public key to verify. The version compatibility check is used to ensure that the current system running environment can parse and correctly execute the structure rules described in the configuration file. The verification method includes comparing the minimum compatible version number recorded in the configuration file with the current system engine version number, or performing a configuration file structure pre-validation process.

[0189] If the signature and version verification are passed, the system begins to parse the configuration file to obtain model structure description data. The structure description data is the meta-information carrier of the model, including two core parts: function item set definition and permission level mapping table. The function item set definition is the basis for the composition of the function menu, and its data structure is usually a mapping table composed of function identifiers and function attribute sets. The function identifier indicates each function module, such as "FUNC_DASHBOARD", "FUNC_REPORT_VIEW", etc.; the function attribute set includes function name, display label, dependent module, trigger event identifier, icon path, and other presentation and behavior configuration fields.

[0190] The permission level mapping table defines how different permission levels are mapped to function subsets and rendering strategies. The table structure contains multiple triple records, each record consisting of a permission level identifier, a function item subset identifier, and a rendering strategy identifier. The permission level identifier corresponds to the user's permission level, the function item subset identifier points to the index or filtering rule of a certain preset subset in the function item set, and the rendering strategy identifier indicates the interface layout and style strategy applicable under this permission level, such as "STRATEGY_GRID_MINIMAL", "STRATEGY_TAB_EXTENDED", etc.

[0191] After parsing is completed, the system generates an associated mapping structure from the permission level identifier to the function item subset identifier and the rendering strategy identifier based on the mapping table. The mapping is usually constructed in the form of nested dictionaries, hash tables, or compressed index arrays to support low-latency matching queries in high-frequency access scenarios, and to eliminate runtime computation costs by pre-building mapping relationships.

[0192] After extracting the function item set definition and constructing the permission mapping structure, the system combines it to build a function menu strategy model instance. This instance is a runtime structure that has the ability to quickly query the function subset corresponding to the permission level and the rendering strategy, and supports external modules to read data through interface calls. The model instance structure needs to include the function item set field, the permission mapping table field, and the cache meta information field, and has the ability of concurrent access protection and consistency management.

[0193] After completing the model construction, the system loads it into the runtime memory. The loading method can be selected according to the deployment structure, such as process-level memory cache, distributed cache service (such as Redis, Memcached), or service local global variable. This loading process needs to be registered to the context control center or configuration center to ensure that the subsequent session context generation and function menu generation process can directly read the model data, avoiding repeated access to persistent storage and improving the running efficiency.

[0194] This embodiment constructs the dynamic mapping relationship between permission levels, function subsets, and rendering strategies by loading structured function menu strategy models, significantly enhancing the system's response capability when facing different user permissions and interface adaptation needs. By decoupling and structuring the management of function item sets and mapping logic, the system can accurately select function menus and rendering strategies based on runtime context, avoiding authorization mismatch problems and rendering template redundancy problems caused by static menu configuration. At the same time, the strategy model loaded into memory improves data acquisition efficiency, supports high-concurrency access and low-latency response, and lays a stable and efficient foundation for subsequent dynamic session context-driven menu generation and permission control. This mechanism effectively improves the flexibility, security, and maintainability of the system, adapting to complex running environments with multiple devices, multiple permissions, and multiple scenarios.

[0195] In one embodiment, the above step S50 includes:

[0196] S501, extracting a session validity period mark from the time control field of the dynamic session context;

[0197] S502, when the session validity period mark is not expired, obtaining a permission level identifier from the function access qualification field of the dynamic session context;

[0198] S503, searching for the permission level identifier in the associated mapping of the function menu strategy model;

[0199] S504, when a matching item is found, obtaining the corresponding function item subset identifier and rendering strategy identifier from the associated mapping;

[0200] S505, using the function item subset identifier as a key value, locating the target function item subset in the index table defined by the function item set of the function menu strategy model;

[0201] S506, accessing the pre-stored rendering strategy library, retrieving the target rendering strategy according to the rendering strategy identifier;

[0202] S507, creating a matching result object containing the target function item subset reference and the target rendering strategy reference.

[0203] In this embodiment, the time limit control field is first extracted from the dynamic session context, and the session validity period mark is parsed. The mark is usually in the format of a standardized timestamp, recording the expiration time of the current user session. The system will judge whether the session is expired by comparing with the current server time, if it is expired, the subsequent matching process will be terminated, and the session invalid response will be returned, preventing invalid sessions from continuing to request interface rendering resources or function modules. This operation combines the time synchronization mechanism and the time limit control logic, and has the ability to prevent the drift of permissions and the disconnection of context.

[0204] If the session validity period is still within the legal range, the permission level identifier is further extracted from the function access qualification field in the dynamic session context. The permission level identifier is the core anchor point in the permission control mechanism, usually a set of strings or enumeration values, used to identify the function access permission level of the current user, such as "LEVEL_ADMIN", "LEVEL_VIEWER", "LEVEL_OPERATOR", etc. This field is dynamically generated by the previous step according to the user authentication state and the license state, with real-time and customization features.

[0205] After extracting the permission level identifier, the system performs matching lookup in the associated mapping of the function menu strategy model. The mapping structure is in the form of key-value pair, taking the permission level identifier as the key, and the combination tuple of function item subset identifier and rendering strategy identifier as the value. The lookup process uses data structures such as hash index or compressed prefix tree to accelerate, ensuring the retrieval efficiency in high concurrency environment. If there is a match, it means that the permission level has a legal function and display strategy definition, and the subsequent steps can be continued; if there is no hit, return the permission not configured error prompt, indicating that the backend strategy configuration is missing or data is abnormal.

[0206] After successfully obtaining the function item subset identifier and the rendering strategy identifier, the system locates the function item set definition in the function menu strategy model using the function item subset identifier as the key. The function item set definition is a structured index table that organizes and manages all function items using a grouping list or a tag filtering mechanism. The function item subset identifier can directly point to a certain group of function item sets (such as division according to business function modules) or generate sets in a rule filtering manner (such as filtering function items through the tag combination rule "Tag A and Tag B"). After this positioning operation is completed, the actual data reference or object pointer of the target function item subset is obtained.

[0207] While obtaining the function item subset, the system also needs to access the pre-stored rendering strategy library. The rendering strategy library is a collection of resources for interface display control, where each record is indexed by a unique rendering strategy identifier and contains corresponding layout structure definitions, control combination schemes, and interaction behavior binding rules. The system retrieves the rendering strategy based on the previously matched rendering strategy identifier and returns the structured configuration data or execution script module of the rendering strategy. These strategy files can be presented in the form of responsive layout languages (such as CSS media queries description), UI framework component templates (such as Vue / React components), or embedded script configurations (such as JSON-driven configurations) to adapt to different terminal rendering environments and front-end frameworks.

[0208] Finally, the system creates a matching result object that contains the reference of the target function item subset and the reference of the target rendering strategy. This object can be structured as a data transfer object (DTO) or a context extension block, embedded in the current user's request session flow, and passed to the subsequent function menu instance construction step as an input parameter. By encapsulating the function definition and the display strategy into one, this matching result object has complete permission semantics and interface rendering logic, which can drive the terminal to generate customized function entries and layouts.

[0209] This embodiment establishes a mapping and matching mechanism between the dynamic session context and the function menu strategy model, ensuring that users with different permission levels can accurately obtain their corresponding function modules and interface display strategies. By combining session time validation and permission mapping lookup, the system effectively blocks resource access risks after session failure, preventing interface abuse and menu hijacking. By extracting structured permission identifiers and quickly matching function item subsets and rendering strategies, the system avoids the permission mismatch and rendering abnormality problems caused by traditional static menu templates, while supporting responsive adaptation and terminal layout diversity. The final matching result object provides accurate input for function menu instance generation, supporting precise control and scalable deployment in cross-device, multi-permission, and multi-session scenarios. This mechanism improves the granularity, security of permission control, and flexibility of rendering behavior, and is a key link to achieve agile function delivery and user interface adaptation.

[0210] In one embodiment, the above step S60 comprises:

[0211] S601, parsing the target rendering strategy to obtain layout mode configuration, interaction strategy configuration and visual style configuration;

[0212] S602, instantiating a menu container component according to the layout mode configuration to generate a basic menu layout framework;

[0213] S603, inserting the function item elements of the target function item subset into the basic menu layout framework;

[0214] S604, registering an event listener in the basic menu layout framework based on the interaction strategy configuration;

[0215] S605, rendering a menu visual style through the visual style configuration;

[0216] S606, serializing the basic menu layout framework, event listener and rendered menu visual style into an executable menu component instance.

[0217] In this embodiment, the target rendering strategy is first taken as input, and the layout mode configuration, interaction strategy configuration and visual style configuration encapsulated in the strategy are parsed. The layout mode configuration is usually expressed in a nested structured template or component hierarchical description language, such as using JSON Schema, YAML tree or DSL template structure, and its content includes menu container types (such as list, tree, grid), arrangement methods (horizontal, vertical, responsive grid) and nested structure rules. The interaction strategy configuration defines the response mechanism, focus switching logic, keyboard shortcut behavior and asynchronous loading logic of each function item in different states. The visual style configuration describes the appearance characteristics of the menu interface on the terminal, including color theme, border style, icon set, font style, space white space and animation transition effect, usually in the form of CSS template, style variable table or UI theme specification.

[0218] After parsing, the system will start the instantiation process of the menu container component based on the layout mode configuration. The menu container component is the basic carrying framework, which determines the spatial organization and control packaging form of the function item subset. Its implementation can be based on a general UI component library, such as using the container template class under the framework of Vue, React, Flutter, etc., calling the constructor to complete the initial state setting of the menu container, including container size, sub-component slot, scrolling strategy and nesting rules, etc.

[0219] After the container is initialized, the system inserts the function item elements in the target function item subset into the basic menu layout framework one by one. The insertion process completes the construction and assembly of the sub-components through the function item definition structure (usually containing function name, binding event, icon reference, available state, etc.), and can use virtual DOM description tree structure or component combination form to splice view nodes, ensuring that the function items are logically and structurally consistent with the container.

[0220] After the structure is assembled, the system registers event listeners on the corresponding function item elements or container elements according to the interaction strategy configuration. The registration method is selected according to the terminal running environment, and addEventListener or framework event binding (such as @click, v-on) is used on the Web side, touch event callback (such as onTap, gestureHandler) is used on the mobile side, and SDK binding mechanism is used on the desktop client. The binding rules of the listener are extracted from the strategy, which supports dynamically enabling / disabling the listener according to the function item state, ensuring that the interaction response is consistent with the function permission logic.

[0221] Subsequently, the system parses the visual style configuration and applies it to the completed menu layout, performing rendering operations on the menu visual style. Style application supports theme variable injection, responsive breakpoint adaptation, style class binding, and dynamic style overlay mechanisms, which can select different theme file loading paths based on the current device resolution, interaction complexity level, or dark / light mode. The visual rendering process can use Shadow DOM to isolate style conflicts, or use a CSS-in-JS scheme (such as styled-components) to dynamically bind styles and component logic.

[0222] Finally, the system structures the completed assembly and rendering of the basic menu layout framework, the registered event listener set, and the rendered menu visual style into an executable menu component instance. This instance is a rendering unit that can be directly loaded into the front-end running environment, with complete behavior response logic and interface display capabilities. Serialization operations support JSON packaging, Base64 encoding transmission, or binary structure packaging to adapt to cross-terminal platform data parsing mechanisms and performance requirements, and are used as the final output for subsequent terminal push process calls.

[0223] Example: In the digital outpatient management platform in the medical health field, in order to realize the fine distribution of permissions based on personnel identity and device state and dynamic interface response, a mechanism that can dynamically build a function menu when a user logs in is needed. The system supports multiple roles such as doctors, nurses, and medical technicians, and connects different terminal devices from different manufacturers, including diagnosis and treatment workstations, mobile ward round tablets, remote consultation machines, etc. The system needs to automatically complete interface rendering and function restriction according to user type, authorized range of license, and device capability.

[0224] When a doctor accesses the system through a mobile ward round tablet, the platform first receives an access request containing device type information. The request sends an encrypted network request packet through an HTTPS channel. The system decrypts the packet and extracts the plaintext protocol data unit. The User-Agent string and access network identifier are obtained. After verifying the signature integrity of the User-Agent string, a device type identifier is generated (such as "ARM64_MobilePad"). At the same time, the mobile device management system interface is called to collect device hardware fingerprints such as motherboard model, kernel version, and MAC address, and a composite device identifier is generated. Based on the network identifier (such as the internal WLAN of a medical institution) and device fingerprint information, it is determined that the terminal is a "mobile in-hospital compliant device", and the device type information is generated accordingly.

[0225] The system then parses the session token contained in the access request, verifies its digital signature and validity period, and extracts the identity of the doctor's account (such as the physician code ID) accordingly. The system accesses the unified identity authentication center to query the account's permission level (such as "Deputy Chief Physician") and current session activity status, and then generates an authentication state. At the same time, a query request is sent to the medical license management system to confirm whether the doctor's professional qualification license is within the valid period, and the current authorized scope (such as "outpatient prescription" "medical record writing" "laboratory test order") is extracted. The system determines whether the license is still within the authorized period based on the current time, and generates the corresponding license status.

[0226] The system generates a dynamic session context based on the authentication state, license status, and device type information. The permission level "Deputy Chief Physician" is mapped to the permission identifier "LV3", which is combined with the active flag to confirm that it can access all functions. The device is a mobile platform, so the system selects a "grid-based responsive layout" accordingly, and sets the responsive breakpoints based on the screen resolution (1280x800) and view height. The interaction complexity is set to "medium", considering the high frequency of operation but moderate depth of interaction in the mobile ward round scenario. The expiration time field is set to the minimum expiration time point before the license expires. All the above fields are packaged into a structured context object.

[0227] Subsequently, the system accesses the pre-deployed function menu strategy model configuration file, verifies its signature validity and version compatibility, parses the function item set definition, including "prescription" "laboratory test review" "medical record modification" "video consultation" and other modules, and extracts the permission level mapping table. LV3 permission corresponds to all the above functions and rendering strategy "Mobile_Grid_Card". The system constructs the mapping relationship between permission level and function subset and rendering strategy, forms a function menu strategy model, and loads it into the system running memory.

[0228] The system determines that the validity period field of the current dynamic session context is still within the authorized period, extracts the "LV3" permission level identifier, and finds the corresponding function item subset identifier and rendering strategy identifier in the model mapping. Further index the function item set to confirm that "prescription" and "review test report" are the target function item subset, and access the rendering strategy library to obtain the "Mobile_Grid_Card" strategy. This strategy specifies that the menu should be a card grid layout, the card size is adaptive according to the screen width, the interaction mode is point selection expansion, the theme is the blue and white color of medical institutions, and it supports simple style and minimal level nesting.

[0229] According to the rendering strategy, the system instantiates the menu container component as a responsive grid layout container, inserts the target function items as card-type subcomponents, and binds each subcomponent to its logical function. The interaction strategy defines event binding logic such as "single-click to expand the prescription interface" and "long-press to display help instructions", and the system registers the corresponding event listeners. Subsequently, the system renders the visual style, applies uniform fonts, icons, and animation effects to all card components, and completes the assembly of all elements. Finally, the menu instance is serialized into an executable component package and sent to the mobile ward-round tablet used by the doctor through the WebSocket push mechanism, realizing the instant generation and display of the menu interface.

[0230] A comprehensive financial service platform provides multiple function modules including online account opening, portfolio management, risk assessment, contract signing, and transaction instruction issuance, and covers multiple roles such as ordinary investors, high net worth clients, fund sales representatives, and compliance auditors. The system supports multi-terminal access, including web browsers, tablet apps, and self-service terminals, and different roles and devices have different operation permissions and interface display requirements. To avoid unauthorized access, expired authorization abuse, and interface loading delay, the platform uses a dynamic function menu strategy driving mechanism to achieve precise control of permissions and intelligent rendering of interfaces.

[0231] When a registered financial advisor uses a self-service device configured by the company to operate customer product recommendation, the system first receives its access request through the VPN channel, which contains device type information. The system parses the encrypted network packet, extracts the user agent string (identified as "RM-Terminal-v3.2") and network access environment identifier (such as internal bridge address) in the plaintext protocol data unit. After verifying the integrity of the user agent string, a device type identifier (such as "FIN_KIOSK_X86") is generated. The system also collects device hardware feature code information (including motherboard number, TPM signature, public key digest, etc.) through the terminal management control module, forming a composite device identifier. Combined with the network environment and device identifier, the system determines the current device as a "controlled offline display terminal" and generates its device type information.

[0232] The system further extracts an OAuth2-based session token from the access request, verifies its signature and time validity, and confirms the legality to obtain the employee ID of the financial advisor. The system accesses the unified identity platform to query the current session state and role level (such as "product recommendation consultant" role identifier LV2) of the ID, and combines it into an authentication state. At the same time, call the license management center interface to check the current license validity of the user (such as "fund sales qualification" license), parse its authorization module (for example "recommend equity funds" "access risk rating record") and effective time interval, and compare with the current time to obtain the license state.

[0233] Based on the above authentication state, license state and device type information, the system generates a dynamic session context. The permission level is LV2, and the session state is "active"; the device type is a display terminal with 1080p resolution and embedded touch screen. The system determines the interaction complexity to be "low", the layout mode to be "fixed scrollable", and sets the responsive breakpoint threshold to 1280px. The authorization module only contains part of the fund product module, so the function access set is generated after filtering. The function access set, device adaptation layout strategy, response breakpoint, interaction level and license validity period fields are integrated into the context structure to form a dynamic session context.

[0234] Subsequently, the system accesses the menu strategy model configuration file and completes signature and version verification, parses the model structure definition, including different function item sets (such as "product browsing", "transaction simulation", "investor notice preview", "contract push", etc.) and the mapping rules between permission level-function item-rendering strategy. The LV2 role is mapped to a specific subset of function items and rendering strategy "Grid_Fixed_Display_LowInteraction", and the model instance is loaded into the running memory.

[0235] The system reads the current permission level (LV2) from the dynamic session context, retrieves the corresponding function item subset identifier and rendering strategy identifier in the mapping table. According to the index table, the subset is obtained, and it is confirmed that the current user can only use the function items such as "product browsing" and "risk rating record viewing". At the same time, the target rendering strategy is retrieved from the rendering strategy library, which limits the menu to adopt the form of left fixed navigation bar plus main area content panel, disables dragging and hierarchical nesting, and adopts gray-blue tone and large font style.

[0236] Then the system performs rendering processing: first, create a basic menu container, define a grid framework according to the strategy layout; then insert each function item subcomponent into the corresponding container unit and register event listeners (such as touch response, prompt pop-up window, etc.); then apply uniform visual style to render component style, including responsive spacing, uniform icons, button style, etc., and finally serialize to generate a runnable menu component package. Through the WebSocket channel, the menu component is sent to the user terminal, so that the interface is dynamically rendered and instantly displayed under the current permission, authorization and device conditions.

[0237] The embodiment can realize differentiated, dynamic and policy-based construction of the user terminal interface by fusing the function item subset driven by the permission matching result with the multi-dimensional rendering strategy. The overall processing flow completes the function structure organization, behavior logic injection and visual style shaping from bottom to top, ensuring that each permission level user only gets the functions within their permission range and displays them in the most optimal interactive experience under the terminal adaptation of the display mode. The layout configuration and the interaction strategy are decoupled, which facilitates policy version control and remote update, centralized management of visual style, and supports unified theme style and responsive adaptation. The final menu component instance has the features of plug-and-play, low coupling and high scalability, can be quickly loaded into the terminal system for display, and realizes efficient collaboration of permission control, interface generation and interactive behavior.

[0238] In an embodiment, a dynamic function menu generation device is provided, which corresponds to the dynamic function menu generation method in the above embodiment. Referring to Figure 3 , Figure 3 A functional module schematic diagram of a preferred embodiment of the dynamic function menu generation device of the present application. The access analysis module 10, the identity verification module 20, the session context generation module 30, the strategy model loading module 40, the permission mapping module 50, the menu generation module 60 and the menu transmission module 70. The detailed description of each functional module is as follows:

[0239] The access analysis module 10 is used to obtain the access request sent by the user terminal and carrying the device type information;

[0240] An identity authentication module 20 is configured to parse an authentication state of a user account and obtain a license state associated with the user account in response to the access request;

[0241] A session context generation module 30 is configured to generate a dynamic session context for defining a function access qualification and an interface rendering strategy according to the authentication state, the license state and the device type information;

[0242] A policy model loading module 40 is configured to load a function menu policy model corresponding to a rendering strategy of a set of function items and different permission levels;

[0243] A permission mapping module 50 is configured to determine a target permission level in the function menu policy model based on the dynamic session context, and match a target function item subset and a target rendering strategy according to the target permission level;

[0244] A menu generation module 60 is configured to process the target function item subset through the target rendering strategy to generate a function menu instance;

[0245] A menu transmission module 70 is configured to send the function menu instance to the user terminal.

[0246] In an embodiment, the access parsing module 10 is specifically configured to:

[0247] receive an encrypted network request data packet transmitted by a user terminal;

[0248] decrypt the encrypted network request data packet to obtain a plaintext protocol data unit;

[0249] extract a user agent string and a network environment identifier from the plaintext protocol data unit;

[0250] verify the integrity signature of the user agent string;

[0251] generate a device type identifier based on the verified user agent string;

[0252] collect a device hardware feature code of the user terminal;

[0253] associate the device type identifier with the device hardware feature code to generate a composite device identifier;

[0254] determine device type information based on the network environment identifier and the composite device identifier.

[0255] In an embodiment, the identity authentication module 20 is specifically configured to:

[0256] extract a session token data from the access request;

[0257] verifying the digital signature and the validity period of the session token data;

[0258] when both the digital signature and the validity period are verified, resolving a user identity identifier from the session token data;

[0259] querying an identity authentication database using the user identity identifier to obtain an account permission level and a session state value;

[0260] combining the account permission level and the session state value to generate an authentication state;

[0261] accessing an application program interface of a license management system and sending a query request containing the user identity identifier;

[0262] receiving a response data packet of the license management system and resolving a license validity timestamp and an authorized scope parameter in the response data packet;

[0263] generating a license state value based on a comparison result of a current system time and the license validity timestamp;

[0264] associating the authorized scope parameter and the license state value to generate a license state.

[0265] In an embodiment, the session context generation module 30 is specifically configured to:

[0266] resolving the authentication state to obtain a permission level identifier and a session active marker;

[0267] extracting an authorized function list and a validity period marker in the license state;

[0268] analyzing the device type information to obtain a device classification identifier and a screen display parameter;

[0269] filtering the authorized function list according to the permission level identifier to generate a function access eligibility set;

[0270] determining a basic layout mode based on the device classification identifier, determining a responsive breakpoint according to the screen display parameter, and setting an interaction complexity level based on the session active marker;

[0271] creating a context data structure containing a function access eligibility field, a layout mode field, a responsive breakpoint field, an interaction complexity field, and a time control field;

[0272] writing the set of functional access qualifications into a functional access qualifications field, writing the base layout pattern into a layout pattern field, writing the responsive breakpoint into a responsive breakpoint field, writing the interaction complexity level into an interaction complexity field, and writing the validity period marker into a time-to-live field, to obtain a written context data structure;

[0273] generating a dynamic session context based on the written context data structure.

[0274] In an embodiment, a policy model loading module 40 is specifically configured to:

[0275] access a pre-stored functional menu policy model configuration file;

[0276] verify the digital signature and version compatibility of the functional menu policy model configuration file;

[0277] when the verification passes, parse the functional menu policy model configuration file to obtain model structure description data;

[0278] extract a set of functional item definitions from the model structure description data;

[0279] parse a permission level mapping table in the model structure description data, the permission level mapping table containing permission level identifiers, corresponding functional item subset identifiers, and rendering policy identifiers;

[0280] generate an association mapping of permission level identifiers and functional item subset identifiers, and rendering policy identifiers according to the permission level mapping table;

[0281] construct a functional menu policy model instance containing the set of functional item definitions and the association mapping;

[0282] load the functional menu policy model instance into a runtime memory.

[0283] In an embodiment, a permission mapping module 50 is specifically configured to:

[0284] extract a session validity period marker from a time-to-live field of the dynamic session context;

[0285] when the session validity period marker is not expired, obtain a permission level identifier from a functional access qualifications field of the dynamic session context;

[0286] look up the permission level identifier in an association mapping of the functional menu policy model;

[0287] when a match is found, obtain a corresponding functional item subset identifier and a rendering policy identifier from the association mapping;

[0288] locating a target function item subset in an index table defined by a function item set of the function menu policy model using the function item subset identifier as a key value;

[0289] accessing a pre-stored rendering policy library to retrieve a target rendering policy according to the rendering policy identifier;

[0290] creating a matching result object containing a reference to the target function item subset and a reference to the target rendering policy.

[0291] In an embodiment, the menu generation module 60 is specifically configured to:

[0292] parsing the target rendering policy to obtain a layout pattern configuration, an interaction policy configuration and a visual style configuration;

[0293] instantiating a menu container component according to the layout pattern configuration to generate a basic menu layout framework;

[0294] inserting function item elements of the target function item subset into the basic menu layout framework;

[0295] registering an event listener in the basic menu layout framework based on the interaction policy configuration;

[0296] rendering a menu visual style through the visual style configuration;

[0297] serializing the basic menu layout framework, the event listener and the rendered menu visual style into an executable menu component instance.

[0298] In one embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in Figure 4 The computer device includes a processor, a memory, a network interface and a database connected through a system bus. The processor of the computer device is configured to provide determination and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium, an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is configured to communicate with an external user terminal through a network connection. The computer program is executed by the processor to implement the functions or steps of the server side of the dynamic function menu generation method.

[0299] In one embodiment, a computer device is provided, which can be a user terminal, and an internal structure diagram of the computer device can be as shown in Figure 5The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. The processor of the computer device is configured to provide determination and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is configured to communicate with an external server through a network connection. The computer program is executed by the processor to implement the functions or steps of the user side of the generation method of the dynamic function menu.

[0300] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the following steps when executing the computer program:

[0301] An access request carrying device type information sent by a user terminal is obtained;

[0302] In response to the access request, the authentication status of a user account is parsed, and the license status associated with the user account is obtained;

[0303] According to the authentication status, the license status and the device type information, a dynamic session context for defining function access eligibility and interface rendering strategy is generated;

[0304] A function menu strategy model corresponding to the rendering strategy of the associated function item set and different permission levels is loaded;

[0305] Based on the dynamic session context, a target permission level is determined in the function menu strategy model, and a corresponding target function item subset and a target rendering strategy are matched according to the target permission level;

[0306] The target function item subset is processed through the target rendering strategy to generate a function menu instance;

[0307] The function menu instance is sent to the user terminal.

[0308] In one embodiment, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to implement the following steps:

[0309] An access request carrying device type information sent by a user terminal is obtained;

[0310] In response to the access request, the authentication status of a user account is parsed, and the license status associated with the user account is obtained;

[0311] According to the authentication state, the license state and the device type information, a dynamic session context is generated for defining a function access qualification and an interface rendering strategy;

[0312] A function menu strategy model is loaded, in which a set of associated function items and rendering strategies corresponding to different permission levels are matched;

[0313] Based on the dynamic session context, a target permission level is determined in the function menu strategy model, and a corresponding target function item subset and a target rendering strategy are matched according to the target permission level;

[0314] The target function item subset is processed through the target rendering strategy, and a function menu instance is generated;

[0315] The function menu instance is sent to the user terminal.

[0316] It should be noted that the functions or steps that the computer readable storage medium or the computer device can implement correspond to the related descriptions of the server side and the user terminal side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0317] Those skilled in the art can understand that all or part of the processes in the foregoing method embodiments can be completed by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the foregoing method embodiments. In the embodiments provided in the present application, any reference to a memory, storage, database or other medium can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM) and memory bus dynamic RAM (RDRAM).

[0318] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is taken as an example, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0319] It should be noted that if non-company software tools or components appear in the embodiments of the present application, they are only used for example introduction and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for generating a dynamic function menu, characterized in that: The following steps are involved: Obtaining an access request sent by a user terminal that carries device type information; In response to the access request, resolving the authentication status of the user account and obtaining the license status associated with the user account; Generate a dynamic session context for defining function access qualifications and interface rendering strategies based on the authentication status, license status, and device type information; Loading a function menu strategy model for associating a set of function items with rendering strategies corresponding to different permission levels; Based on the dynamic session context, determining a target permission level in the function menu policy model, and matching a corresponding target function item subset and a target rendering strategy according to the target permission level; Processing the target function item subset by the target rendering strategy to generate a function menu instance; The function menu instance is sent to the user terminal.

2. The method for generating a dynamic function menu according to claim 1, wherein: Obtain access requests sent by user terminals that carry device type information, including: Receiving an encrypted network request data packet transmitted by a user terminal; Decrypting the encrypted network request data packet to obtain a plaintext protocol data unit; extracting a user agent string and a network environment identifier from the plaintext protocol data unit; Verifying the integrity signature of the user agent string; Generate a device type identifier based on the validated user agent string; Collecting the device hardware feature code of the user terminal; Associating the device type identifier with the device hardware feature code to generate a composite device identifier; Device type information is determined based on the network environment identifier and the composite device identification.

3. The method for generating a dynamic function menu according to claim 1, wherein: In response to the access request, resolving the authentication status of the user account and obtaining the license status associated with the user account includes: extracting session token data from the access request; Verifying the digital signature and validity period of the session token data; When both the digital signature and the validity period verification are passed, parsing the user identity identifier from the session token data; Using the user identity identifier to query the identity authentication database to obtain the account authority level and session status value; Combining the account permission level and the session state value to generate an authentication state; Accessing an application program interface of a license management system and sending a query request including the user identification identifier; receiving a response data packet from the license management system, and parsing the license effective timestamp and authorization scope parameters in the response data packet; Generate a license status value based on a comparison result of the current system time and the license effective timestamp; The authorization scope parameter is associated with the license status value to generate a license status.

4. The method for generating a dynamic function menu according to claim 1, wherein: Generating a dynamic session context for defining function access qualifications and interface rendering policies based on the authentication status, license status, and device type information, including: Parsing the authentication status to obtain an authority level identifier and a session active flag; Extracting the authorized function list and validity period mark in the license status; Analyzing the device type information to obtain a device classification identifier and screen display parameters; Filtering the authorized function list according to the permission level identifier to generate a function access qualification set; determining a basic layout mode based on the device classification identifier, determining a responsive breakpoint based on the screen display parameters, and setting an interaction complexity level based on the session activity flag; Create a context data structure containing a function access qualification field, a layout mode field, a responsive breakpoint field, an interaction complexity field, and a timeliness control field; Writing the function access qualification set into the function access qualification field, writing the basic layout mode into the layout mode field, writing the responsive breakpoint into the responsive breakpoint field, writing the interaction complexity level into the interaction complexity field, and writing the validity period mark into the timeliness control field, to obtain a context data structure in which writing is completed; A dynamic session context is generated based on the written context data structure.

5. The method for generating a dynamic function menu according to claim 1, wherein: Load the function menu policy model that associates the function item set with the rendering policy corresponding to different permission levels, including: Access pre-stored function menu strategy model configuration files; Verifying the digital signature and version compatibility of the function menu policy model configuration file; When the verification is passed, the function menu strategy model configuration file is parsed to obtain model structure description data; Extracting function item set definitions from the model structure description data; Parsing the permission level mapping table in the model structure description data, wherein the permission level mapping table includes a permission level identifier, a corresponding function item subset identifier, and a rendering strategy identifier; Generate an association mapping between the permission level identifier, the function item subset identifier, and the rendering strategy identifier according to the permission level mapping table; Constructing a function menu strategy model instance including the function item set definition and association mapping; The function menu strategy model instance is loaded into the runtime memory.

6. The method for generating a dynamic function menu according to claim 1, wherein: Based on the dynamic session context, determining a target permission level in the function menu policy model, and matching a corresponding target function item subset and a target rendering policy according to the target permission level, including: Extracting a session validity period mark from a time control field of the dynamic session context; When the session validity period mark has not expired, obtaining a permission level identifier from the function access qualification field of the dynamic session context; searching the permission level identifier in the association map of the function menu policy model; When a matching item is found, the corresponding function item subset identifier and rendering strategy identifier are obtained from the association map; Using the function item subset identifier as a key value, locating a target function item subset in an index table defined by a function item set of the function menu policy model; Accessing a pre-stored rendering strategy library and retrieving a target rendering strategy according to the rendering strategy identifier; Create a matching result object containing the target function item subset reference and the target rendering strategy reference.

7. The method for generating a dynamic function menu according to claim 1, wherein: The target function item subset is processed by the target rendering strategy to generate a function menu instance, including: Parsing the target rendering strategy to obtain layout mode configuration, interaction strategy configuration, and visual style configuration; Configure the instantiated menu container component according to the layout mode to generate a basic menu layout framework; Inserting the function item elements of the target function item subset into the basic menu layout framework; registering an event listener in the basic menu layout framework based on the interaction strategy configuration; Configure the rendering menu visual style through the visual style described above; The basic menu layout framework, event listeners and rendered menu visual styles are serialized into an executable menu component instance.

8. A device for generating a dynamic function menu, characterized in that: The generating device of the dynamic function menu comprises: An access parsing module is used to obtain an access request sent by a user terminal that carries device type information; an authentication module, configured to, in response to the access request, parse the authentication status of the user account and obtain the license status associated with the user account; A session context generation module, configured to generate a dynamic session context for defining function access qualifications and interface rendering strategies based on the authentication status, license status, and device type information; A policy model loading module is used to load a function menu policy model of a rendering policy corresponding to a set of associated function items and different permission levels; A permission mapping module, configured to determine a target permission level in the function menu policy model based on the dynamic session context, and match a corresponding target function item subset and a target rendering policy according to the target permission level; A menu generation module, configured to process the target function item subset using the target rendering strategy to generate a function menu instance; The menu transmission module is used to send the function menu instance to the user terminal.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a dynamic function menu generation program stored in the memory and capable of running on the processor. When the dynamic function menu generation program is executed by the processor, the steps of the dynamic function menu generation method as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a program for generating a dynamic function menu. When the program for generating a dynamic function menu is executed by a processor, the steps of the method for generating a dynamic function menu according to any one of claims 1 to 7 are implemented.

Images