An application access method and device, electronic equipment and computer readable medium

Abstract

The application discloses an application access method and device, electronic equipment and a computer readable medium, and relates to the technical field of computers. The method comprises the following steps: obtaining an application identifier, a user identifier and user query data according to a received application access request; in response to the application identifier corresponding to a low-code application, determining the permission type corresponding to the application identifier; determining a target execution component and a permission interception rule according to the permission type; calling the target execution component to perform authentication and filtering on the user query data based on the permission interception rule, and obtaining authentication result data; updating the permission of a user corresponding to the user identifier, which is opened by the low-code application corresponding to the application identifier, according to the authentication result data, and jumping to an application display page corresponding to the user query data based on the permission. When the module under the low-code platform has particularly complex permission requirements or highly customized permissions, the application access efficiency is improved, and the maintenance cost of the application access platform is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to an application access method, apparatus, electronic device, and computer-readable medium. Background Technology

[0002] Currently, some modules on low-code platforms have particularly complex permission requirements or highly customized permissions. This leads to the need for low-code platforms to adapt to complex requirements. For example, some modules need data sharing requirements for a single data dimension, but the traditional RABC model does not support this. This requires upgrading the low-code platform, which is costly and cannot meet all business needs. It also results in low application access efficiency and high application access platform maintenance costs. Summary of the Invention

[0003] In view of this, embodiments of this application provide an application access method, apparatus, electronic device, and computer-readable medium, which can solve the problems of low application access efficiency and high application access platform maintenance costs when some modules in existing low-code platforms have particularly complex permission requirements or highly customized permissions.

[0004] To achieve the above objectives, according to one aspect of an embodiment of this application, an application access method is provided, comprising:

[0005] Based on the received application access request, obtain the corresponding application identifier, user identifier and user query data. In response to the application identifier corresponding to a low-code application, determine the permission type corresponding to the application identifier.

[0006] Based on the permission type, determine the target execution component and permission interception rules;

[0007] The target execution component is invoked to authenticate and filter user query data based on permission interception rules, and the authentication result data is obtained.

[0008] Based on the authentication results, update the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier, and redirect the user to the application display page corresponding to the data queried by the user based on the permissions.

[0009] Optionally, the target execution component is determined, including:

[0010] If the permission is centralized, then the target execution component is determined to be the permission executor;

[0011] If the permission is decentralized, the target execution components are determined to include the permission custom interface, the standardized interface, and the permission executor.

[0012] Optionally, the target execution component is invoked to authenticate and filter user query data based on permission interception rules, obtaining authentication result data, including:

[0013] If the permission interception rule is a decentralized permission interception rule, then determine the data source type corresponding to the user's query data;

[0014] If the data source type includes a third-party data source, then the standardized interface is called to obtain the authentication data corresponding to the user's query data from the third-party data source;

[0015] The permission executor is invoked to authenticate and filter the authentication data and user query data, and the authentication result data is obtained.

[0016] Optionally, based on permissions, the user may be redirected to the application display page corresponding to the data queried by the user, including:

[0017] Based on permissions, determine the authentication data that can be displayed in the authentication data, redirect the user, and display the displayed authentication data on the application display page corresponding to the data queried by the user.

[0018] Optionally, before receiving an application access request, the method further includes:

[0019] Based on the received permission selection request, determine the target permission selected by the user;

[0020] If the target permission is a decentralized permission, call the permission resource manager to install the pre-generated initial version permission resource package into the target low-code application and display the permission customization interface to the user;

[0021] Call the permission customization interface to obtain user-customized permission data input by the user, and then generate the corresponding user-customized permission resource package;

[0022] Update and install the custom permission resource package into the target low-code application.

[0023] Optionally, the custom permission resource package can be updated and installed into the target low-code application, including:

[0024] Update the initial version of the permission resource package based on the user-defined permission resource package, and install the updated initial version of the permission resource package into the target low-code application.

[0025] In addition, this application also provides an application access device, including:

[0026] The acquisition unit is configured to acquire the corresponding application identifier, user identifier, and user query data based on the received application access request, and determine the permission type corresponding to the application identifier in response to the application identifier corresponding to a low-code application.

[0027] The determination unit is configured to determine the target execution component and permission interception rules based on the permission type;

[0028] The authentication unit is configured to call the target execution component to authenticate and filter user query data based on permission interception rules, and obtain authentication result data.

