A smart traffic-oriented multi-device permission management method and system

Abstract

This invention discloses a multi-device access control method and system for intelligent transportation, comprising: receiving a login request initiated by a user through a login page, the login request carrying the user's account information; authenticating the account information based on a preset user access permission association database in response to the login request; if authentication is successful, redirecting to a Swagger interface management page and generating a token for the user who initiated the login request, enabling the user to initiate an interface access request by entering the token on the Swagger interface management page; and retrieving the access permission number corresponding to the account information in the token from the user access permission association database within the token's validity period, allowing the user to access the corresponding third-party device interface based on the permission number. This achieves access control for user access to third-party device interfaces, provides unified management of different third-party device interfaces, and ensures security during the access process.

Description

Technical Field

[0001] This invention belongs to the field of intelligent transportation, specifically relating to a method and system for multi-device access control in intelligent transportation. Background Technology

[0002] With the continuous development of internet application technologies, China's highway transportation has entered a period of rapid digital and intelligent development. The continuous advancement of electronic equipment technologies has led to the increasingly mature application of intelligent transportation scenarios. The deployment of numerous third-party road equipment in intelligent transportation scenarios can, to a certain extent, ensure traffic safety. These third-party devices include intelligent traffic digital display devices and intelligent traffic signs.

[0003] The current intelligent transportation scenarios involve a wide variety of devices, which brings problems such as high equipment maintenance costs, significantly reduced user interaction efficiency, and compromised security.

[0004] Patent CN210639750U discloses a traffic condition monitoring device for smart cities. This solution integrates various third-party devices, such as smart streetlights, air quality monitoring equipment, and meteorological monitoring equipment, and, combined with a smart road platform, can comprehensively monitor traffic conditions. However, the modular management of multiple devices results in low efficiency in acquiring and interacting with status information from different devices, leading to higher maintenance costs.

[0005] Patent CN106296814A discloses a method and system for highway maintenance inspection and visualization interaction. It utilizes road data acquisition equipment to obtain information such as road surface smoothness and damage. Users can interact with the database based on this information to achieve intelligent road surface visualization maintenance. While obtaining information from the acquisition equipment is relatively convenient, there are potential security risks related to access permissions.

[0006] Patent CN115273451A discloses a smart pedestrian crossing early warning system. This system achieves early warning for pedestrian crossings by utilizing information transmission and interaction between various system modules, as well as information transmission with external network devices and an interaction center. The control center then schedules these modules to achieve early warning. While this smart transportation scenario allows for corresponding early warnings through the interaction of multiple devices, the reliance on a control center for scheduling significantly increases maintenance costs, and users cannot interact with the devices in real time.

[0007] Therefore, in the current intelligent transportation scenario, how to manage the interaction interfaces of different road equipment while saving costs, and how to meet the interaction needs of different users while ensuring security, have become urgent problems to be solved. Summary of the Invention

[0008] To address the aforementioned problems in the existing technology, this invention provides a multi-device access control method and system for intelligent transportation.

[0009] The technical problem to be solved by this invention is achieved through the following technical solution:

[0010] In a first aspect, the present invention provides a multi-device access control method for intelligent transportation, applied to a server; the method includes:

[0011] Receive a login request initiated by a user through the login page; the login request carries the user's account information;

[0012] In response to the login request, the account information is authenticated based on a preset user permission association database; wherein, the user permission association database stores account information of multiple users and permission numbers of at least one third-party device interface that each account information can access;

[0013] If authentication is successful, the user is redirected to the Swagger API management page, and a token is generated for the user who initiated the login request. This allows the user to enter the token on the Swagger API management page to initiate an API access request. The token contains the user's account information and the token's validity period.

[0014] In response to the interface access request, within the validity period of the token, the access permission number corresponding to the account information in the token is obtained from the user permission association database, so that the user who initiated the interface access request can access the corresponding third-party device interface according to the access permission number.

[0015] Optionally, the step of authenticating the account information based on a preset user permission association database in response to the login request includes:

[0016] In response to the login request, the login request is forwarded to the UsernamePasswordAuthenticationFilter of SpringSecurity through the OncePerRequestFilter, so that the UsernamePasswordAuthenticationFilter can authenticate the account information based on the user permission association database.

[0017] Optionally, the method further includes:

[0018] In response to the interface access request, determine whether the token is within its validity period;

[0019] If the token is not valid, the interface access request is rejected.

