System authentication method and device based on Redis

Abstract

The invention discloses a system authentication method and device based on Redis, belongs to the technical field of system login authentication, and aims to solve the technical problem of how to provide an authentication method for a user to ensure that the user normally uses a system function. The login authentication of the user is realized based on the front-end service provided by the browser and the gateway service, the authentication service, the business service, the database service, the Redis cache service and the short message service provided by the rear end, and the encryption and verification of the login state of the user are realized through the Redis and JWT technologies, so that the hostile attack and illegal access are effectively prevented, and the security is improved; through the analysis and verification of the JWT token, the access control of the user request is realized, and the security of a service system is ensured; through the Redis cache service, the consistency of data such as a user verification code and a login state is ensured, and the problem of data synchronization is avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of system login authentication, and in particular to a system authentication method and device based on Redis. Background Art

[0002] System login authentication is a technology that authenticates users and ensures the availability of subsequent functions, and plays an important role in system applications.

[0003] Redis: An open source, high-performance, key-value-based in-memory database that can be used as a database, cache, and message middleware.

[0004] JWT (JSON Web Token): An open standard (RFC 7519) that defines a compact and self-contained way to securely transmit information between parties in the form of a JSON object. Due to its compact and self-contained nature, JWT is often used in authentication and information exchange scenarios.

[0005] SHA-512 encryption technology: A cryptographic hash function used to generate a 512-bit hash value, usually expressed as 128 hexadecimal digits.

[0006] Based on Redis, JWT and encryption technology, how to provide users with authentication methods to ensure that users can use system functions normally is a technical problem that needs to be solved. Summary of the invention

[0007] The technical task of the present invention is to address the above shortcomings and provide a system authentication method and device based on Redis to solve the technical problem of how to provide users with an authentication method to ensure that users can use system functions normally.

[0008] In a first aspect, the present invention provides a system authentication method based on Redis, which implements user login authentication based on a front-end service provided by a browser and a gateway service, an authentication service, a business service, a database service, a Redis cache service, and a short message service provided by a back-end, and the method comprises the following steps:

[0009] The user initiates a request to obtain a verification code from the authentication service through the front-end service;

[0010] Based on the verification code request, the authentication service queries the user information from the database service and verifies the user status based on the user information;

[0011] After the user status verification passes, the authentication service retrieves the user's SMS sending count from the Redis cache service and verifies the SMS sending count. After the SMS sending count verification passes, a verification code is generated and sent to the user via the SMS service. The verification code, user information, and the sending time of the verification code sent via the SMS service are stored in the Redis service. The validity period of the verification code is set, and the SMS sending count in the Redis cache is updated;

[0012] After the user receives the verification code, a login request is initiated to the authentication service through the front-end service. The login request carries the user information and the verification code;

[0013] Based on the login request, the authentication service verifies the verification code through the Redis cache service and verifies the user status by querying the user information through the database service. After the verification passes, a token is generated, stored in the Redis cache service, and the validity period is set. A JWT token is constructed based on the user information and the JWT token is signed. The generated JWT token is returned to the front-end service, and the front-end service saves the JWT token in the browser;

[0014] The user initiates a business request to the gateway service through the front-end service. The business request carries the JWT token. The gateway service filters the business request, parses the JWT token, and performs token verification. After the verification passes, a business request is initiated to the business service. The business service processes the business request and returns business data to the front-end service. Among them, the gateway service places the verification code request and the login request in the white list and does not perform token verification.

[0015] Preferably, when the user initiates a verification code request to the authentication service through the front-end service, the user fills in the user information through the browser and triggers a click event through the browser. After the front-end service detects the click event triggered by the user, it sends a verification code request to the authentication service carrying the user information.

[0016] Preferably, based on the verification code request, the authentication service queries the user information from the database service and verifies the user status based on the user information. If the user status is abnormal, the verification code acquisition is rejected, and the rejection information is returned to the front-end service, and the current verification code request ends. If the user status is normal, the user status verification passes.