[0029] The page display unit is configured to update the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier based on the authentication result data, and then redirect to the application display page corresponding to the user's query data based on the permissions.

[0030] Optionally, the determining unit is further configured to:

[0031] If the permission is centralized, then the target execution component is determined to be the permission executor;

[0032] If the permission is a decentralized permission, then the target execution component is configured as a permission custom interface, a standardized interface, and a permission executor.

[0033] Optionally, the authentication unit is further configured as follows:

[0034] If the permission interception rule is a decentralized permission interception rule, then determine the data source type corresponding to the user's query data;

[0035] If the data source type is configured as a third-party data source, the standardized interface is called to obtain the authentication data corresponding to the user's query data from the third-party data source.

[0036] The permission executor is invoked to authenticate and filter the authentication data and user query data, and the authentication result data is obtained.

[0037] Optionally, the page display unit is further configured as follows:

[0038] Based on permissions, determine the authentication data that can be displayed in the authentication data, redirect the user, and display the displayed authentication data on the application display page corresponding to the data queried by the user.

[0039] Optionally, the application access device also includes a permission customization unit, configured to:

[0040] Based on the received permission selection request, determine the target permission selected by the user;

[0041] If the target permission is a decentralized permission, call the permission resource manager to install the pre-generated initial version permission resource package into the target low-code application and display the permission customization interface to the user;

[0042] Call the permission customization interface to obtain user-customized permission data input by the user, and then generate the corresponding user-customized permission resource package;

[0043] Update and install the custom permission resource package into the target low-code application.

[0044] Optionally, the permission customization unit is further configured as follows:

[0045] Update the initial version of the permission resource package based on the user-defined permission resource package, and install the updated initial version of the permission resource package into the target low-code application.

[0046] In addition, this application also provides an application access electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the application access method described above.

[0047] In addition, this application also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the application access method as described above.

[0048] To achieve the above objectives, according to another aspect of the embodiments of this application, a computer program product is provided.

[0049] A computer program product according to an embodiment of this application includes a computer program that, when executed by a processor, implements the application access method provided in an embodiment of this application.

[0050] One embodiment of the above invention has the following advantages or beneficial effects: This application obtains the corresponding application identifier, user identifier, and user query data based on the received application access request; in response to the application identifier corresponding to a low-code application, it determines the permission type corresponding to the application identifier; based on the permission type, it determines the target execution component and permission interception rules; it calls the target execution component to authenticate and filter the user query data based on the permission interception rules, obtaining authentication result data; based on the authentication result data, it updates the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier, and redirects the user to the application display page corresponding to the user query data based on the permissions. Therefore, when some modules under the low-code platform have particularly complex permission requirements or highly customized permissions, it improves the access efficiency of related applications and reduces the maintenance cost of the application access platform.

[0051] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0052] The accompanying drawings are provided to better understand this application and do not constitute an undue limitation thereof. Wherein:

[0053] Figure 1 This is a schematic diagram of the main flow of an application access method according to an embodiment of this application;

[0054] Figure 2 This is a schematic diagram of the main flow of an application access method according to an embodiment of this application;

[0055] Figure 3 This is a schematic diagram of the main process of generating a permission template for an application access method according to an embodiment of this application;

[0056] Figure 4 This is a schematic diagram of the main runtime authentication process of an application access method according to an embodiment of this application;

[0057] Figure 5 This is a schematic diagram of the main flow of an application access method according to an embodiment of this application;

[0058] Figure 6 This is a schematic diagram of the main units of an application access device according to an embodiment of this application;

[0059] Figure 7 This is an exemplary system architecture diagram to which embodiments of this application can be applied;

[0060] Figure 8 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers in the embodiments of this application. Detailed Implementation

[0061] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solutions of this application comply with relevant national laws and regulations. It should also be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions. The collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solutions of this application all comply with relevant laws and regulations, are used for legal and reasonable purposes, do not violate public order and good morals, are not shared, disclosed, or sold outside of these legal uses, and are subject to supervision and management by regulatory authorities. Necessary measures should be taken to prevent unauthorized access to user personal information, safeguard user personal information security, cybersecurity, and national security, and ensure that those authorized to access personal information comply with relevant laws and regulations. Once this user personal information is no longer needed, risks should be minimized by restricting or even prohibiting data collection and / or deleting the data.

