Access control method and device of equipment digital platform, electronic equipment and platform

Abstract

The invention discloses an access control method and device of an equipment digital platform, electronic equipment and the platform, and belongs to the field of computers. The method comprises the steps that after a front end obtains authorization equipment information and authorization menu item information, a routing table is constructed based on the authorization menu item information, then a navigation menu is generated based on the authorization menu item information and the authorization equipment information, and when a user wants to access a page on the navigation menu, the front end judges whether to respond to a jump request or not according to the generated routing table. According to the method, the personalized navigation menu can be automatically generated for the user, and whether jumping is allowed or not can be judged based on the route. In this way, the user can only access the equipment with the routing authority, and personalized access authority control is achieved while the user requirement is met.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to an access control method, apparatus, electronic device, and platform for a device digitization platform. Background Technology

[0002] With the development of industrial automation and intelligent manufacturing, industrial robots, as key equipment, play a vital role in improving production efficiency, ensuring product quality, and reducing labor costs. To further enhance the efficiency and reliability of industrial robots, digital platforms are becoming increasingly widespread for monitoring, configuring, and managing these devices. However, achieving efficient access control on these platforms has become a critical challenge. Especially in complex and ever-changing industrial environments, different users need to access diverse functional modules and data, requiring precise control of these permissions to ensure system security and operational accuracy.

[0003] Existing navigation menu configuration methods configure target navigation menus through user configuration information to achieve personalized customization of navigation menus. Although this method achieves customized navigation menus, it does not control routing. Even if users cannot see certain menu items, if the system does not control routing permissions, users can still access pages not displayed in the menu by directly entering the page route. This allows unauthorized users to directly access restricted resources through page routes, posing a security risk.

[0004] Existing permission verification methods determine the target access permissions of the target interface indicated by the interface request based on a preset association between interfaces and their access permissions. However, interfaces and routes are concepts of different dimensions; routes correspond to pages, while interfaces correspond to data. Therefore, controlling interfaces cannot achieve the control of pages. Disabling all interfaces of a page might seem to disable that page, but interfaces are shared resources, not exclusive to any particular page. Disabling an interface would prevent all pages from using that interface and accessing the corresponding data, which is clearly not a good design.

[0005] Existing methods for differentiated webpage display also lack routing control and rely on user roles for system differentiation, which is inflexible in complex industrial application scenarios. Specifically, certain operations or data access requirements may necessitate more granular access control, going beyond user roles to consider individual user attributes such as skill level and work experience, in order to assign different device access permissions to different users. Therefore, existing solutions struggle to meet the demands for granular, individual-level access control.

[0006] In summary, while the current technical solution has achieved personalized configuration of functional modules and differentiation of content display to a certain extent, it still lacks flexibility in routing control and permission management, and needs further optimization and improvement. Summary of the Invention

[0007] To overcome the shortcomings of the prior art, this application provides an access control method, apparatus, electronic device, and platform for a device digitization platform, in order to address the problem that while the access schemes of existing device digitization platforms have achieved personalized configuration of functional modules and differentiated content display to a certain extent, they are still lacking in the flexibility of routing control and permission management, and need to be further optimized and improved.

[0008] The technical solution adopted by this application to solve its technical problem is:

[0009] Firstly, an access control method for a device digitization platform is provided, applied to the front end, the method comprising:

[0010] After obtaining authorized device information and authorized menu item information, a routing table is constructed based on the authorized menu item information, and a navigation menu is generated based on the authorized menu item information and the authorized device information;

[0011] In response to a user-initiated redirection request, determine whether to respond to the redirection request based on the routing table;

[0012] If the redirection request is not responded to, the route will be redirected to a preset page.

[0013] As an optional implementation of this application, the step of constructing a routing table based on the authorized menu item information includes:

[0014] The authorized menu item information is traversed to extract the routing information from the authorized menu item information;

[0015] Build a route whitelist based on the routing information and create a routing table.

[0016] As an optional implementation of this application, the step of generating a navigation menu based on the authorized menu item information and the authorized device information includes:

[0017] Generate a common first-level menu in the navigation menu based on the authorized menu item information;