[0020] Optionally, the method further includes:

[0021] If an access request is received from an unlogged-in user to the Swagger API management page, the user will be redirected to the login page and prompted to log in.

[0022] Optionally, after obtaining the access permission number corresponding to the account information in the token from the user permission association database, the method further includes:

[0023] The retrieved records are stored in the retrieved record database.

[0024] Optionally, the method further includes:

[0025] If authentication fails, an authentication error message will be displayed on the login page.

[0026] Secondly, this invention provides a multi-device access control system for intelligent transportation, the system comprising multiple third-party devices and a server in an intelligent transportation scenario; the server includes:

[0027] The receiving module is used to receive login requests initiated by users through the login page; the login request carries the user's account information.

[0028] The user authentication module is used to respond to the login request and authenticate the account information based on a preset user permission association database; wherein, the user permission association database stores account information of multiple users and permission numbers of at least one third-party device interface that each account information can access;

[0029] The token generation module is used to redirect to the Swagger interface management page and generate a token for the user who initiated the login request when the user authentication module passes the authentication, so that the user can initiate an interface access request by entering the token on the Swagger interface management page; the token stores the user's account information and the token's validity period;

[0030] The permission acquisition module is used to respond to the interface access request and, within the validity period of the token, retrieve the permission number that the account information in the token can access, so that the user who initiated the interface access request can access the corresponding third-party device interface according to the permission number.

[0031] Optionally, the user authentication module is specifically used for:

[0032] In response to the login request, the login request is forwarded to the UsernamePasswordAuthenticationFilter of SpringSecurity through the OncePerRequestFilter, so that the UsernamePasswordAuthenticationFilter can authenticate the account information based on the user permission association database.

[0033] Optionally, the system further includes:

[0034] The token verification module is used to determine whether the token is valid in response to the interface access request;

[0035] If the token is not valid, the interface access request is rejected.

[0036] Optionally, the system further includes:

[0037] The redirection module is used to redirect users to the login page and prompt them to log in if an access request is received from an unlogged-in user to the Swagger interface management page.

[0038] Optionally, the system also includes:

[0039] The record acquisition and storage module is used to store the acquisition record in the acquisition record database after obtaining the access permission number corresponding to the account information in the token from the user permission association database.

[0040] Optionally, the system also includes:

[0041] The authentication error message module is used to display authentication error information on the login page if authentication fails.

[0042] This invention provides a multi-device access control method for intelligent transportation. Compared to existing technologies, most current intelligent transportation applications lack unified management of third-party device interface interactions and permission restrictions. In this solution, because a preset user permission association database contains account information for multiple users and permission numbers for at least one third-party device interface that each account can access, authentication can be performed based on the preset user permission association database when a login request carrying account information is received from a user. After successful authentication, a token is generated for the user on the Swagger interface management page. Since the token contains the user's account information, the user can obtain the corresponding permission number by entering the token, and then access the corresponding third-party device interface according to the permission number. Through permission management, access control of user access to third-party device interfaces can be achieved, allowing users to access only the third-party devices within their own permissions, thus ensuring security during the access process.

[0043] Furthermore, compared to existing solutions that typically employ multiple modules for device interaction and information relay, resulting in fragmented control and high costs for different types of third-party device interfaces, this solution utilizes a Swagger interface management page for unified management of various third-party device interfaces. The Swagger management page eliminates the need for multiple modules to manage and control access to third-party device interfaces, reducing maintenance costs and improving user experience. Additionally, the Swagger page enables token entry, facilitating the verification of user access permissions.

[0044] The present invention will now be described in further detail with reference to the accompanying drawings. Attached Figure Description

[0045] Figure 1 This is a flowchart illustrating a multi-device access control method for intelligent transportation provided in an embodiment of the present invention;

[0046] Figure 2 This is a schematic diagram of a login page scenario provided in an embodiment of the present invention;

[0047] Figure 3 This is a schematic diagram of a scenario for the Swagger interface management page provided in an embodiment of the present invention;

[0048] Figure 4 This is a flowchart illustrating another method for multi-device access control in intelligent transportation provided by an embodiment of the present invention;

[0049] Figure 5 This is a schematic diagram of the server structure of a multi-device access control system for intelligent transportation provided in an embodiment of the present invention. Detailed Implementation