[0062] When used, including in certain relevant applications, data is deidentified to protect user privacy, for example by removing specific identifiers, controlling the amount or specificity of stored data, controlling how data is stored, and / or other methods.

[0063] Figure 1 This is a schematic diagram of the main flow of an application access method according to an embodiment of this application, as shown below. Figure 1 As shown, the application access method mainly includes the following steps S101-S104.

[0064] Step S101: Obtain the corresponding application identifier, user identifier, and user query data based on the received application access request. In response to the application identifier corresponding to a low-code application, determine the permission type corresponding to the application identifier.

[0065] In this embodiment, the execution entity of the application access method (e.g., a server) can receive application access requests via wired or wireless connections. The application corresponding to the application access request can be a low-code application, i.e., an application that requires no coding (0 code) or is generated with minimal code, such as creating web pages and mobile applications using a graphical user interface, drag-and-drop components, and model-driven logic. When the execution entity receives an application access request, it can obtain the application identifier carried in the request, which is used to characterize the type of application. The type of application can include a low-code application. The execution entity can obtain the application identifier, user identifier, and user query data corresponding to the application access request. The user identifier can be the ID or name of the user who issued the application access request. The user query data includes, for example, querying role data, querying profit data, and other data related to the low-code application. If the application identifier corresponds to a low-code application, the permission type corresponding to that application identifier is determined. For example, the permission type can include centralized permissions and decentralized permissions. Centralized permissions can be general permissions configured in the permission center under a low-code or PaaS platform. Decentralized permissions can be local permissions, which are user-defined permissions. PaaS is an abbreviation for Platform as a Service, which refers to a platform as a service.

[0066] Step S102: Determine the target execution component and permission interception rules based on the permission type.

[0067] Specifically, the target execution component is determined as follows: if the permission is a centralized permission, the target execution component is determined to be a permission executor; if the permission is a decentralized permission, the target execution component includes a permission custom interface, a standardized interface, and a permission executor.

[0068] If the permission is centralized, the target execution component is determined to be the permission executor; if the permission is decentralized, the target execution component is determined to be the permission rule function executor, which includes a custom permission interface, a standardized interface, and the permission executor. The permission rule function executor can orchestrate user-defined resource and model data extension functions, providing a unified authentication service. Furthermore, the determined target execution component can accurately identify the corresponding permission interception rules to quickly filter application access requests that do not conform to the rules.

[0069] Step S103: Invoke the target execution component to authenticate and filter the user query data based on the permission interception rules, and obtain the authentication result data.

[0070] Specifically, the target execution component is invoked to authenticate and filter user query data based on permission interception rules, obtaining authentication result data. This includes: if the permission interception rule is a decentralized permission interception rule, determining the data source type corresponding to the user query data; if the data source type includes a third-party data source, calling a standardized interface to obtain authentication data corresponding to the user query data from the third-party data source; and invoking the permission executor to authenticate and filter the authentication data and user query data, obtaining authentication result data.

[0071] If the permission interception rule is a decentralized permission interception rule, then the data source type corresponding to the user's query data is determined. Data source types include local data sources and third-party data sources, where third-party data sources can be data sources from partner institutions. If the data source type includes third-party data sources, a standardized interface is called. This standardized interface connects to various third-party data sources to obtain authentication data (e.g., role data or profit data) corresponding to the user's query data (e.g., role fields or profit fields). The permission executor is then called to authenticate and filter the authentication data and the user's query data, obtaining the authentication result data. The authentication result data can be used to characterize the user's permissions to view or manipulate data in the low-code application.

[0072] Step S104: Based on the authentication result data, update the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier, and redirect to the application display page corresponding to the user's query data based on the permissions.

[0073] Based on the authentication results, which indicate the user's permissions to view or manipulate data in low-code applications, the system updates the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier. Based on these permissions, the user is redirected to the application display page corresponding to the data they queried. This improves the access efficiency of related applications and reduces the maintenance costs of the application access platform.

[0074] Specifically, redirecting to the application display page corresponding to the user's query data based on permissions includes: determining the displayable authentication data in the authentication data based on permissions, redirecting, and displaying the displayable authentication data on the application display page corresponding to the user's query data.