[0018] Under the online device option in the primary menu, a secondary menu is generated based on the authorized device information, wherein each secondary menu includes devices that the user can access;

[0019] Generate a standard third-level menu for each device in the second-level menu.

[0020] As an optional implementation of this application, the step of responding to a user-initiated redirection request by determining whether to respond to the redirection request based on the routing table includes:

[0021] In response to a user's page navigation request initiated by the navigation menu, determine whether the route to the target page exists in the routing table;

[0022] If the route to the target page does not exist in the routing table, the route will be redirected to a preset page;

[0023] If the route to the target page exists in the routing table, respond to the page redirection request and redirect to the target page corresponding to the page redirection request.

[0024] As an optional implementation of this application, the step of responding to a user-initiated redirection request by determining whether to respond to the redirection request based on the routing table includes:

[0025] The complete route is obtained by adding the identification parameter to the route in the routing table, and the identification parameter is unique for each device.

[0026] In response to a user's device access request initiated on the target page, obtain the identification parameters from the complete route of the target device;

[0027] If the identifier parameter in the complete route to the target device is not found in the authorized device information, the route will be redirected to a preset page;

[0028] If the authorized device information contains an identifier parameter in the complete route of the target device, the device access request will be responded to, and the user will be redirected to the target device's page.

[0029] As an optional implementation of this application, it also includes:

[0030] In response to the user's username and password input, the username and password are sent to the backend for verification;

[0031] After the backend verification is successful, the system receives authentication data sent by the backend, which includes user ID and role ID.

[0032] The user ID is used to call the interface to send an authorization device information retrieval request to the backend, and the role ID is used to call the interface to send an authorization menu item information request to the backend.

[0033] Receive authorized device information and authorized menu item information sent by the backend.

[0034] Secondly, an access control device for a device digitization platform is provided, applied to the front end, the device comprising:

[0035] The navigation menu generation module is used to construct a routing table based on the authorized menu item information and generate a navigation menu based on the authorized menu item information and the authorized device information after obtaining authorized device information and authorized device information;

[0036] The redirection request determination module is used to respond to a user-initiated redirection request and determine whether to respond to the redirection request based on the routing table.

[0037] The preset page redirection module is used to redirect the route to a preset page when the redirection request is not responded to.

[0038] Thirdly, an electronic device is provided, comprising:

[0039] At least one processor and at least one memory;

[0040] The memory stores the executable instructions of the processor;

[0041] The processor is configured to perform any of the methods described above.

[0042] Fourthly, a device digitization platform is provided, comprising: a front-end and a back-end;

[0043] The front-end application uses any of the methods described above;

[0044] The backend is used to verify the account and password sent by the frontend, and to send authorized device information to the frontend when it receives an authorization device information request from the frontend, and to send authorized device information to the frontend when it receives an authorization menu item information request from the frontend.

[0045] As an optional implementation of this application, the backend is further used for:

[0046] The system receives user information and device information sent by the front end. The user information includes at least one of the following dimensions: a region dimension representing the user's work area, a function dimension representing the user's job, and a department dimension representing the user's department. The device information includes at least one of the following: device location, device model, and department.

[0047] Based on the user information and the device information, authorized device information is generated for the user, wherein the region dimension of the authorized device information matches the device location, and / or the function dimension matches the device model, and / or the department dimension matches the user's department.

[0048] Beneficial effects:

[0049] This application provides an access control method, device, electronic device, and platform for a device digitization platform. After obtaining authorized device information and authorized menu item information, the front end constructs a routing table based on the authorized menu item information. Then, it generates a navigation menu based on the authorized menu item information and authorized device information. When a user wants to access a page on the navigation menu, the front end determines whether to respond to the redirection request based on the generated routing table. This application can not only automatically generate personalized navigation menus for users but also determine whether redirection is allowed based on the routing. In this way, users can only access devices with routing permissions, satisfying user needs while achieving personalized access control. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a flowchart of an access control method for a device digitization platform provided in an embodiment of this application;

[0052] Figure 2 This is a schematic diagram of a navigation menu provided in an embodiment of this application;