[0050] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0051] Currently, most intelligent transportation applications lack unified management of device interactions and permission restrictions. Faced with complex traffic situations, the inability to obtain real-time road conditions and device status makes it difficult to provide effective warnings for vehicles. Furthermore, unknown device status increases maintenance costs and hinders long-term use.

[0052] To address the aforementioned problems, embodiments of the present invention provide a multi-device access control method for intelligent transportation, see [link to relevant documentation]. Figure 1 , Figure 1 This is a flowchart illustrating a multi-device access control method for intelligent transportation provided by an embodiment of the present invention, applied to the server side, including:

[0053] Step S101: Receive a login request initiated by the user through the login page. The login request carries the user's account information.

[0054] In this embodiment, the login request carries the user's account information, which may include the user's login account and login password.

[0055] See Figure 2 , Figure 2 This is a schematic diagram of a login page provided in an embodiment of the present invention. Users can initiate a login request carrying their account information by entering their login account in the "Account" field, their login password in the "Password" field, and then clicking the login button.

[0056] Step S102: In response to the login request, the account information is authenticated based on a preset user permission association database. The user permission association database stores account information of multiple users and permission numbers of at least one third-party device interface that each account information can access.

[0057] In this embodiment, the user's account information is carried in the user login request. Therefore, by comparing the user's account information carried in the login request with the account information stored in the preset user permission association database, the account information can be authenticated.

[0058] The preset user permission association database contains account information for multiple users and permission numbers for at least one third-party device interface that each account can access.

[0059] In this embodiment, the RBAC (Role-Based Access Control) model is used to establish user role permission relationships. The RBAC model is an access control mechanism widely used in the field of computer security. The RBAC model controls users' access permissions to resources in the system by assigning users to different roles.

[0060] In this embodiment, the user permission association database can be a MySQL (My Structured Query Language) database. MySQL is a relational database. On the server side, a connection to the user permission association database can be established using the database's address, username, and password.

[0061] In this embodiment, the user permission association database may include a role-user association data table (role_user), a role-permission association data table (role_persmission), and a system user table (sys_user).

[0062] The role-permission association data table stores the role information assigned to users and the permission numbers of the third-party device interfaces that users can access. For example, if user 1 is set as management role 1 who can access all third-party device interfaces, then the information of management role 1 and the permission numbers of all third-party device interfaces are filled in the role-permission association data table, meaning that management role 1 can access all third-party devices.

[0063] Some users can only access a specific third-party device, some can access a few third-party devices, and some can access all third-party devices in the system. Therefore, users can be assigned different roles, and different permissions can be assigned based on the role information. For example, if user 2 is assigned role 2, and role 2 can access third-party device interface 1 and third-party device interface 2, then the role permission association data table should be filled with the information of role 2 and the permission numbers of third-party device interface 1 and third-party device interface 2 that role 2 can access.

[0064] In the role-user association data table, users are associated to distinguish the third-party device interfaces that different users can access. For example, management users can create and associate User 2 and User 3.

[0065] The system user table stores user account information and their corresponding role information. For example, user account information can include the user's login username and password, and may also include the user's login name. User passwords can be encrypted using BCryptPassword, a built-in encryption tool of Spring Security, a security framework used to protect system security. Encrypting user passwords and storing them in the system user table ensures the security of user account information.

[0066] For example, after setting user 1 as administrator role 1, the encrypted account information of user 1 is associated with the information of administrator role 1 and stored in the system user table. After setting user 2 as role 2, the encrypted account information of user 2 and the information of role 2 are associated and stored in the system user table.

[0067] Step S103: If authentication is successful, redirect to the Swagger interface management page and generate a token for the user who initiated the login request, so that the user can initiate an interface access request by entering the token on the Swagger interface management page. The token contains the user's account information and the token's validity period.

[0068] In this embodiment, Swagger is an API (Application Programming Interface) development tool.

[0069] A token is a string generated by the server based on a user's account information, used for user authentication and authorization. Each token is unique and corresponds to each user.

[0070] In this embodiment, the token can be a JWT (JSON Web Token). A JWT consists of three parts: a header, a payload, and a signature.

[0071] The user's account information and token expiration date are used as the payload. The server can choose the encryption algorithm and key (JWT_KEY) as the JWT signature according to its needs. For example, the encryption algorithm can be the HS256 symmetric encryption algorithm.

[0072] After generating the login user's token, store the token in Redis (Remote Dictionary Server) and redirect to the Swagger API management page.