[0075] Based on user permissions, the system determines which authentication data (e.g., profit data) can be displayed. The user is then redirected to the application's display page corresponding to their query data. This ensures accurate and rapid presentation of application access results.

[0076] This embodiment obtains the corresponding application identifier, user identifier, and user query data based on the received application access request. Responding to the application identifier corresponding to a low-code application, it determines the permission type corresponding to the application identifier. Based on the permission type, it determines the target execution component and permission interception rules. The target execution component is invoked to authenticate and filter the user query data based on the permission interception rules, obtaining authentication result data. Based on the authentication result data, the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier are updated, and the user is redirected to the application display page corresponding to the user query data based on the permissions. This improves the access efficiency of related applications and reduces the maintenance cost of the application access platform when some modules in the low-code platform have particularly complex permission requirements or highly customized permissions.

[0077] Figure 2 This is a schematic diagram of the main flow of an application access method according to an embodiment of this application, such as... Figure 2 As shown, the application access method mainly includes the following steps S201-S208.

[0078] Step S201: Determine the target permissions selected by the user based on the received permission selection request.

[0079] When a user configures custom permissions, the executing entity receives a permission selection request from the user, which carries the target permission data selected by the user. The target permission selected by the user is determined based on the target permission data carried in the permission selection request. For example, the target permission can be a decentralized permission, i.e., a local permission, which is a user-defined permission.

[0080] Step S202: If the target permission is a decentralized permission, call the permission resource manager to install the pre-generated initial version permission resource package into the target low-code application and display the permission customization interface to the user.

[0081] For example, the pre-generated initial version permission resource package can be derived from existing user, role, resource, model permission, organizational structure, and other services and page resources by packaging them into version V1.0. When the target permission is a decentralized permission, it indicates that the user needs to configure custom permissions. In this case, the executing entity can install version V1.0 (i.e., the initial version permission resource package) into the target low-code application and display a permission customization interface to the user, allowing the user to customize and extend permissions based on version V1.0, thereby reducing the application access platform maintenance costs.

[0082] Step S203: Call the permission customization interface to obtain user-customized permission data input by the user, and then generate the corresponding user-customized permission resource package.

[0083] Users can input user-defined permission data through the permission customization interface. The executing entity obtains the user-defined permission data input by the user through the permission customization interface and generates a corresponding user-defined permission resource package based on the user-defined permission data. This user-defined permission resource package can be the resource package corresponding to the added permission.

[0084] Step S204: Update and install the custom permission resource package into the target low-code application.

[0085] Specifically, updating and installing a custom permission resource package into the target low-code application includes: updating the initial version of the permission resource package based on the user-defined permission resource package, and installing the updated initial version of the permission resource package into the target low-code application.

[0086] For example, the executing entity can place the custom permission resource package at an appropriate position within the initial version permission resource package, such as appending it after or before the initial version permission resource package, to obtain the updated initial version permission resource package. The updated initial version permission resource package is then installed into the target low-code application to complete the custom permission configuration. This reduces the application's access platform maintenance costs when some modules on the low-code platform have particularly complex permission requirements or highly customized permissions.

[0087] Step S205: Obtain the corresponding application identifier, user identifier, and user query data based on the received application access request; in response to the application identifier corresponding to a low-code application, determine the permission type corresponding to the application identifier.

[0088] An application identifier is used to characterize the type of application. Application types can include low-code applications. The executing entity can obtain the application identifier, user identifier, and user query data corresponding to the application access request. The user identifier can be the ID or name of the user issuing the application access request. User query data includes, for example, querying inventory data or logistics data, which involves data from low-code applications. If the application identifier corresponds to a low-code application, the corresponding permission type is determined. For example, permission types can include centralized permissions and decentralized permissions. Centralized permissions can be common permissions configured in the permission center of a low-code or PaaS platform. Decentralized permissions can be local permissions, which are user-defined permissions. PaaS is an abbreviation for Platform as a Service.

[0089] Step S206: Determine the target execution component and permission interception rules based on the permission type.

[0090] If the permission is centralized, the target execution component is determined to be the permission executor; if the permission is decentralized, the target execution component is determined to be the permission rule function executor, which includes a custom permission interface, a standardized interface, and the permission executor. The permission rule function executor can orchestrate user-defined resource and model data extension functions, providing a unified authentication service. Furthermore, the determined target execution component can accurately identify the corresponding permission interception rules to quickly filter application access requests that do not conform to the rules.