[0053] Figure 3 This is a schematic diagram of the access control device structure of a device digitization platform provided in an embodiment of this application;

[0054] Figure 4 This is a schematic diagram of an electronic device structure provided in an embodiment of this application;

[0055] Figure 5 This is a flowchart of access control for an industrial robot digital platform provided in an embodiment of this application;

[0056] Figure 6 This is a database entity relationship diagram provided in an embodiment of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] In traditional web systems, permissions include menu permissions, component permissions, and API permissions. Menu permissions determine which pages a user can view, component permissions determine which elements (such as buttons) are displayed on a page, and API permissions are usually bound to components, becoming part of the component, and determining which data a user can access or which operations they can perform. These permissions are usually bound to roles, with user permissions determined by assigning roles to users. However, these three types of permissions cannot control device access. Menu permissions determine which pages a user can access; however, different devices essentially use the same page, only loading data for different devices through different query parameters in the page routing. While API permissions can control data access, they suffer from the same problem as menu permissions: the same API is used to retrieve data for different devices, only using different parameters carried in the HTTP request. Therefore, menu permissions and API permissions cannot effectively control device access, and component permissions only control whether certain elements on a page are displayed, offering no real control over devices.

[0059] Currently, the robot IoT platforms of the four major robot manufacturers do not seem to have effective device control. The common approach is to network the robots and then view all online robots within that network segment. Sensitive operations on certain devices (such as robot data backup and restore) are then subject to approval to achieve security. While this method does provide some security, it lacks flexibility. Adding device permissions to this solution, directly controlling access to sensitive devices and prohibiting general users from accessing them, would significantly improve robot security and the flexibility of access control.

[0060] In summary, in addition to the three types of permissions mentioned above, device permissions should also be introduced in industrial internet platforms to determine which devices a user can access or control. Furthermore, device permissions should be decoupled from roles and directly associated with users, allowing for more precise and flexible control over the devices a user can access. Traditional web systems, which do not involve physical devices, primarily focus on controlling the functions a user can use. However, by introducing device permissions, it's possible to determine which devices a user is authorized to use functions on. Since device permission allocation is independent of roles and falls under personal permissions, the combination of device permissions and role permissions (menus, components, interfaces) can achieve highly flexible and granular permission control.

[0061] Reference Figure 1 This application provides an access control method for a device digitization platform, applied to the front end, the method comprising:

[0062] S11: After obtaining the authorized device information and authorized menu item information, construct a routing table based on the authorized menu item information and generate a navigation menu based on the authorized menu item information and the authorized device information.

[0063] The authorized device information and authorized menu item information are obtained in the following ways:

[0064] In response to the user's username and password input, the username and password are sent to the backend for verification. (That is, the user enters their username and password on the frontend, where the username can be a username, ID number, or other information.) After being sent to the backend, the backend verifies the username and password by calling the entity relationship table or relationship table stored in the database. If the verification is successful, authentication data containing the user ID and role ID will be sent to the frontend.

[0065] After the backend verification is successful, the system receives authentication data sent by the backend, which includes user ID and role ID.

[0066] The system calls an API based on the user ID to send an authorization device information retrieval request to the backend, and also calls an API based on the role ID to send an authorization menu item information request to the backend; wherein, the user ID determines the devices that the user can access, and the role ID determines the menus that the user can access.

[0067] Receive authorized device information and authorized menu item information sent by the backend.

[0068] As a preferred implementation of this application, the step of generating a navigation menu based on the authorized menu item information and the authorized device information includes:

[0069] A common first-level menu is generated based on the authorized menu item information in the navigation menu; that is, the first-level menu is the same for all users in this application, as shown in the reference. Figure 2 The primary menu includes multiple options such as Home, System Management, Factory Flow, and Online Equipment.

[0070] Under the "Online Devices" option in the primary menu, a secondary menu is generated based on the authorized device information. Each secondary menu includes devices accessible to the user. Secondary menus under other options besides "Online Devices" are generated based on authorized menu item information, specifically set according to actual needs. This application does not limit the content generation of secondary menus under other options. Since the authorized device information includes devices accessible to the user, secondary menus are generated based on this information. For example, Device 1 and Device 2 are named "Device + Device Number". Thus, the devices displayed in the secondary menus are those for which the user has access rights. Devices without access rights are not displayed, preventing the leakage of gas equipment information.