[0017] Preferably, after the user status is verified, the authentication service retrieves the user's SMS sending count from the Redis cache service. If the user's SMS sending count cannot be retrieved, it means the user has not performed any SMS sending operations. In this case, the user's SMS sending count in the Redis cache service is initialized to 0. If the user's SMS sending count exists in the Redis cache, the count is read and compared with the preset upper limit. If the user's SMS sending count is higher than the upper limit, the user is locked, and a rejection message is returned to the front-end service, ending the current verification code request. If the user's SMS sending count is lower than the upper limit, it is checked whether there is corresponding user sending information in the Redis cache service. If there is no corresponding user sending information, a verification code is generated using the Random generation method, and the SMS service is called to send the verification code to the user. The verification code, user information, and the sending time of the verification code sent through the SMS service are stored in the Redis cache service, and the validity period of the verification code is set. The SMS sending count in the Redis cache is updated. If there is corresponding user sending information, the SMS service is called to send the verification code to the user. After sending, the validity period of the verification code is set, and the SMS sending count in the Redis cache is updated.

[0018] Preferably, based on the login request, the authentication service verifies the verification code through the Redis cache service. If the verification fails, an exception message is returned to the front-end service. If the verification passes, the user information is queried from the database and compared with the user information in the login request for verification. If the verification passes, a random uuid is generated as a token, and the token is stored in the Redis cache service. The validity period of the token is set, and a set is created to store the JWT claims for the user. Multiple key-value pairs are added to the set. The key-value pairs represent the user's information, including the token, user ID, username, and user source. The JWT token is constructed using Jwts.builder(), the claims set is set to the JWT token through the setClaims(claims) method, and the JWT token is signed using the signature algorithm. The signed JWT token is compressed into a string, the user's login log is recorded, and the generated JWT token is returned to the front-end service. The front-end service saves the JWT token in the browser and logs in to the business system.

[0019] Preferably, the signature algorithm is HMAC with SHA-512.

[0020] Preferably, after receiving a service request initiated by a user through a front-end service, the gateway service filters the request. The gateway service obtains the ServerHttpRequest object of the current service request from the ServerWebExchange, and checks whether the URL path of the service request matches the configured whitelist. If it matches, the service request is not token-validated, and the service request is passed to the next filter or processor. The gateway service extracts the JWT token from the Header or Query parameters of the service request. If the JWT token prefix exists, the prefix is removed. If there is no token in the Header, an attempt is made to obtain it from the Query parameters. The JWT token is parsed, and its claim set is obtained. It is determined whether the obtained claim set is the same as the created set. If the JWT token is empty, the parsing fails, or the claim is empty, a token expiration or incorrect verification is returned to the front-end service. After the token is successfully parsed, it is checked whether the Redis cache service stores the user login information related to the token. If the user is not logged in or the login status has expired, a login status expiration is returned to the front-end service. The user ID and username are extracted from the obtained token claims. If the user ID and username are empty, a token verification failure is returned to the front-end service. The parsed user information is added to the Header of the request, a new ServerWebExchange object is constructed using the modified service request, and the filter method is called to continue processing the service request. After the service request is processed in the processing chain of the gateway service, it reaches the business service. The business service returns corresponding business data to the front-end service according to the service request initiated by the user through the front-end service, and then the current service request is completed.

[0021] In a second aspect, a Redis-based system authentication device of the present invention includes a browser and a backend. The browser provides a front-end service, and the backend provides a gateway service, an authentication service, a business service, a database service, a Redis cache service, and a short message service. The browser and the backend cooperate to execute a Redis-based system authentication method according to any one of the first aspects to implement user login authentication.

[0022] The Redis-based system authentication method and device of the present invention have the following advantages:

[0023] 1. Through Redis and JWT technologies, the encryption and verification of the user login status are realized, effectively preventing malicious attacks and illegal access, and enhancing security;

[0024] 2. Through the parsing and verification of the JWT token, access control of user requests is realized, ensuring the security of the business system;

[0025] 3. The Redis cache service ensures the consistency of data such as user verification codes and login status, avoiding data synchronization problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0027] The present invention is further described below in conjunction with the accompanying drawings.

[0028] Figure 1 This is a flowchart of a Redis-based system authentication method in Example 1. DETAILED DESCRIPTION

[0029] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it. However, the embodiments are not intended to limit the present invention. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments may be combined with each other.

[0030] The embodiments of the present invention provide a system authentication method and system based on Redis, which are used to solve the technical problem of how to provide an authentication method for users to ensure that users can use system functions normally.

[0031] Embodiment 1:

[0032] The present invention provides a system authentication method based on Redis, which implements user login authentication based on the front-end service provided by the browser and the gateway service, authentication service, business service, database service, Redis cache service and SMS service provided by the back-end. The method comprises the following steps:

[0033] Step S100: The user initiates a request to obtain a verification code from the authentication service through the front-end service;

[0034] Step S200: Based on the verification code acquisition request, the authentication service queries the user information from the database service, and performs user status verification based on the user information;

[0035] Step S300: After the user status verification is passed, the authentication service obtains the number of SMS messages sent by the user from the Redis cache service and verifies the number of SMS messages sent. After the number of SMS messages sent is verified, a verification code is generated and sent to the user through the SMS service. The verification code, user information, and the time when the verification code is sent through the SMS service are stored in the Redis service, the validity period of the verification code is set, and the number of SMS messages sent in the Redis cache is updated.

[0036] Step S400: After receiving the verification code, the user initiates a login request to the authentication service through the front-end service, and the login request carries the user information and the verification code;

[0037] Step S500: Based on the login request, the authentication service verifies the verification code through the Redis cache service, and verifies the user status through the database service to query the user information. After the verification is passed, a token is generated, and the token is stored in the Redis cache service and the validity period is set. A JWT token is constructed based on the user information and signed, and the generated JWT token is returned to the front-end service, and the front-end service saves the JWT token in the browser;

[0038] Step S600, the user initiates a business request to the gateway service through the front-end service. The business request carries a JWT token. The gateway service filters the business request, parses the JWT token and performs token verification. After the verification is passed, a business request is initiated to the business service. The business service processes the business request and returns business data to the front-end service. Among them, the gateway service puts the verification code request and login request in the whitelist and does not perform token verification.

[0039] As a specific implementation of step S100, when the user initiates a request to obtain a verification code to the authentication service through the front-end service, the user fills in the user information through the browser and triggers a click event through the browser. After the front-end service monitors the click event triggered by the user, it sends a request to obtain a verification code to the authentication service with the user information.

[0040] As a specific implementation of step S200, based on the request to obtain the verification code, the authentication service queries the user information from the database service, and verifies the user status based on the user information. If the user status is abnormal, the verification code is refused, and the rejection information is returned to the front-end service. The request to obtain the verification code ends. If the user status is normal, the user status verification is passed.

[0041] As a specific implementation of step S300, after the user status verification is passed, the authentication service obtains the user's SMS sending times from the Redis cache service. If the user's SMS sending times cannot be obtained, it means that the user has not performed the SMS sending operation. The user's SMS sending times in the Redis cache service are initialized to 0 times. If the user's SMS sending times exist in the Redis cache, the user's SMS sending times are read and compared with the preset upper limit times. If the user's SMS sending times are higher than the upper limit times, the user is locked, and a rejection message is returned to the front-end service, and this verification code request ends. If the user's SMS sending times are lower than the upper limit times, it is judged whether there is corresponding user sending information in the Redis cache service. If there is no corresponding user sending information, a verification code is generated by the Random generation method, and the SMS service is called to send the verification code to the user. The verification code, user information, and the sending time of sending the verification code through the SMS service are stored in the Redis cache service, and the validity period of the verification code is set, and the SMS sending times in the Redis cache are updated. If there is corresponding user sending information, the SMS service is called to send the verification code to the user. After the sending is completed, the validity period of the verification code is set, and the SMS sending times in the Redis cache are updated.

[0042] As a specific implementation of step S500, based on the login request, the authentication service verifies the verification code through the Redis cache service. If the verification fails, an exception message is returned to the front-end service. If the verification passes, the user information is queried from the database and compared with the user information in the login request for verification. If the verification passes, a random uuid is generated as a token, and the token is stored in the Redis cache service, and the validity period of the token is set. A set user is created to store the claims of the JWT, and multiple key-value pairs are added to the set. The key-value pairs represent the user's information, including the token, user ID, user name, and user source. The JWT token is constructed through Jwts.builder(), the claims set is set into the JWT token through the setClaims(claims) method, and the JWT token is signed through the signature algorithm. The signed JWT token is compressed into a string, the user's login log is recorded, and the generated JWT token is returned to the front-end service. The front-end service saves the JWT token in the browser and logs in to the business system.