[0073] The generated token is displayed to the user on the Swagger API management page. The user initiating the login request can then enter the token to initiate an API access request on the Swagger API management page. See also... Figure 3 , Figure 3 This is a schematic diagram of a Swagger interface management page provided in an embodiment of the present invention. Users initiate an interface access request by entering a token in the "Token" box and then clicking the Authorize button.

[0074] Step S104: In response to the interface access request, within the validity period of the token, retrieve the access permission number corresponding to the account information in the token from the user permission association database, so that the user who initiated the interface access request can access the corresponding third-party device interface according to the access permission number.

[0075] After receiving an API access request, the server will respond by retrieving the access permission number corresponding to the account information in the token from the user permission database within the token's validity period.

[0076] Because the system user table in the user permission association database stores user account information and corresponding role information, and the role permission association data table stores the role information assigned to the user and the permission numbers of the third-party device interfaces that the user can access, the permission number corresponding to that account can be obtained through the account information in the token. The user initiating the interface request can then access the corresponding third-party device interface based on that permission number.

[0077] In this embodiment, the specific steps for authentication and obtaining permission numbers through the role-permission association data table and the system user table in the user permission association database are as follows:

[0078] Step 1: After authenticating the user's account information in the system user table based on the logged-in user's account information, find the user's corresponding role information based on the account information.

[0079] Step 2: After obtaining the user's role information, retrieve the permission number of the third-party device interface that the user can access based on the role permission association data table.

[0080] In this embodiment, the interface types of third-party devices can also be classified according to their type or function, such as third-party devices for data collection or third-party devices for road warning. Third-party devices may include loudspeakers, information boards, or weather stations, etc.

[0081] In addition, third-party device interfaces also include functional interfaces such as device status query interfaces and interactive command issuance interfaces. When a user has access to a certain third-party device interface, they also have access to all functional interfaces under that third-party device interface.

[0082] In this embodiment, compared to existing technologies where most current smart transportation applications lack unified management of third-party device interface interactions and permission restrictions, this solution addresses this issue by pre-setting a user permission association database containing multiple user account information and permission numbers for at least one third-party device interface that each account can access. Therefore, upon receiving a login request from a user carrying account information, authentication can be performed based on the pre-set user permission association database. After successful authentication, a token is generated for the user on the Swagger interface management page. Since the token contains the user's account information, the user can obtain their corresponding permission number by entering the token and then access the corresponding third-party device interface based on the permission number. This permission management system controls user access to third-party device interfaces, ensuring that users can only access third-party devices within their own permissions, thus guaranteeing security during the access process.

[0083] Furthermore, compared to existing solutions that typically employ multiple modules for device interaction and information relay, resulting in fragmented control and high costs for different types of third-party device interfaces, this solution utilizes a Swagger interface management page for unified management of various third-party device interfaces. The Swagger management page eliminates the need for multiple modules to manage and control access to third-party device interfaces, reducing maintenance costs and improving user experience. Additionally, the Swagger page enables token entry, facilitating the verification of user access permissions.

[0084] In this embodiment, the aforementioned authentication and permission number acquisition steps are implemented based on Spring Security. Spring Security is a user authentication and authorization framework based on the Spring framework.

[0085] In response to a login request, the login request is forwarded through Spring Security's OncePerRequestFilter (a filter that ensures a request is processed only once) to Spring Security's UsernamePasswordAuthenticationFilter (a filter used for user authentication). This allows the UsernamePasswordAuthenticationFilter to authenticate the account information based on a predefined database of user permissions.

[0086] The `OncePerRequestFilter` is an abstract filter class in the Spring Boot framework (Spring Boot is a framework built on top of Spring, used to simplify initial setup and development). All user requests (login requests and API access requests) are filtered by this filter. The core of the `OncePerRequestFilter` class is the `doFilterInternal` method, which performs the request filtering operation. In this embodiment, the `doFilterInternal` method refers to the aforementioned authentication and permission acquisition logic steps. Third-party device interfaces are created in the `Service` package within the Spring Boot project.