[0071] A standard third-level menu is generated for each device in the second-level menu. In this application, the third-level menu is also generic. For example, they are: Device Details, Parameter Adjustment, and Waveform Acquisition. However, not every user can use all device functions; the number of functions is determined by the user's role (authorized menu items). Users with the lowest privileges can only use the Device Details function.

[0072] In addition, to prevent interference between menu groups (three-level menus), a deep copy (i.e., creating a new set of data instead of referencing the original data) should be used to create a new menu group and assign it to the new device.

[0073] Furthermore, the construction of the routing table based on the authorized menu item information includes:

[0074] The authorized menu item information is traversed to extract the routing information from the authorized menu item information;

[0075] Build a route whitelist based on the routing information and create a routing table.

[0076] S12: In response to a user-initiated redirection request, determine whether to respond to the redirection request based on the routing table.

[0077] For example, in response to a user's page jump request initiated by the navigation menu, it is determined whether the route to the target page exists in the routing table; if the route to the target page does not exist in the routing table, the route is redirected to a preset page; if the route to the target page exists in the routing table, in response to the page jump request, the user is redirected to the target page corresponding to the page jump request.

[0078] Furthermore, the routes in the routing table are added with an identifier parameter to obtain a complete route, and the identifier parameter is unique for each device; in response to a device access request initiated by a user on the target page, the identifier parameter in the complete route of the target device is obtained; if the identifier parameter in the complete route of the target device does not exist in the authorized device information, the route is redirected to a preset page; if the identifier parameter in the complete route of the target device exists in the authorized device information, the device access request is responded to and the user is redirected to the page of the target device.

[0079] This application uses routing to restrict user access permissions. Compared to regular interface or menu permissions, routing allows access to the same page, but prevents access to devices on that page for which the user lacks routing permissions. Interface or menu permissions, on the other hand, prevent access to the entire page. However, in practical applications, it's often necessary for users to access a specific menu item, but only a single device within that menu. Menu and interface permissions cannot achieve this functionality.

[0080] S13: If the redirection request is not responded to, the route is redirected to a preset page. The preset page is used to inform the user that they do not have access rights, such as a 404 page.

[0081] The access control method for a digital platform provided in this application is applied to the front end. After obtaining authorized device information and authorized menu item information, the front end constructs a routing table based on the authorized menu item information, and then generates a navigation menu based on the authorized menu item information and authorized device information. When a user wants to access a page on the navigation menu, the front end determines whether to respond to the redirection request based on the generated routing table. This application can not only automatically generate personalized navigation menus for users, but also determine whether redirection is allowed based on routing. In this way, users can only access devices with routing permissions, satisfying user needs while achieving personalized access control.

[0082] Based on the same inventive concept, such as Figure 3 As shown, this application also provides an access control device 30 for a device digitization platform, applied at the front end, the access control device 30 comprising:

[0083] The navigation menu generation module 31 is used to construct a routing table based on the authorized menu item information and generate a navigation menu based on the authorized menu item information and the authorized device information after obtaining authorized device information and authorized menu item information.

[0084] The authorized device information and authorized menu item information are obtained in the following ways:

[0085] In response to the user's username and password input, the username and password are sent to the backend for verification. (That is, the user enters their username and password on the frontend, where the username can be a username, ID number, or other information.) After being sent to the backend, the backend verifies the username and password by calling the entity relationship table or relationship table stored in the database. If the verification is successful, authentication data containing the user ID and role ID will be sent to the frontend.

[0086] After the backend verification is successful, the system receives authentication data sent by the backend, which includes user ID and role ID.

[0087] The system calls an API based on the user ID to send an authorization device information retrieval request to the backend, and also calls an API based on the role ID to send an authorization menu item information request to the backend; wherein, the user ID determines the devices that the user can access, and the role ID determines the menus that the user can access.