[0043] As a specific implementation of step S600, after the gateway service receives a service request initiated by the user through the front-end service, it filters the request. The gateway service obtains the ServerHttpRequest object of the current service request from the ServerWebExchange, and checks whether the URL path of the service request matches the configured whitelist. If it matches, the service request is not token-validated, and the service request is passed to the next filter or processor. The gateway service extracts the JWT token from the Header or Query parameters of the service request. If the JWT token prefix exists, the prefix is removed. If there is no token in the Header, it tries to obtain it from the Query parameters, parses the JWT token, and obtains its claim set. It determines whether the obtained claim set is the same as the created set. If the JWT token is empty, the parsing fails, or the claim is empty, it returns to the front-end service that the token has expired or the verification is incorrect. After the token is successfully parsed, it checks whether the user login information related to the token is stored in the Redis cache service. If the user is not logged in or the login status has expired, it returns to the front-end service that the login status has expired. It extracts the user ID and user name from the obtained token claims. If the user ID and user name are empty, it returns to the front-end service that the token verification fails. It adds the parsed user information to the Header of the request, constructs a new ServerWebExchange object using the modified service request, and calls the filter method to continue processing the service request. After the service request is processed in the processing chain of the gateway service, it reaches the business service. The business service returns the corresponding business data to the front-end service according to the service request initiated by the user through the front-end service, and then this service request is completed.

[0044] Based on the above steps, the specific operations of the method in this embodiment are given:

[0045] Prerequisite: The gateway service places the verification code request and login request in the white list, and the gateway service does not perform token verification when the front-end service initiates the above requests.

[0046] (1) The user fills in personal login information in the browser and clicks to obtain the verification code after filling.

[0047] (2) After the front-end service detects the click event generated by the user, it sends a verification code request to the authentication service carrying the user information in step 1.

[0048] (3) After the authentication service receives the verification code request, it requests the database service to obtain the user information data.

[0049] (4) Verify the user information. If the status information is abnormal, directly reject the request for the verification code and return the rejection information to the front-end service, and this request ends. If the status is normal, the information verification passes and subsequent operations are performed.

[0050] (5) If the user status in step (4) is normal, obtain the user's SMS sending times from the Redis cache service. If the times cannot be obtained, it means the user has not performed any SMS sending operations. At this time, initialize the SMS sending times to 0 times. If there are already SMS sending times, retrieve the data.

[0051] (6) Compare the times in step 5 with the configured upper limit times. If it is higher than the upper limit times, lock the user and return the rejection information to the front-end service, and this request ends. If it is lower than the upper limit times, perform step 7 operation.

[0052] (7) Obtain whether there is any existing sending information of this user in the cache service. If not, execute steps 8 - 10; otherwise, execute steps 11 - 12.

[0053] (8) If there is no existing sending information, use the random generation method of Random to generate a 6-digit verification code.

[0054] (9) Call the SMS sending service to send the verification code generated in step 8 to the user.

[0055] (10) Store the verification code in step 8, the user information, and the sending time in step 9 as the sending information in the cache service, and set the validity period to 10 minutes. And increase the record of the user's sending times by one in the cache service.

[0056] (11) If there is existing sending information, call the SMS sending service to send the verification code in the sending information to the user.

[0057] (12) After sending is completed, refresh the validity period of the sending information to 10 minutes, and increase the record of the user's sending times by one in the cache service.

[0058] (13) After executing steps 8 - 10 or steps 11 - 12, return a successful sending message to the front-end service.

[0059] (14) After the user receives the verification code, fill it in the browser and click Login.

[0060] (15) The front-end service sends a login request with the user information and the verification code to the authentication service. After receiving the request, the authentication service verifies the verification code through the Redis cache. If the verification fails, directly return the exception information to the front-end service.

[0061] (16) After successful verification, query the user information again through the database service and execute step 4 again.

[0062] (17) Generate a random uuid as a token, store this token in the Redis cache service, and set an expiration time.

[0063] (18) Create a set to store the claims of the JWT. Add multiple key-value pairs to the set, and these key-value pairs represent user information, including user token (USER_KEY), user ID (DETAILS_USER_ID), user name (DETAILS_USERNAME), source (SOURCE), etc.

[0064] (19) Use Jwts.builder() to start building the JWT token. Set the claim set into the JWT token through the setClaims(claims) method, then sign the JWT token (the signature algorithm is HMAC with SHA-512), and finally compress the JWT token into a string.

[0065] (20) Record the user's login log.

[0066] (21) Return the generated token to the front-end service, and the front-end service saves it in the browser and logs in to the business system.