[0087] In this embodiment, after a user initiates a login request, it is intercepted by the OncePerRequestFilter and enters the doFilterInternal method. Inside this method, it determines that the user is not yet logged in based on the login request. Therefore, the filterChain.doFilter method within doFilterInternal allows the login request to proceed. Allowing the request means forwarding it to the next Spring Security filter, UsernamePasswordAuthenticationFilter, which is used to authenticate the account information in the login request. After allowing the request, the internal code automatically executes the loadUserByUsername authentication method provided by Spring Security. This method is the authentication method within UsernamePasswordAuthenticationFilter. This authentication method retrieves the user's account information from the user permission association database based on the user's input account information and compares it. If they match, the user is authenticated. If they do not match, the user fails authentication. If authentication fails, an authentication error message is displayed on the login page. For example, it may display a message such as "User authentication information error" to prompt the user to enter the correct account information.

[0088] In this embodiment, a series of filters provided by Spring Security are used. Every user operation passes through the OncePerRequestFilter to verify information such as the user's permission number and the validity of the token. Therefore, every user operation can go through Spring Security and the aforementioned authentication and permission number acquisition steps to ensure the security and validity of the user's access to the third-party device interface, thus solving the security risks that exist in most existing intelligent transportation solutions for user interaction with third-party devices.

[0089] In this application, the RBAC model is used to establish user role and permission relationships, and the Swagger interface is used to manage the page for permission control. There is no need to develop additional front-end pages, and a static login page is used instead, which improves the user experience and reduces maintenance costs.

[0090] In addition, the system needs to determine whether the token is valid when responding to an API access request. If the token is not valid, it means that the token has expired, and the API access request will be rejected to ensure security. When a user performs an API access operation and the token is not valid, the user will be prompted with a message such as "Token expired, please log in again," so that the user can log in again and continue to initiate the API access request.

[0091] In this embodiment of the application, in order to prevent unlogged users from accessing third-party device interfaces and causing security risks, when an access request is received from an unlogged user to the Swagger interface management page, the user is redirected to the login page and prompted to log in.

[0092] For example, if an unknown user sends an access request to the Swagger API management page before logging in on the login page, the user will be redirected to the login page with a message such as "Please log in to your account first."

[0093] In this embodiment, after obtaining the access permission number corresponding to the account information in the token from the user permission association database, the acquisition record can also be saved in the acquisition record database. This acquisition record database can also be the aforementioned MySQL database. After a user obtains the corresponding permission number for a third-party device interface on the Swagger interface management page and accesses the third-party device interface, they can view the acquisition records and results through the acquisition record database. Then, by combining this with on-site observation of the status, the interaction effect of the third-party device interface can be judged, and the status information of the third-party device can be obtained. This allows for accurate location of the target third-party device when it malfunctions, facilitating maintenance.

[0094] Furthermore, if a user wants to log out during use, they can do so by accessing the Logout interface. Upon logout, the user's token will be removed from Redis, and a message similar to "User has logged out" will be displayed. If the user then wants to access the third-party device interface again, they will need to return to the login page to re-authenticate and obtain a permission number before they can continue accessing the interface.

[0095] The Spring Security solution in this project also provides multiple Handlers. These Handlers can implement corresponding follow-up processing based on actual needs; for example, an authentication failure handler handles subsequent operations after authentication failure, and a successful logout handler handles subsequent operations after logging out. Handlers can recognize the current user's interaction state with the third-party device interface while implementing subsequent operations or providing relevant information, greatly reducing development costs and time, and making third-party device interaction interface permission management flexible and convenient.

[0096] For example, if user authentication fails, the user is redirected to the authentication failure handler, which returns relevant error information to the user. Alternatively, if the user successfully logs out, the user is redirected to the logout success handler, which performs operations such as deleting the user's login information.

[0097] See Figure 4 , Figure 4 This is a flowchart illustrating another multi-device access control method for intelligent transportation provided by an embodiment of the present invention, including:

[0098] Step S401: Log in with account and password.

[0099] Users log in by entering their username and password on the login page, initiating a login request that carries the user's account information.

[0100] Step S402, Spring Security Authentication.

[0101] User account information authentication is performed using Spring Security.

[0102] Step S403, MySQL database.

[0103] The MySQL database stores account information for multiple users and permission numbers for at least one third-party device interface that each account can access. User authentication can then be performed by comparing the user's account information.

[0104] Step S404: Is the authentication successful?

[0105] Determine if authentication is successful. If the account information in the login request matches the account information stored in MySQL, authentication is successful, and proceed to step S406. If the account information in the login request does not match the account information stored in MySQL, authentication fails, and proceed to step S405.

[0106] Step S405 returns an error message.

[0107] When authentication fails, an error message is returned to the user, prompting the user to re-enter the correct account information to log in and authenticate.