[0088] Receive authorized device information and authorized menu item information sent by the backend.

[0089] As a preferred implementation of this application, the step of generating a navigation menu based on the authorized menu item information and the authorized device information includes:

[0090] A common first-level menu is generated based on the authorized menu item information in the navigation menu; that is, the first-level menu is the same for all users in this application, as shown in the reference. Figure 2 The primary menu includes multiple options such as Home, System Management, Factory Flow, and Online Equipment.

[0091] Under the "Online Devices" option in the primary menu, a secondary menu is generated based on the authorized device information. Each secondary menu includes devices accessible to the user. Secondary menus under other options besides "Online Devices" are generated based on authorized menu item information, specifically set according to actual needs. This application does not limit the content generation of secondary menus under other options. Since the authorized device information includes devices accessible to the user, secondary menus are generated based on this information. For example, Device 1 and Device 2 are named "Device + Device Number". Thus, the devices displayed in the secondary menus are those for which the user has access rights. Devices without access rights are not displayed, preventing the leakage of gas equipment information.

[0092] A standard third-level menu is generated for each device in the second-level menu. In this application, the third-level menu is also generic. For example, they are: Device Details, Parameter Adjustment, and Waveform Acquisition. However, not every user can use all device functions; the number of functions is determined by the user's role (authorized menu items). Users with the lowest privileges can only use the Device Details function.

[0093] In addition, to prevent interference between menu groups (three-level menus), a deep copy (i.e., creating a new set of data instead of referencing the original data) should be used to create a new menu group and assign it to the new device.

[0094] Furthermore, the construction of the routing table based on the authorized menu item information includes:

[0095] The authorized menu item information is traversed to extract the routing information from the authorized menu item information;

[0096] Build a route whitelist based on the routing information and create a routing table.

[0097] The redirection request determination module 32 is used to respond to a user-initiated redirection request and determine whether to respond to the redirection request based on the routing table.

[0098] For example, in response to a user's page jump request initiated by the navigation menu, it is determined whether the route to the target page exists in the routing table; if the route to the target page does not exist in the routing table, the route is redirected to a preset page; if the route to the target page exists in the routing table, in response to the page jump request, the user is redirected to the target page corresponding to the page jump request.

[0099] Furthermore, the routes in the routing table are added with an identifier parameter to obtain a complete route, and the identifier parameter is unique for each device; in response to a device access request initiated by a user on the target page, the identifier parameter in the complete route of the target device is obtained; if the identifier parameter in the complete route of the target device does not exist in the authorized device information, the route is redirected to a preset page; if the identifier parameter in the complete route of the target device exists in the authorized device information, the device access request is responded to and the user is redirected to the page of the target device.

[0100] This application uses routing to restrict user access permissions. Compared to regular interface or menu permissions, routing allows access to the same page, but prevents access to devices on that page for which the user lacks routing permissions. Interface or menu permissions, on the other hand, prevent access to the entire page. However, in practical applications, it's often necessary for users to access a specific menu item, but only a single device within that menu. Menu and interface permissions cannot achieve this functionality.

[0101] The preset page redirection module 33 is used to redirect the route to a preset page when the redirection request is not responded to. The preset page is used to indicate to the user that they do not have access rights, such as a 404 page.

[0102] The access control device for a digital platform provided in this application embodiment obtains authorized device information and authorized menu item information at the front end. Based on the authorized menu item information, it constructs a routing table and then generates a navigation menu based on the authorized menu item information and authorized device information. When a user wants to access a page on the navigation menu, the front end determines whether to respond to the redirection request based on the generated routing table. This application can not only automatically generate personalized navigation menus for users but also determine whether redirection is allowed based on routing. In this way, users can only access devices with routing permissions, satisfying user needs while achieving personalized access control.

[0103] Based on the same inventive concept, such as Figure 4 As shown, this application also provides an electronic device 40, comprising:

[0104] At least one processor 41 and at least one memory 42;

[0105] The memory stores the executable instructions of the processor;

[0106] The processor is configured to execute the access control method of the device digitization platform provided in the above embodiments.