[0091] Step S207: Invoke the target execution component to authenticate and filter the user query data based on the permission interception rules, and obtain the authentication result data.

[0092] If the permission interception rule is a decentralized permission interception rule, then the data source type corresponding to the user's query data is determined. Data source types include local data sources and third-party data sources, where third-party data sources can be data sources from partner institutions. If the data source type includes third-party data sources, a standardized interface is called. This standardized interface connects to various third-party data sources to obtain authentication data (e.g., inventory data or logistics data) corresponding to the user's query data (e.g., inventory fields or logistics fields). The permission executor is then called to authenticate and filter the authentication data and the user's query data, obtaining the authentication result data. The authentication result data can be used to characterize the user's permissions to view or manipulate data in the low-code application.

[0093] Step S208: Based on the authentication result data, update the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier, and redirect to the application display page corresponding to the user's query data based on the permissions.

[0094] Based on user permissions, the system determines which authorized data (e.g., inventory or logistics data) can be displayed. The user is then redirected to the application's display page corresponding to their query data. This ensures accurate and rapid presentation of application access results.

[0095] The following are explanations of terms that may be used in this application's embodiments: Low-code platform: A low-code development platform (LCDP) is a development platform that allows applications to be generated quickly with no coding (0 code) or with minimal coding. It uses a visual approach to application development (refer to visual programming languages), enabling developers with varying levels of experience to create web pages and mobile applications through a graphical user interface, using drag-and-drop components and model-driven logic. Permissions: Permissions refer to the specific system resource usage rights a particular user has, such as restrictions on the use or storage of folders, specific system commands, etc. RABC: Various permissions for system operations are not directly granted to specific users, but rather a set of roles is established between a set of users and a set of permissions. Each role corresponds to a set of permissions. Once a user is assigned an appropriate role, that user has all the operational permissions for that role.

[0096] Users can use the general RABC authentication system, or they can customize their own permission modules to create personalized permission systems based on their specific business needs.

[0097] Figure 3 This is a schematic diagram of the main process of generating a permission template for an application access method according to an embodiment of this application; as shown below. Figure 3 As shown, permission template generation: The executing entity can use the derivation engine executor to package the original user, role, resource, model permission, organization and other services and page resources into version V1.0 based on low-code centralized permissions, and publish the derived version V1.0 (i.e. permission template) to the permission resource manager.

[0098] When a user selects permissions, the executing entity can call the permission generator to generate a default interceptor and install it into the application. It then determines whether the user selected a centralized permission. If the user selected a centralized permission, the permission customization process ends. If the user selected a decentralized permission, the executing entity can call the permission resource manager to install the version V1.0 permission resource (i.e., permission template) into the low-code application by default for user-defined permissions. Subsequent users can also use the permissions defined by the previous user or create new permissions, ending the permission customization process. This improves the access efficiency of applications and reduces the maintenance costs of the application access platform when some modules on the low-code platform have particularly complex permission requirements or highly customized permissions.

[0099] Figure 4This is a schematic diagram of the main runtime authentication process of an application access method according to an embodiment of this application; runtime authentication: when a user accesses a low-code generated application (i.e., a low-code application), the executing entity can call the permission adapter to select permission interception rules based on the permission type of the low-code application; if the permission type of the low-code application is centralized permission, the permission interceptor can be called to directly call the permission executor through a remote network call to authenticate and filter data and resources; if the permission of the low-code application is user-defined permission, the permission interceptor can be called to authenticate and filter data through the permission rule function executor + built-in standardized interface + permission executor, for example, such as Figure 5 The diagram illustrates the specific rules of the built-in rule function executor: When the executing entity receives a user's application access request for a low-code application (e.g., a data query for the low-code application), it can invoke the permission interceptor to perform interception and verification based on model permission rules and resource permission rules. Specifically, interception and verification based on model permission rules can include interception and verification based on user-defined functions (if any), or interception and verification based on default functions when no user-defined functions exist. Verification based on resource permission rules can include determining the user role at the permission API (interface) layer based on the user identifier in the request, performing permission verification based on the user role, and finally obtaining permission verification result data. The permission verification result data can include allowing the application access request if the permission verification passes, or it can include blocking the application access request if the permission verification fails. When the permission verification passes, the executing entity can obtain the relevant third-party information based on the allowed application access request, and call the standardized interface layer to obtain accurate relevant third-party data based on the relevant third-party information (e.g., third-party name, third-party fields, third-party data storage address, etc.). Combining the obtained relevant third-party data, it provides the result data required by the application access request (e.g., page display data, analysis table data, or analysis chart data, etc.). This improves the access efficiency of related applications and reduces the maintenance cost of application access platforms when some modules on low-code platforms have particularly complex permission requirements or highly customized permissions.