[0067] (22) When the front-end service makes a normal business data request, the request reaches the gateway service, and the gateway service performs HTTP request filtering.

[0068] (23) The gateway service obtains the ServerHttpRequest object of the current request from the ServerWebExchange. And check whether the URL path of the request matches the configured whitelist. If it matches, do not perform token verification on this request and pass the request to the next filter or processor. Normal business requests are not in this whitelist, and continue to execute the subsequent steps.

[0069] (24) The gateway service extracts the JWT token from the request's Header or Query parameters. If the token prefix exists, remove the prefix. If there is no token in the Header, try to obtain it from the Query parameters.

[0070] (25) Parse the token and obtain its claim (Claims) set, which is the same as the set in step 18. If the token is empty, the parsing fails, or the claims are empty, return "The token has expired or the verification is incorrect" to the front-end service.

[0071] After successful parsing, check whether the Redis cache service stores user login information related to the token. If the user is not logged in or the login status has expired, return "Login status has expired" to the front-end service.

[0072] (27) Extract the user ID and user name from the token claims obtained in step 25. If this information is empty, return token verification failure to the front-end service.

[0073] (28) Add the parsed user information to the request header so that subsequent processing flows can use this information.

[0074] (29) Use the modified request to construct a new ServerWebExchange object and call the filter method to continue processing the request.

[0075] (30) After the request is processed in the processing chain of the gateway service and reaches the business service, if the business service returns the corresponding data to the front-end service according to the request information in step 22, then this request is completed.

[0076] The method of this embodiment is based on Redis and JWT technologies. After the user clicks to obtain the verification code in the browser, the front-end service sends a request to obtain the verification code to the back-end. After receiving the request, the back-end service verifies the user status. If the verification passes, it calls the SMS sending service to send the SMS to the user's mobile phone. After the user receives it, fills in the verification code and clicks to log in. At this time, the front-end service sends a login request to the back-end service with the verification information. After receiving the request, the back-end service verifies the information. After the verification passes, it generates a token and returns it to the front-end service. The front-end service saves the received token and carries this token when making subsequent function requests. The gateway service verifies the token. If the verification passes, it responds to the request.

[0077] Embodiment 2:

[0078] A system authentication device based on Redis according to the present invention includes a browser and a back-end. The browser provides a front-end service, and the back-end provides a gateway service, an authentication service, a business service, a database service, a Redis cache service, and an SMS service. The browser and the back-end cooperate to execute the method disclosed in Embodiment 1 to implement user login authentication.

[0079] The above has introduced in detail the Redis-based system authentication device provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation on the present invention.

Claims

1. A system authentication method based on Redis, characterized in that: The method implements user login authentication based on the front-end service provided by the browser and the gateway service, authentication service, business service, database service, Redis cache service and SMS service provided by the back-end, and comprises the following steps: The user initiates a request to obtain a verification code from the authentication service through the front-end service; Based on the verification code request, the authentication service queries the user information from the database service and verifies the user status based on the user information; After the user status is verified, the authentication service obtains the number of SMS messages sent by the user from the Redis cache service and verifies the number of SMS messages sent. After the number of SMS messages is verified, a verification code is generated and sent to the user through the SMS service. The verification code, user information, and the time when the verification code is sent through the SMS service are stored in the Redis service, the validity period of the verification code is set, and the number of SMS messages sent in the Redis cache is updated; After receiving the verification code, the user initiates a login request to the authentication service through the front-end service. The login request carries the user information and the verification code. Based on the login request, the authentication service verifies the verification code through the Redis cache service, and verifies the user status by querying the user information through the database service. After the verification is passed, a token is generated, and the token is stored in the Redis cache service and the validity period is set. A JWT token is constructed based on the user information and signed, and the generated JWT token is returned to the front-end service, which saves the JWT token in the browser. The user initiates a business request to the gateway service through the front-end service. The business request carries the JWT token. The gateway service filters the business request, parses the JWT token and performs token verification. After the verification is passed, the business request is initiated to the business service. The business service processes the business request and returns the business data to the front-end service. Among them, the gateway service puts the verification code request and login request in the whitelist without performing token verification.

2. The Redis-based system authentication method according to claim 1, characterized in that: When a user initiates a request to obtain a verification code from the authentication service through the front-end service, the user fills in the user information through the browser and triggers a click event through the browser. After the front-end service monitors the click event triggered by the user, it sends a request to obtain a verification code to the authentication service with the user information.