[0107] The electronic device provided in this application stores executable instructions for the processor in its memory. When these instructions are executed, the processor obtains authorized device information and authorized menu item information from the front end, constructs a routing table based on the authorized menu item information, and then generates a navigation menu based on the authorized menu item information and authorized device information. When a user wants to access a page on the navigation menu, the front end determines whether to respond to the redirection request based on the generated routing table. This application can not only automatically generate personalized navigation menus for users, but also determine whether redirection is allowed based on routing. In this way, users can only access devices with routing permissions, satisfying user needs while achieving personalized access control.

[0108] Based on the same inventive concept, this application provides a device digitization platform, including: a front end and a back end;

[0109] The front-end application uses the device digital platform access method provided in any of the above embodiments;

[0110] The backend is used to verify the account and password sent by the frontend, and to send authorized device information to the frontend when it receives an authorization device information request from the frontend, and to send authorized device information to the frontend when it receives an authorization menu item information request from the frontend.

[0111] In a preferred implementation of this application, the backend is further configured to:

[0112] The system receives user information and device information sent by the front end. The user information includes at least one of the following dimensions: a region dimension representing the user's work area, a function dimension representing the user's job, and a department dimension representing the user's department. The device information includes at least one of the following: device location, device model, and department.

[0113] Based on the user information and the device information, authorized device information is generated for the user, wherein the region dimension of the authorized device information matches the device location, and / or the function dimension matches the device model, and / or the department dimension matches the user's department.

[0114] The following section uses an industrial robot digital platform as an example to explain the solution in detail. The overall process is as follows: Figure 5 As shown.

[0115] 1. The architecture is as follows:

[0116] It includes the following core modules:

[0117] 1.1 Identity Authentication Gateway Module

[0118] Components: Account parser, attribute collector

[0119] Connection relationship: After receiving the frontend request, connect to the database to verify login information.

[0120] Function: Outputs authentication data packets such as user ID and role ID.

[0121] 1.2 Dynamic Menu Engine Module

[0122] Components: Character parser, device mapper, menu generator

[0123] Connection relationship: After receiving a request from the front end, it connects to the database to obtain authorized menu items and authorized device information.

[0124] Function: Retrieve authorized devices based on user ID, retrieve authorized menu items based on role ID, and generate a dynamic menu based on the authorized menu items and authorized devices.

[0125] 1.3 Intelligent Router Protection Module

[0126] Components: Route loader, parameter validator, exception handler

[0127] Function: Builds a route whitelist based on authorized menu items, verifies query parameters in the complete route, and redirects unauthorized pages to a 404 page.

[0128] 2. Dynamic Menu Generation Method

[0129] The navigation menu of this invention is divided into a general module and a device module (attached). Figure 1 The top-level menus all belong to the general module, with appendices... Figure 1 The third-level menu under "Online Devices" is the device module. The specific content of the general module and the device module is determined by the user role, and different roles can access different pages. The second-level menu under "Online Devices" (specific devices) is determined by the user attributes. Different users can access different devices, but each device has the same menu group (third-level menu).

[0130] When a user enters their username and password, the backend receives the username and password and calls the database to verify the information. If the verification is successful, it will send an authentication data packet containing the user ID and role ID to the frontend.

[0131] After receiving the user ID and role ID, the front-end will call the interface to obtain authorized device information based on the user ID and the authorized menu item information based on the role ID.

[0132] After receiving a request from the frontend, the backend will call the user-device intermediate table and the role-menu intermediate table in the database to send the authorized device and authorized menu item to the frontend.

[0133] After obtaining the authorized menu items, the front-end will use the menu item information to generate a general menu. Upon obtaining the authorized device information, a second-level menu will be generated under the first-level menu "Online Devices," such as Device 1 and Device 2, named "Device + Device Number." Each device node automatically derives a standard operation third-level menu (Device Details, Parameter Adjustment, and Waveform Acquisition). Not every user can use all device functions; the number of functions is determined by the user's role (authorized menu items). Users with the lowest privileges can only use the Device Details function. To prevent interference between menu groups (third-level menus), a deep copy (i.e., creating a new set of data instead of referencing the original data) is used to create new menu groups and assign them to new devices.