[0100] In this embodiment, the derivative engine executor packages each version of permission resources and services; the permission resource manager manages and installs permission resources; the permission executor executes different permission engines (centralized permissions, local permissions, and local permissions are decentralized permissions) according to the user's selection; the built-in permission rule function executor orchestrates user-defined resource and model data extension functions to provide unified authentication services; and the permission adapter adapts permissions and handles rules for low-code applications.

[0101] Figure 6This is a schematic diagram of the main units of an application access device according to an embodiment of this application. Figure 6 As shown, the application access device 600 includes an acquisition unit 601, a determination unit 602, an authentication unit 603, and a page display unit 604.

[0102] The acquisition unit 601 is configured to acquire the corresponding application identifier, user identifier and user query data based on the received application access request, and determine the permission type corresponding to the application identifier in response to the application identifier corresponding to a low-code application.

[0103] Unit 602 is configured to determine the target execution component and permission interception rules based on the permission type.

[0104] The authentication unit 603 is configured to call the target execution component to authenticate and filter user query data based on permission interception rules, and obtain authentication result data.

[0105] Page display unit 604 is configured to update the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier based on the authentication result data, and then redirect to the application display page corresponding to the user's query data based on the permissions.

[0106] In some embodiments, the determining unit 602 is further configured to: if the permission is a centralized permission, determine the target execution component as a permission executor; if the permission is a decentralized permission, determine the target execution component as a permission custom interface, a standardized interface, and a permission executor.

[0107] In some embodiments, the authentication unit 603 is further configured to: if the permission interception rule is a decentralized permission interception rule, determine the data source type corresponding to the user query data; if the data source type is configured as a third-party data source, call a standardized interface to obtain authentication data corresponding to the user query data from the third-party data source; and call the permission executor to authenticate and filter the authentication data and the user query data to obtain authentication result data.

[0108] In some embodiments, the page display unit 604 is further configured to: determine the displayable authentication data in the authentication data based on permissions, jump to and display the displayable authentication data on the application display page corresponding to the user query data.

[0109] In some embodiments, the application access device also includes Figure 6The permission customization unit (not shown) is configured to: determine the target permission selected by the user based on the received permission selection request; if the target permission is a decentralized permission, call the permission resource manager to install the pre-generated initial version permission resource package into the target low-code application and display the permission customization interface to the user; call the permission customization interface to obtain the user-inputted user-defined permission data, and then generate the corresponding user-defined permission resource package; and update and install the custom permission resource package into the target low-code application.

[0110] In some embodiments, the permission customization unit is further configured to: update the initial version permission resource package based on the user-defined permission resource package, and install the updated initial version permission resource package into the target low-code application.

[0111] It should be noted that the application access method and application access device in this application are related in terms of specific implementation content, so repeated content will not be described again.

[0112] Figure 7 An exemplary system architecture 700 is shown that can be applied to the application access method or application access device according to the embodiments of this application.

[0113] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing communication links between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0114] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0115] Terminal devices 701, 702, and 703 can be various electronic devices with application access processing screens and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0116] Server 705 can be a server providing various services, such as a backend management server supporting application access requests submitted by users using terminal devices 701, 702, and 703 (this is just an example). The backend management server can obtain the corresponding application identifier, user identifier, and user query data based on the received application access request. Responding to the application identifier corresponding to a low-code application, it determines the permission type corresponding to the application identifier; based on the permission type, it determines the target execution component and permission interception rules; it calls the target execution component to authenticate and filter the user query data based on the permission interception rules, obtaining authentication result data; based on the authentication result data, it updates the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier, and redirects the user to the application display page corresponding to the user query data based on the permissions. This improves the access efficiency of related applications and reduces the maintenance cost of the application access platform when some modules in the low-code platform have particularly complex permission requirements or highly customized permissions.