3. The Redis-based system authentication method according to claim 1, characterized in that: Based on the request to obtain the verification code, the authentication service queries the user information from the database service and verifies the user status based on the user information. If the user status is abnormal, the verification code is rejected and the rejection information is returned to the front-end service. The request to obtain the verification code ends. If the user status is normal, the user status verification is passed.

4. The Redis-based system authentication method according to claim 1, characterized in that: After the user status verification is passed, the authentication service obtains the number of times the user has sent SMS messages from the Redis cache service. If the number of times the user has not been obtained, it means that the user has not performed the SMS sending operation. The number of times the user has sent SMS messages in the Redis cache service is initialized to 0. If the number of times the user has sent SMS messages exists in the Redis cache, the number of times the user has sent SMS messages is read, and the number of times the user has sent SMS messages read is compared with the preset upper limit. If the number of times the user has sent SMS messages is higher than the upper limit, the user is locked, and a rejection message is returned to the front-end service. This request to obtain the verification code ends. If the number of times the user has sent SMS messages is lower than the upper limit, it is determined whether there is sending information of the corresponding user in the Redis cache service. If there is no sending information of the corresponding user, a verification code is generated through the Random generation method, and the SMS service is called to send the verification code to the user. The verification code, user information, and the sending time of the verification code sent through the SMS service are stored in the Redis cache service, and the validity period of the verification code is set. The number of times the SMS has been sent in the Redis cache is updated. If there is sending information of the corresponding user, the SMS service is called to send the verification code to the user. After the sending is completed, the validity period of the verification code is set, and the number of times the SMS has been sent in the Redis cache is updated.

5. The Redis-based system authentication method according to claim 1, characterized in that: Based on the login request, the authentication service verifies the verification code through the Redis cache service. If the verification fails, an exception message is returned to the front-end service. If the verification passes, the user information is queried through the database and compared with the user information in the login request. If the verification passes, a random uuid is generated as a token, and the token is stored in the Redis cache service. The validity period of the token is set, and a collection user is created to store the JWT declaration. Multiple key-value pairs are added to the collection. The key-value pairs represent the user's information, including token, user ID, user name, and user source. The JWT token is constructed through Jwts.builder(), and the claim collection is set to the JWT token through the setClaims(claims) method. The JWT token is signed through the signature algorithm, and the signed JWT token is compressed into a string. The user's login log is recorded and the generated JWT token is returned to the front-end service. The front-end service saves the JWT token in the browser and logs in to the business system.

6. The Redis-based system authentication method according to claim 1, characterized in that: The signature algorithm is HMACwith SHA-512.

7. The Redis-based system authentication method according to claim 5, characterized in that: After the gateway service receives the business request initiated by the user through the front-end service, it filters the request. The gateway service obtains the ServerHttpRequest object of the current business request from ServerWebExchange and checks whether the URL path of the business request matches the configured whitelist. If it matches, the business request is not validated for token and the business request is passed to the next filter or processor. The gateway service extracts the JWT token from the Header or Query parameter of the business request. If the JWT token prefix exists, the prefix is ​​removed. If there is no token in the Header, it tries to obtain it from the Query parameter, parses the JWT token, and obtains its claim set to determine whether the obtained claim set is the same as the created set. If the JWT token is empty, parsing fails, or the claim is empty, it returns Return to the front-end service that the token has expired or the verification is incorrect. After the token is parsed successfully, check whether the user login information related to the token is stored in the Redis cache service. If the user is not logged in or the login status has expired, return to the front-end service that the login status has expired, extract the user id and user name from the obtained token declaration, if the user id and user name are empty, return to the front-end service that the token verification failed, add the parsed user information to the request Header, use the modified business request to build a new ServerWebExchange object, and call the filter method to continue processing the business request. After the business request is processed in the processing chain of the gateway service, it reaches the business service. The business service returns the corresponding business data to the front-end service based on the business request initiated by the user through the front-end service, and this business request is completed.

8. A system authentication device based on Redis, characterized in that: It includes a browser and a backend, the browser provides front-end services, the backend provides gateway services, authentication services, business services, database services, Redis cache services and SMS services, and the browser and the backend cooperate to execute a Redis-based system authentication method as described in any one of claims 1-7 to realize user login authentication.

Images