[0134] Device permissions are personal permissions. There are two ways to assign device permissions: one is to collect user information during user registration, and after review by the administrator, the system will automatically assign matching devices based on the user information; the other is that the administrator can directly assign access permissions for a device to a user in the system.

[0135] To achieve automatic device permission allocation, relevant permission information needs to be set for each device, including location, model, and department. User information should also include corresponding information. Then, permission matching rules need to be set in the system. For example: geolocation matching: a user belonging to "Factory A" can access all devices located in Factory A; model matching: a user who is a "SCARA developer" can access all SCARA devices. Even complex combinations of rules can be set, such as allowing a six-axis robot developer in the Equipment Institute to access all six-axis robots in the R&D building laboratory. After user registration information is approved by the administrator, the system automatically triggers the device permission allocation process. Therefore, by adding key fields to device and user information and pre-setting matching rules, access permissions for the corresponding devices can be obtained immediately after successful user registration, providing convenience for device permission allocation. Furthermore, even after the system automatically allocates device permissions, administrators can still manually adjust user device permissions (adding or removing access permissions for a device) within the system, providing flexibility while maximizing device security.

[0136] The menu data retrieval is written in the main.ts file and will be executed immediately when the page starts or refreshes. After the data is retrieved, the cache will be called to update the routing table, and the navigation menu will also automatically load new data when the page is refreshed, so as to realize the timely application of permissions.

[0137] 3. Routing protection mechanism

[0138] After obtaining the authorized menu item data, the front end will iterate through the authorized menu items, extract the routing information, and build a route whitelist and create a routing table based on the routing information.

[0139] When redirecting a page, first check if the page route exists in the routing table. If not, redirect the route to a 404 page.

[0140] Because the device modules use the same components and have the same routes, a query parameter (recording the device number) is added to the route to construct a complete route for differentiation. When accessing a device, the query parameter is first extracted from the complete route, and the device number in the query parameter is compared with the authorized devices. If it is found that the user does not have access rights to the device, the route is redirected to a 404 page.

[0141] 4. Example of a permission database

[0142] This embodiment requires the use of, for example Figure 6 The four database entity relationships shown are as follows: there is a one-to-many relationship between roles and users, and many-to-many relationships between roles and menu items, and between users and devices.

[0143] To retrieve menu information based on role ID, an intermediate table needs to be created to store the many-to-many relationship between roles and menu items. After creating this relationship, all menu item IDs can be retrieved by role ID. Then, menu item details are preloaded based on these IDs. Once all menu item details are retrieved, the navigation menu for the general module can be created.

[0144] To retrieve authorized device information based on user ID, an intermediate table needs to be created to store the many-to-many relationship between users and devices. After creating the many-to-many relationship, all authorized device IDs can be retrieved by user ID. Then, device details are preloaded based on the device ID. After retrieving the device details, a standard three-level menu can be automatically generated for each device node.

[0145] This application uses an identifier parameter to distinguish different device modules. In actual operation, the identifier parameter can be omitted, and the same effect of distinguishing different device modules can be achieved by using named routing. The only difference is that the configuration of named routing is more complicated than that of the identifier parameter.

[0146] For the third-level menu under the specific device node of "Online Devices", the third-level menu does not need to be displayed in the sidebar. It can be displayed in the content area as a floating menu, with a similar effect.

[0147] For specific device nodes of "online devices", they can also be displayed on the specific page in the form of a table or card instead of in the sidebar. Clicking on a specific device will take you to the device function page, where the device functions (device details, parameter debugging, waveform acquisition, etc.) are displayed in the form of a floating menu.

[0148] This application's embodiments achieve highly granular access control by combining user roles and personal attributes to customize navigation menus. In the general module, different functions can be assigned based on user roles; in the device module, different device access permissions can be assigned based on user personal attributes, thus achieving highly customized navigation menus. In the device module of the navigation menu, menu group reuse technology is used, ensuring each device directory has a complete function menu, and these function menus can also be customized, improving configuration flexibility and efficiency. This invention restricts user-accessible routes while customizing the navigation menu, ensuring users cannot directly access unauthorized pages via routes. Therefore, it not only enhances the personalization of the user experience but also greatly strengthens the security of the system and devices.