[0108] Step S406: Generate Jwt and return.

[0109] Generate a JWT for the user who initiates the login request. The JWT contains the user's account information and the token's expiration date.

[0110] Step S407, Redis caching.

[0111] Store the generated JWT in Redis.

[0112] Step S408 redirects you to the Swagger API management page.

[0113] The generated token is displayed to the user on the Swagger API management page.

[0114] Step S409, Permission verification.

[0115] Users who initiate login requests can perform permission verification by entering a token on the Swagger API management page to request API access.

[0116] Step S410, Interface access.

[0117] In response to an interface access request, within the validity period of the JWT, the system retrieves the access permission number corresponding to the account information in the JWT from the MySQL database, so that the user who initiated the interface access request can access the corresponding third-party device interface based on the permission number.

[0118] In this embodiment, Spring Security is used to ensure the security and validity of user access to third-party device interfaces, resolving the security risks associated with user interaction with third-party devices in most current intelligent transportation solutions. The use of Swagger pages not only enables access to third-party device interfaces but also allows for unified management of different third-party device interfaces and facilitates JWT input, which helps verify interface permissions.

[0119] Based on the same inventive concept, embodiments of the present invention also provide a multi-device access control system for intelligent transportation, the system including multiple third-party devices and servers in intelligent transportation scenarios; see [link to related document]. Figure 5 , Figure 5 This is a schematic diagram of the server structure of a multi-device access control system for intelligent transportation provided in an embodiment of the present invention. The server includes:

[0120] The receiving module 501 is used to receive login requests initiated by users through the login page, and the login requests carry the user's account information.

[0121] User authentication module 502 is used to authenticate account information based on a preset user permission association database in response to login requests. The user permission association database stores account information of multiple users and permission numbers of at least one third-party device interface that each account can access.

[0122] The token generation module 503 is used to redirect to the Swagger interface management page and generate a token for the user who initiated the login request when the user authentication module passes the authentication. This allows the user to initiate an interface access request by entering the token on the Swagger interface management page. The token contains the user's account information and the token's validity period.

[0123] The permission acquisition module 504 is used to respond to interface access requests and, within the validity period of the token, retrieve the access permission number corresponding to the account information in the token from the user permission association database, so that the user who initiated the interface access request can access the corresponding third-party device interface according to the access permission number.

[0124] In this embodiment, compared to existing technologies where current smart transportation applications mostly lack unified management of third-party device interface interactions and permission restrictions, this solution addresses this issue. Because the preset user permission association database contains account information for multiple users and permission numbers for at least one third-party device interface that each account can access, when the receiving module 501 receives a login request carrying account information from a user, the user authentication module 502 can perform authentication based on the preset user permission association database. After successful authentication, the token generation module 503 generates a token for the user on the Swagger interface management page. Since the token contains the user's account information, the user can enter the token and obtain the corresponding permission number through the permission acquisition module 504. Then, based on the permission number, the user can access the corresponding third-party device interface. Through permission management, access control for user access to third-party device interfaces can be achieved, ensuring that users can only access third-party devices within their own permissions, thus guaranteeing security during the access process.

[0125] Furthermore, compared to existing solutions that typically employ multiple modules for device interaction and information relay, resulting in fragmented control and high costs for different types of third-party device interfaces, this solution utilizes a Swagger interface management page for unified management of various third-party device interfaces. The Swagger management page eliminates the need for multiple modules to manage and control access to third-party device interfaces, reducing maintenance costs and improving user experience. Additionally, the Swagger page enables token entry, facilitating the verification of user access permissions.

[0126] Optionally, the user authentication module is specifically used for:

[0127] In response to the login request, the login request is forwarded to the UsernamePasswordAuthenticationFilter of SpringSecurity through the OncePerRequestFilter, so that the UsernamePasswordAuthenticationFilter can authenticate the account information based on the user permission association database.

[0128] Optionally, the system also includes:

[0129] The token verification module is used to determine whether the token is valid in response to the interface access request;

[0130] If the token is not valid, the interface access request is rejected.

[0131] Optionally, the system also includes:

[0132] The redirection module is used to redirect users to the login page and prompt them to log in if an access request is received from an unlogged-in user to the Swagger interface management page.

[0133] Optionally, the system also includes:

[0134] The record acquisition and storage module is used to store the acquisition record in the acquisition record database after obtaining the access permission number corresponding to the account information in the token from the user permission association database.