[0117] It should be noted that the application access method provided in this application embodiment is generally executed by server 705, and correspondingly, the application access device is generally set in server 705.

[0118] It should be understood that Figure 7 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0119] The following is for reference. Figure 8 It shows a schematic diagram of the structure of a computer system 800 suitable for implementing a terminal device according to the embodiments of this application. Figure 8 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0120] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the computer system 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0121] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0122] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs the functions defined above in the system of this application.

[0123] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The units described in the embodiments of this application can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor can be described as including an acquisition unit, a determination unit, an authentication unit, and a page display unit. The names of these units do not necessarily limit the specific unit itself.

[0126] In another aspect, this application also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs. When the one or more programs are executed by the device, the device obtains the corresponding application identifier, user identifier, and user query data based on the received application access request. In response to the application identifier corresponding to a low-code application, the device determines the permission type corresponding to the application identifier; based on the permission type, it determines the target execution component and permission interception rules; it calls the target execution component to authenticate and filter the user query data based on the permission interception rules, obtaining authentication result data; based on the authentication result data, it updates the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier, and redirects to the application display page corresponding to the user query data based on the permissions.

[0127] The computer program product of this application includes a computer program that, when executed by a processor, implements the application access method in the embodiments of this application.

[0128] According to the technical solution of the embodiments of this application, when some modules in a low-code platform have particularly complex permission requirements or highly customized permissions, the access efficiency of related applications can be improved and the maintenance cost of application access platform can be reduced.

[0129] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An application access method, characterized in that, include: Based on the received application access request, obtain the corresponding application identifier, user identifier and user query data, and in response to the application identifier corresponding to a low-code application, determine the permission type corresponding to the application identifier. Based on the permission type, determine the target execution component and permission interception rules; The target execution component is invoked to authenticate and filter the user query data based on the permission interception rules, and authentication result data is obtained. Based on the authentication result data, update the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier, and based on the permissions, redirect to the application display page corresponding to the user query data.

2. The method according to claim 1, characterized in that, The target execution component includes: If the permission is a centralized permission, then the target execution component is determined to be the permission executor; If the permission is a decentralized permission, then the target execution component is determined to include a permission custom interface, a standardized interface, and a permission executor.

3. The method according to claim 2, characterized in that, The invocation of the target execution component to authenticate and filter the user query data based on the permission interception rules, and to obtain authentication result data, includes: If the permission interception rule is a decentralized permission interception rule, then determine the data source type corresponding to the user query data; If the data source type includes a third-party data source, then a standardized interface is invoked to obtain authentication data corresponding to the user query data from the third-party data source; The permission executor is invoked to authenticate and filter the authentication data and the user query data, thereby obtaining authentication result data.

4. The method according to claim 3, characterized in that, The step of redirecting to the application display page corresponding to the user's query data based on the permission includes: Based on the permissions, determine the displayable authentication data in the authentication data, redirect to and display the displayable authentication data on the application display page corresponding to the user query data.

5. The method according to claim 1, characterized in that, Before receiving the application access request, the method further includes: Based on the received permission selection request, determine the target permission selected by the user; If the target permission is a decentralized permission, invoke the permission resource manager to install the pre-generated initial version permission resource package into the target low-code application, and display the permission customization interface to the user; Call the permission customization interface to obtain user-customized permission data input by the user, and then generate the corresponding user-customized permission resource package; The custom permission resource package is updated and installed into the target low-code application.

6. The method according to claim 5, characterized in that, The step of updating and installing the custom permission resource package into the target low-code application includes: The initial version of the permission resource package is updated based on the user-defined permission resource package, and the updated initial version of the permission resource package is installed into the target low-code application.

7. An application access device, characterized in that, include: The acquisition unit is configured to acquire the corresponding application identifier, user identifier, and user query data based on the received application access request, and in response to the application identifier corresponding to a low-code application, determine the permission type corresponding to the application identifier. The determining unit is configured to determine the target execution component and permission interception rules based on the permission type. The authentication unit is configured to invoke the target execution component to authenticate and filter the user query data based on the permission interception rules, and obtain authentication result data. The page display unit is configured to update the permissions granted by the low-code application corresponding to the application identifier to the user corresponding to the user identifier based on the authentication result data, and then redirect to the application display page corresponding to the user query data based on the permissions.

8. An application for accessing an electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images