[0149] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0150] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

Claims

1. An access control method for a device digitization platform, characterized in that, Applied to the front end, the method includes: After obtaining authorized device information and authorized menu item information, a routing table is constructed based on the authorized menu item information, and a navigation menu is generated based on the authorized menu item information and the authorized device information; In response to a user-initiated redirection request, determine whether to respond to the redirection request based on the routing table; If the redirection request is not responded to, the route will be redirected to a preset page.

2. The method according to claim 1, characterized in that: The step of constructing a routing table based on the authorized menu item information includes: The authorized menu item information is traversed to extract the routing information from the authorized menu item information; Build a route whitelist based on the routing information and create a routing table.

3. The method according to claim 1, characterized in that: The step of generating a navigation menu based on the authorized menu item information and the authorized device information includes: Generate a common first-level menu in the navigation menu based on the authorized menu item information; Under the online device option in the primary menu, a secondary menu is generated based on the authorized device information, wherein each secondary menu includes devices that the user can access; Generate a standard third-level menu for each device in the second-level menu.

4. The method according to claim 1, characterized in that: The step of responding to a user-initiated redirection request by determining whether to respond to the redirection request based on the routing table includes: In response to a user's page navigation request initiated by the navigation menu, determine whether the route to the target page exists in the routing table; If the route to the target page does not exist in the routing table, the route will be redirected to a preset page; If the route to the target page exists in the routing table, respond to the page redirection request and redirect to the target page corresponding to the page redirection request.

5. The method according to claim 4, characterized in that: The step of responding to a user-initiated redirection request by determining whether to respond to the redirection request based on the routing table includes: The complete route is obtained by adding the identification parameter to the route in the routing table, and the identification parameter is unique for each device. In response to a user's device access request initiated on the target page, obtain the identification parameters from the complete route of the target device; If the identifier parameter in the complete route to the target device is not found in the authorized device information, the route will be redirected to a preset page; If the authorized device information contains an identifier parameter in the complete route of the target device, the device access request will be responded to, and the user will be redirected to the target device's page.

6. The method according to claim 1, characterized in that, Also includes: In response to the user's username and password input, the username and password are sent to the backend for verification; After the backend verification is successful, the system receives authentication data sent by the backend, which includes user ID and role ID. The user ID is used to call the interface to send an authorization device information retrieval request to the backend, and the role ID is used to call the interface to send an authorization menu item information request to the backend. Receive authorized device information and authorized menu item information sent by the backend.

7. An access control device for a digital platform for equipment, characterized in that, Applied to the front end, the device includes: The navigation menu generation module is used to construct a routing table based on the authorized menu item information and generate a navigation menu based on the authorized menu item information and the authorized device information after obtaining authorized device information and authorized device information; The redirection request determination module is used to respond to a user-initiated redirection request and determine whether to respond to the redirection request based on the routing table. The preset page redirection module is used to redirect the route to a preset page when the redirection request is not responded to.

8. An electronic device, characterized in that, include: At least one processor and at least one memory; The memory stores the executable instructions of the processor; The processor is configured to perform the method according to any one of claims 1-6.

9. A digital platform for equipment, characterized in that, include: Front-end and back-end; The front-end application uses the method described in any one of claims 1-6; The backend is used to verify the account and password sent by the frontend, and to send authorized device information to the frontend when it receives an authorization device information request from the frontend, and to send authorized device information to the frontend when it receives an authorization menu item information request from the frontend.

10. The platform according to claim 9, characterized in that, The backend is also used for: The system receives user information and device information sent by the front end. The user information includes at least one of the following dimensions: a region dimension representing the user's work area, a function dimension representing the user's job, and a department dimension representing the user's department. The device information includes at least one of the following: device location, device model, and department. Based on the user information and the device information, authorized device information is generated for the user, wherein the region dimension of the authorized device information matches the device location, and / or the function dimension matches the device model, and / or the department dimension matches the user's department.

Images