[0135] Optionally, the system also includes:

[0136] The authentication error message module is used to display authentication error information on the login page if authentication fails.

[0137] It should be noted that, for the system implementation, since it is basically similar to the method implementation, the description is relatively simple, and relevant parts can be referred to in the description of the method implementation.

[0138] It should be noted that the terms "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of systems and methods consistent with some aspects of the invention.

[0139] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features or characteristics described may be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and integrate the different embodiments or examples described in this specification.

[0140] Although the invention has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings and the disclosure in carrying out the claimed invention. In the description of the invention, the word "comprising" does not exclude other components or steps, "a" or "an" does not exclude a plurality, and "a plurality" means two or more, unless otherwise explicitly specified. Furthermore, while different embodiments may describe certain measures, this does not mean that these measures cannot be combined to produce good results.

[0141] It should be noted that the system in this embodiment of the invention is a system that applies the above-mentioned method for managing the access rights of multiple devices for intelligent transportation. Therefore, all embodiments of the above-mentioned method for managing the access rights of multiple devices for intelligent transportation are applicable to this system and can achieve the same or similar beneficial effects.

[0142] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for multi-device access control in intelligent transportation, characterized in that, Applied to the server side; the method includes: Receive a login request initiated by a user through the login page; the login request carries the user's account information; In response to the login request, the account information is authenticated based on a preset user permission association database; wherein, the user permission association database stores account information of multiple users and permission numbers of at least one third-party device interface that each account information can access; If authentication is successful, the user is redirected to the Swagger API management page, and a token is generated for the user who initiated the login request. This allows the user to enter the token on the Swagger API management page to initiate an API access request. The token contains the user's account information and the token's validity period. In response to the interface access request, within the validity period of the token, the access permission number corresponding to the account information in the token is obtained from the user permission association database, so that the user who initiated the interface access request can access the corresponding third-party device interface according to the access permission number.

2. The method of claim 1, wherein, The step of authenticating the account information based on a preset user permission association database in response to the login request includes: In response to the login request, the login request is forwarded to the UsernamePasswordAuthenticationFilter of SpringSecurity through the OncePerRequestFilter, so that the UsernamePasswordAuthenticationFilter can authenticate the account information based on the user permission association database.

3. The method of claim 1, wherein, The method further includes: In response to the interface access request, determine whether the token is within its validity period; If the token is not valid, the interface access request is rejected.

4. The method of claim 1, wherein, The method further includes: If an access request is received from an unlogged-in user to the Swagger API management page, the user will be redirected to the login page and prompted to log in.

5. The method of claim 1, wherein, After retrieving the access permission number corresponding to the account information in the token from the user permission association database, the method further includes: The retrieved records are stored in the retrieved record database.

6. The method of claim 1, wherein, The method further includes: If authentication fails, an authentication error message will be displayed on the login page.

7. A smart traffic-oriented multi-device permission management system, characterized in that, The system includes multiple third-party devices and servers in a smart transportation scenario; the server includes: The receiving module is used to receive login requests initiated by users through the login page; the login request carries the user's account information. The user authentication module is used to respond to the login request and authenticate the account information based on a preset user permission association database; wherein, the user permission association database stores account information of multiple users and permission numbers of at least one third-party device interface that each account information can access; The token generation module is used to redirect to the Swagger interface management page and generate a token for the user who initiated the login request when the user authentication module passes the authentication, so that the user can initiate an interface access request by entering the token on the Swagger interface management page; the token stores the user's account information and the token's validity period; The permission acquisition module is used to respond to the interface access request and, within the validity period of the token, retrieve the permission number that the account information in the token can access, so that the user who initiated the interface access request can access the corresponding third-party device interface according to the permission number.

8. The system of claim 7, wherein, The user authentication module is specifically used for: In response to the login request, the login request is forwarded to the UsernamePasswordAuthenticationFilter of SpringSecurity through the OncePerRequestFilter, so that the UsernamePasswordAuthenticationFilter can authenticate the account information based on the user permission association database.

9. The system of claim 7, wherein, The system also includes: The token verification module is used to determine whether the token is valid in response to the interface access request; If the token is not valid, the interface access request is rejected.

10. The system of claim 7, wherein, The system also includes: The redirection module is used to redirect users to the login page and prompt them to log in if an access request is received from an unlogged-in user to the Swagger interface management page.

Images