CN110730171A - Service request processing method, device and system, electronic equipment and storage medium - Google Patents
Service request processing method, device and system, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN110730171A CN110730171A CN201910959090.XA CN201910959090A CN110730171A CN 110730171 A CN110730171 A CN 110730171A CN 201910959090 A CN201910959090 A CN 201910959090A CN 110730171 A CN110730171 A CN 110730171A
- Authority
- CN
- China
- Prior art keywords
- service request
- token
- login
- verification result
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
Abstract
The application provides a service request processing method and device, electronic equipment and a computer readable storage medium, and relates to the field of information processing. The method comprises the following steps: when a service request initiated by a terminal is received, extracting an original token from the service request; matching the original token with any target token in a preset cache; when the matched target token does not exist, sending matching failure information to the terminal so that the terminal can display a preset login page, wherein the login page is used for receiving user information and a login instruction input by a user, generating a login request based on the user information and the login instruction, and sending the login request to a preset main system so that the main system can verify the user information in the login request, generate a verification result and send the verification result to the subsystem; and when the received verification result is successful, performing corresponding service processing on the service request. The method and the device not only improve the efficiency of business processing, but also improve the user experience.
Description
Technical Field
The present application relates to the field of information processing technologies, and in particular, to a method and an apparatus for processing a service request, an electronic device, and a computer-readable storage medium.
Background
With the continuous development of the internet, the internet technology is also promoted correspondingly. Once used, business systems and programs for large enterprises are constantly evolving towards a civilization process.
In particular, with the competition and cooperation of large platforms, such as WeChat small program platforms, 360 small program platforms, etc., the number of systems owned by enterprises is also increasing at double. Under such a huge market, many small and medium-sized companies which want to be the main platform constantly improve their own systems at a higher speed and with better quality in order to obtain more users as much as possible in the initial stage of startup, so that the stability of the system can be maintained at the same time under the condition of increasing traffic, and the problem of user identity authentication is the first ring of problems to be solved for all the time no matter what platform is used.
At present, the main mode for login in the market is that a front end, such as a mobile end or a PC end, initiates a service request to a back end, such as a server end, and when the request is successful, a token returned by the back end is obtained. Thus, each request from the front-end requires the back-end system to hold the current token to find the authorization server for authentication. However, the disadvantages of this approach are: each authentication request needs to take the token to access the authorization server, and if the authorization server has a problem, all systems on the mobile end and the PC end are crashed, which is disastrous for the platform.
Or, by using a token issuing mechanism of JWT (JSON Web token), a token is issued when a user logs in, and then a Header part is put in and returned to the user, so that all subsequent requests of the user carry the token. However, this method also has the following drawbacks: in a token issuing mechanism of JWT, a token carries an expiration time when it is generated, and when the expiration time of the token is over, the token is invalid, and a user needs to log in again when initiating a service request, which not only has low efficiency of service processing, but also has poor user experience.
Disclosure of Invention
The application provides a method and a device for processing a service request, electronic equipment and a computer-readable storage medium, which can solve the problems that in the prior art, the service time of a token is the fixed time carried by the token during generation and cannot be prolonged, and each request authentication needs to take the token to access an authorization server. The technical scheme is as follows:
in a first aspect, a method for processing a service request is provided, where the method includes:
when a service request initiated by a terminal is received, extracting an original token from the service request;
matching the original token with any target token in a preset cache;
when no matched target token exists, sending matching failure information to the terminal, so that after the terminal receives the matching failure information, a preset login page is displayed, wherein the login page is used for receiving user information and a login instruction input by a user, generating a login request based on the user information and the login instruction, and sending the login request to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
and when the received verification result is that the verification is successful, performing corresponding service processing on the service request.
Preferably, the method further comprises the following steps:
and when the matched target token exists, performing corresponding service processing on the service request, and refreshing the preset effective time of the target token.
Preferably, the method further comprises the following steps:
and when the received verification result is verification failure, suspending the service request until the received verification result is verification success or the service request is overdue, and discarding the service request.
Preferably, the step of extracting the original token from the service request includes:
extracting the original token from a Header and/or a Cookie of the service request;
a manner in which there is no matching target token, comprising:
the original token extracted from the Header of the service request is not matched with any target token in the preset cache, and the original token extracted from the Cookie of the service request is not matched with any target token in the preset cache.
Preferably, before generating the verification result and sending the verification result to the subsystem, the method further includes:
when the verification result is that the verification is successful, generating a target token of a JWT standard based on the user information and storing the target token into the preset cache;
and generating response information, writing the target token into a Header and a Cookie of the response information, and sending the response information to the terminal.
Preferably, the method further comprises the following steps:
and when any target token fails to be matched with any original token within the valid time, deleting the target token from the preset cache.
In a second aspect, a system for processing a service request is provided, the system comprising:
when a subsystem receives a service request initiated by a terminal, extracting an original token from the service request;
the subsystem matches the original token with any target token in a preset cache;
when no matched target token exists, the subsystem sends matching failure information to the terminal;
when the terminal receives the matching failure information, displaying a preset login page, wherein the login page is used for receiving user information and a login instruction input by a user;
the terminal generates a login request based on the user information and the login instruction, and sends the login request to a preset main system;
the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request.
In a third aspect, an apparatus for processing a service request is provided, where the apparatus includes:
the receiving module is used for receiving a service request initiated by a terminal;
the extracting module is used for extracting an original token from the service request;
the matching module is used for matching the original token with any target token in a preset cache;
the sending module is used for sending matching failure information to the terminal when no matching target token exists, so that the terminal displays a preset login page after receiving the matching failure information, the login page is used for receiving user information and a login instruction input by a user, generating a login request based on the user information and the login instruction, and sending the login request to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
and the processing module is used for carrying out corresponding service processing on the service request when the received verification result is that the verification is successful.
Preferably, the method further comprises the following steps:
the processing module is further configured to perform corresponding service processing on the service request when the matched target token exists;
and the refreshing module is used for refreshing the preset effective time of the target token.
Preferably, the method further comprises the following steps:
the suspension module is used for suspending the service request when the received verification result is verification failure until the received verification result is verification success;
and the discarding module is used for suspending the service request until the service request is overdue when the received verification result is verification failure, and discarding the service request.
Preferably, the extraction module is specifically configured to:
extracting the original token from a Header and/or a Cookie of the service request;
a manner in which there is no matching target token, comprising:
the original token extracted from the Header of the service request is not matched with any target token in the preset cache, and the original token extracted from the Cookie of the service request is not matched with any target token in the preset cache.
Preferably, before generating the verification result and sending the verification result to the subsystem, the method further includes:
when the verification result is that the verification is successful, generating a target token of a JWT standard based on the user information and storing the target token into the preset cache;
and generating response information, writing the target token into a Header and a Cookie of the response information, and sending the response information to the terminal.
Preferably, the method further comprises the following steps:
and the deleting module is used for deleting the target token from the preset cache when any target token fails to be matched with any original token within the valid time.
In a fourth aspect, an electronic device is provided, which includes:
a processor, a memory, and a bus;
the bus is used for connecting the processor and the memory;
the memory is used for storing operation instructions;
the processor is configured to invoke the operation instruction, and the executable instruction enables the processor to execute an operation corresponding to the method for processing the service request shown in the first aspect of the present application.
In a fifth aspect, a computer-readable storage medium is provided, on which a computer program is stored, which when executed by a processor, implements the method for processing a service request as shown in the first aspect of the present application.
The beneficial effect that technical scheme that this application provided brought is:
in the embodiment of the invention, when a subsystem receives a service request initiated by a terminal, an original token is extracted from the service request, then the original token is matched with any target token in a preset cache, when no matched target token exists, matching failure information is sent to the terminal, so that the terminal displays a preset login page after receiving the matching failure information, the login page is used for receiving user information and a login instruction input by a user, a login request is generated based on the user information and the login instruction, and the login request is sent to a preset main system, so that the main system verifies the user information in the login request, a verification result is generated, and the verification result is sent to the subsystem; and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request. Therefore, by setting the cache and setting the valid time for the token in the cache, the service time of the token is prolonged, and the main system is not required to verify each service request, so that the problems that in the prior art, the service time of the token is the fixed time of the token itself during generation and cannot be prolonged, and the problem that the token is required to be taken to access the authorization server during each request authentication are solved, so that after the fixed time, the user can still perform service processing under the condition of not performing identity verification, the service processing efficiency is improved, and the user experience is also improved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the description of the embodiments of the present application will be briefly described below.
Fig. 1 is a schematic flowchart of a method for processing a service request according to an embodiment of the present application;
fig. 2 is a schematic flowchart of a method for processing a service request according to another embodiment of the present application;
fig. 3 is an interaction diagram of a service request processing system according to another embodiment of the present application;
fig. 4 is a schematic structural diagram of a service request processing apparatus according to yet another embodiment of the present application;
fig. 5 is a schematic structural diagram of an electronic device for processing a service request according to yet another embodiment of the present application.
Detailed Description
Reference will now be made in detail to embodiments of the present application, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are exemplary only for the purpose of explaining the present application and are not to be construed as limiting the present invention.
As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. As used herein, the term "and/or" includes all or any element and all combinations of one or more of the associated listed items.
To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
The application provides a service request processing method, a service request processing device, an electronic device and a computer-readable storage medium, which aim to solve the above technical problems in the prior art.
The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
In one embodiment, a method for processing a service request is provided, as shown in fig. 1, the method is applied to a subsystem, and includes:
step S101, when receiving a service request initiated by a terminal, extracting an original token from the service request;
the subsystem may be a service processing system, a management system, or other systems, and may be configured to perform corresponding service processing for a service request of a user. In practical application, one subsystem may be configured to process multiple types of services, or multiple subsystems may be configured to process different types of services, respectively.
Step S102, matching the original token with any target token in a preset cache;
specifically, the preset cache may store a plurality of target tokens, or tokens of the JWT standard. After the subsystem extracts the original token from the service request, the original token can be matched with each target token in the pre-stored token to determine whether a matching item exists. If the matching item exists, the identity of the user is legal, the subsystem can perform corresponding service processing on the service request of the user, if the matching item does not exist, the identity of the user is illegal, the subsystem cannot perform corresponding service processing on the service request of the user, and meanwhile, the user needs to perform identity authentication.
Step S103, when no matched target token exists, sending matching failure information to the terminal, so that after the terminal receives the matching failure information, displaying a preset login page, wherein the login page is used for receiving user information and a login instruction input by a user, generating a login request based on the user information and the login instruction, and sending the login request to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
and step S104, when the received verification result is successful, performing corresponding service processing on the service request.
The valid time is the storable time of the target token in the cache. In the embodiment of the invention, if the target token matched with the original token exists in the cache, the valid time of the target token can be refreshed, and corresponding service processing is carried out on the service request.
In the embodiment of the invention, when a subsystem receives a service request initiated by a terminal, an original token is extracted from the service request, then the original token is matched with any target token in a preset cache, when the matched target token does not exist, matching failure information is sent to the terminal, so that after the terminal receives the matching failure information, a preset login page is displayed, the login page is used for receiving user information and a login instruction input by a user and generating a login request based on the user information and the login instruction, and the login request is sent to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem; and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request. Therefore, by setting the cache and setting the valid time for the token in the cache, the service time of the token is prolonged, and the main system is not required to verify each service request, so that the problems that in the prior art, the service time of the token is the fixed time of the token itself during generation and cannot be prolonged, and the problem that the token is required to be taken to access the authorization server during each request authentication are solved, so that after the fixed time, the user can still perform service processing under the condition of not performing identity verification, the service processing efficiency is improved, and the user experience is also improved.
In one embodiment, a method for processing a service request is provided, as shown in fig. 2, the method is applied to a subsystem, and includes:
step S201, when receiving a service request initiated by a terminal, extracting an original token from the service request;
the subsystem may be a service processing system, a management system, or other systems, and may be configured to perform corresponding service processing for a service request of a user. In practical application, one subsystem may be configured to process multiple types of services, or multiple subsystems may be configured to process different types of services, respectively. For convenience of description, the present application only takes an example that one system processes one type of service as an example for illustration, and other situations are the same as the principle, and the present application is not repeated.
The token is also called token, and generally speaking, token is generated at the back end, if the front end requests authentication from the server end by using a user name/password, and the back end succeeds in authentication, the back end returns token to the front end, and the front end can bring token to prove its legal status at each request. The front end may be a terminal device of a user, the user may install an application client on the terminal device, and initiate a service request in the application client, and the terminal device may have the following characteristics:
(1) on a hardware architecture, a device has a central processing unit, a memory, an input unit and an output unit, that is, the device is often a microcomputer device having a communication function. In addition, various input modes such as a keyboard, a mouse, a touch screen, a microphone, a camera and the like can be provided, and input can be adjusted as required. Meanwhile, the equipment often has a plurality of output modes, such as a telephone receiver, a display screen and the like, and can be adjusted according to needs;
(2) on a software system, the device must have an operating system, such as Windows Mobile, Symbian, Palm, Android, iOS, and the like. Meanwhile, the operating systems are more and more open, and personalized application programs developed based on the open operating system platforms are infinite, such as a communication book, a schedule, a notebook, a calculator, various games and the like, so that the requirements of personalized users are met to a great extent;
(3) in terms of communication capacity, the device has flexible access mode and high-bandwidth communication performance, and can automatically adjust the selected communication mode according to the selected service and the environment, thereby being convenient for users to use. The device can support GSM (Global System for Mobile Communication), WCDMA (Wideband Code Division Multiple Access), CDMA2000(Code Division Multiple Access), TDSCDMA (Time Division-Synchronous Code Division Multiple Access), Wi-Fi (Wireless-Fidelity), WiMAX (world interoperability for Microwave Access), etc., thereby adapting to various systems of networks, not only supporting voice service, but also supporting various Wireless data services;
(4) in the aspect of function use, the equipment focuses more on humanization, individuation and multi-functionalization. With the development of computer technology, devices enter a human-centered mode from a device-centered mode, and the embedded computing, control technology, artificial intelligence technology, biometric authentication technology and the like are integrated, so that the human-oriented purpose is fully embodied. Due to the development of software technology, the equipment can be adjusted and set according to individual requirements, and is more personalized. Meanwhile, the device integrates a plurality of software and hardware, and the function is more and more powerful.
In a preferred embodiment of the present invention, the step of extracting the original token from the service request comprises:
the original token is extracted from the Header and/or Cookie of the service request.
Specifically, the terminal may send a service request to the subsystem by using an HTTP (Hyper text transfer Protocol) Protocol, where at least one of a Header and a Cookie in the service request may carry an original token corresponding to the user.
Further, the token in the embodiment of the present invention may be a token of jwt (json Web token) standard. Among them, JSON Web Token is an open standard (RFC 7519) that defines a compact, self-contained way to securely transfer information between parties as JSON objects.
Step S202, matching the original token with any target token in a preset cache;
specifically, the preset cache may store a plurality of target tokens, or tokens of the JWT standard. After the subsystem extracts the original token from the service request, the original token can be matched with each target token in the pre-stored token to determine whether a matching item exists. If the matching item exists, the identity of the user is legal, the subsystem can perform corresponding service processing on the service request of the user, if the matching item does not exist, the identity of the user is illegal, the subsystem cannot perform corresponding service processing on the service request of the user, and meanwhile, the user needs to perform identity authentication.
Step S203, when no matched target token exists, sending matching failure information to the terminal, so that after the terminal receives the matching failure information, displaying a preset login page, wherein the login page is used for receiving user information and a login instruction input by a user, generating a login request based on the user information and the login instruction, and sending the login request to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
in a preferred embodiment of the present invention, the way that there is no matching target token comprises:
the original token extracted from the Header of the service request is not matched with any target token in the preset cache, and the original token extracted from the Cookie of the service request is not matched with any target token in the preset cache.
Specifically, because the Header may include the original token, the Cookie may include the original token, or both of them may include the original token, the subsystem may extract the original token from either of them and have a matching target token. However, if the original token extracted by the subsystem from both does not match any of the target tokens, it can be determined that there is no target token matching the original token, i.e. the user identity is not legitimate.
At the moment, the terminal can send matching failure information to the terminal, and after the terminal receives the matching failure information, the preset login page can be displayed, so that the user can perform identity authentication again. The user can input identity information such as a user name and a password in the login page, when the user initiates a login instruction, the terminal can generate a login request according to the identity information and the common information of the user (the identity information and the common information of the user, namely the user information), send the login request to the main system for identity verification, extract the user information from the login request after the main system receives the login request, verify the user information, and send a verification result to the subsystem. Wherein the host system may be a single sign-on system for authenticating user information and, when authenticated, generating a token according to the JWT standard.
Step S204, when the matched target token exists, corresponding service processing is carried out on the service request, and the preset effective time of the target token is refreshed;
the valid time is the storable time of the target token in the cache. For example, if the valid time of a target token is 1 day, it indicates that the target token can be stored in the cache for 1 day. In the embodiment of the invention, if the target token matched with the original token exists in the cache, the valid time of the target token can be refreshed, and corresponding service processing is carried out on the service request.
Step S205, when the received verification result is that the verification is successful, corresponding service processing is carried out on the service request;
specifically, the subsystem may suspend the service request first, and perform corresponding service processing on the service request of the user when the subsystem receives that the verification result sent by the main system is successful.
Or, if there is no matching target token, the subsystem may also discard the service request of the user, and when the user passes the authentication, the user initiates a new service request again, and at this time, the original token in the new service request has the matching target token, and the subsystem may perform corresponding service processing on the new service request. In practical application, the adjustment may be performed according to practical requirements, which is not limited in the embodiment of the present invention.
Step S206, when the received verification result is verification failure, suspending the service request until the received verification result is verification success or until the service request is overdue, and discarding the service request.
Specifically, if the verification result received by the subsystem is verification failure, the subsystem may suspend the service request, and may perform corresponding service processing on the service request until the verification result received is verification success.
When the subsystem suspends the service request, the main system can prompt the user that the authentication fails after the authentication of the user information fails, so that the user can log in again until the login succeeds.
Of course, in order to prevent the subsystem from suspending the service request all the time due to the fact that the user always fails to log in or the user abandons the login, thereby wasting system resources and hardware resources, an expiration time, such as 10 minutes, may be set for the service request, and if the expiration time is reached, the user still fails to log in, the subsystem may discard the service request.
In a preferred embodiment of the present invention, before generating the verification result and sending the verification result to the subsystem, the method further includes:
when the verification result is that the verification is successful, generating a target token of a JWT standard based on the user information and storing the target token into a preset cache;
and generating response information, writing the target token into a Header and a Cookie of the response information, and sending the response information to the terminal.
Specifically, after the host system passes the verification of the user information, the target token of the JWT standard can be generated by using the user information and stored in a preset cache, meanwhile, response information is generated, the target token is written into the Header and the Cookie of the response information and then sent to the terminal, so that the terminal can obtain the token from the Header and the Cookie of the response information after receiving the response information, and the terminal can write the token into the Header and/or the Cookie of the service request as the original token when initiating the next service request.
Step S207, when any target token fails to match any original token within the valid time, deleting the target token from the preset cache.
Specifically, if any target token fails to match any original token within the valid time, it indicates that the user corresponding to the target token does not initiate any service request, and therefore, after the valid time of the target token is over, the target token is deleted from the cache, thereby reducing resource waste. For example, the valid time of the target token a 'corresponding to the user a is 24 hours, and the user a does not initiate any service request within 24 hours, and then after 24 hours, the target token a' is deleted from the cache.
If the user initiates any service request within the valid time of the target token, the valid time of the target token can be refreshed. For example, the valid time of the target token B 'corresponding to the user B is 24 hours, the current valid time is still 10 seconds, at this time, the user B initiates a certain service request, and then after the matching is successful, the valid time of the target token B' can be refreshed to 24 hours.
In the embodiment of the invention, when a subsystem receives a service request initiated by a terminal, an original token is extracted from the service request, then the original token is matched with any target token in a preset cache, when the matched target token does not exist, matching failure information is sent to the terminal, so that after the terminal receives the matching failure information, a preset login page is displayed, the login page is used for receiving user information and a login instruction input by a user and generating a login request based on the user information and the login instruction, and the login request is sent to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem; and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request. Therefore, by setting the cache and setting the valid time for the token in the cache, the service time of the token is prolonged, and the main system is not required to verify each service request, so that the problems that in the prior art, the service time of the token is the fixed time of the token itself during generation and cannot be prolonged, and the problem that the token is required to be taken to access the authorization server during each request authentication are solved, so that after the fixed time, the user can still perform service processing under the condition of not performing identity verification, the service processing efficiency is improved, and the user experience is also improved.
And when the target token in the cache is used once, the service time of the target token can be refreshed, the service time of the target token is dynamically prolonged, the service processing efficiency is further improved, and the user experience is improved.
In one embodiment, a system for processing a service request is provided, as shown in fig. 3, the system comprising:
step S301, when the subsystem receives a service request initiated by a terminal, extracting an original token from the service request;
step S302, the subsystem matches the original token with any target token in a preset cache;
step S303, when no matched target token exists, the subsystem sends matching failure information to the terminal;
step S304, when the terminal receives the matching failure information, displaying a preset login page, wherein the login page is used for receiving user information and a login instruction input by a user;
step S305, the terminal generates a login request based on the user information and the login instruction, and sends the login request to a preset main system;
step S306, the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
step S307, when the verification result received by the subsystem is successful, corresponding service processing is performed on the service request.
The service request processing system of this embodiment can execute the service request processing method shown in steps S101 to S104 and steps S201 to S207 of this application, and the implementation principles thereof are similar, and are not described herein again.
In the embodiment of the invention, when a subsystem receives a service request initiated by a terminal, an original token is extracted from the service request, then the original token is matched with any target token in a preset cache, when the matched target token does not exist, matching failure information is sent to the terminal, so that after the terminal receives the matching failure information, a preset login page is displayed, the login page is used for receiving user information and a login instruction input by a user and generating a login request based on the user information and the login instruction, and the login request is sent to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem; and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request. Therefore, by setting the cache and setting the valid time for the token in the cache, the service time of the token is prolonged, and the main system is not required to verify each service request, so that the problems that in the prior art, the service time of the token is the fixed time of the token itself during generation and cannot be prolonged, and the problem that the token is required to be taken to access the authorization server during each request authentication are solved, so that after the fixed time, the user can still perform service processing under the condition of not performing identity verification, the service processing efficiency is improved, and the user experience is also improved.
And when the target token in the cache is used once, the service time of the target token can be refreshed, the service time of the target token is dynamically prolonged, the service processing efficiency is further improved, and the user experience is improved.
Fig. 4 is a schematic structural diagram of a service request processing apparatus according to yet another embodiment of the present application, and as shown in fig. 4, the apparatus of this embodiment may include:
a receiving module 401, configured to receive a service request initiated by a terminal;
an extracting module 402, configured to extract an original token from the service request;
a matching module 403, configured to match the original token with any target token in a preset cache;
a sending module 404, configured to send matching failure information to the terminal when there is no matching target token, so that after receiving the matching failure information, the terminal displays a preset login page, where the login page is used to receive user information and a login instruction input by a user, and generates a login request based on the user information and the login instruction, and sends the login request to a preset host system, so that the host system verifies the user information in the login request, generates a verification result, and sends the verification result to the subsystem;
the processing module 405 is configured to perform corresponding service processing on the service request when the received verification result is that the verification is successful.
In a preferred embodiment of the present invention, the method further comprises:
the processing module is also used for carrying out corresponding service processing on the service request when the matched target token exists;
and the refreshing module is used for refreshing the preset effective time of the target token.
In a preferred embodiment of the present invention, the method further comprises:
the suspension module is used for suspending the service request when the received verification result is verification failure until the received verification result is verification success;
and the discarding module is used for suspending the service request until the service request is overdue when the received verification result is that the verification fails, and discarding the service request.
In a preferred embodiment of the present invention, the extraction module is specifically configured to:
extracting an original token from a Header and/or a Cookie of the service request;
a manner in which there is no matching target token, comprising:
the original token extracted from the Header of the service request is not matched with any target token in the preset cache, and the original token extracted from the Cookie of the service request is not matched with any target token in the preset cache.
In a preferred embodiment of the present invention, before generating the verification result and sending the verification result to the subsystem, the method further includes:
when the verification result is that the verification is successful, generating a target token of a JWT standard based on the user information and storing the target token into a preset cache;
and generating response information, writing the target token into a Header and a Cookie of the response information, and sending the response information to the terminal.
In a preferred embodiment of the present invention, the method further comprises:
and the deleting module is used for deleting the target token from the preset cache when any target token fails to be matched with any original token within the valid time.
The service request processing apparatus of this embodiment can execute the service request processing method shown in steps S101 to S104 and steps S201 to S207 of this application, and the implementation principles thereof are similar, and are not described herein again.
In the embodiment of the invention, when a subsystem receives a service request initiated by a terminal, an original token is extracted from the service request, then the original token is matched with any target token in a preset cache, when the matched target token does not exist, matching failure information is sent to the terminal, so that after the terminal receives the matching failure information, a preset login page is displayed, the login page is used for receiving user information and a login instruction input by a user and generating a login request based on the user information and the login instruction, and the login request is sent to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem; and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request. Therefore, by setting the cache and setting the valid time for the token in the cache, the service time of the token is prolonged, and the main system is not required to verify each service request, so that the problems that in the prior art, the service time of the token is the fixed time of the token itself during generation and cannot be prolonged, and the problem that the token is required to be taken to access the authorization server during each request authentication are solved, so that after the fixed time, the user can still perform service processing under the condition of not performing identity verification, the service processing efficiency is improved, and the user experience is also improved.
And when the target token in the cache is used once, the service time of the target token can be refreshed, the service time of the target token is dynamically prolonged, the service processing efficiency is further improved, and the user experience is improved.
In another embodiment of the present application, there is provided an electronic device including: a memory and a processor; at least one program stored in the memory for execution by the processor, which when executed by the processor, implements: in the embodiment of the invention, when a subsystem receives a service request initiated by a terminal, an original token is extracted from the service request, then the original token is matched with any target token in a preset cache, when no matched target token exists, matching failure information is sent to the terminal, so that the terminal displays a preset login page after receiving the matching failure information, the login page is used for receiving user information and a login instruction input by a user, a login request is generated based on the user information and the login instruction, and the login request is sent to a preset main system, so that the main system verifies the user information in the login request, a verification result is generated, and the verification result is sent to the subsystem; and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request. Therefore, by setting the cache and setting the valid time for the token in the cache, the service time of the token is prolonged, and the main system is not required to verify each service request, so that the problems that in the prior art, the service time of the token is the fixed time of the token itself during generation and cannot be prolonged, and the problem that the token is required to be taken to access the authorization server during each request authentication are solved, so that after the fixed time, the user can still perform service processing under the condition of not performing identity verification, the service processing efficiency is improved, and the user experience is also improved.
In an alternative embodiment, an electronic device is provided, as shown in fig. 5, the electronic device 5000 shown in fig. 5 includes: a processor 5001 and a memory 5003. The processor 5001 and the memory 5003 are coupled, such as via a bus 5002. Optionally, the electronic device 5000 may also include a transceiver 5004. It should be noted that the transceiver 5004 is not limited to one in practical application, and the structure of the electronic device 5000 is not limited to the embodiment of the present application.
The processor 5001 may be a CPU, general purpose processor, DSP, ASIC, FPGA or other programmable logic device, transistor logic device, hardware component, or any combination thereof. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. The processor 5001 may also be a combination of processors implementing computing functionality, e.g., a combination comprising one or more microprocessors, a combination of DSPs and microprocessors, or the like.
The memory 5003 may be, but is not limited to, a ROM or other type of static storage device that can store static information and instructions, a RAM or other type of dynamic storage device that can store information and instructions, an EEPROM, a CD-ROM or other optical disk storage, optical disk storage (including compact disk, laser disk, optical disk, digital versatile disk, blu-ray disk, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
The memory 5003 is used for storing application program codes for executing the present solution, and the execution is controlled by the processor 5001. The processor 5001 is configured to execute application program code stored in the memory 5003 to implement the teachings of any of the foregoing method embodiments.
Among them, electronic devices include but are not limited to: mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like.
Yet another embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, which, when run on a computer, enables the computer to perform the corresponding content in the aforementioned method embodiments. Compared with the prior art, in the embodiment of the invention, when a subsystem receives a service request initiated by a terminal, an original token is extracted from the service request, then the original token is matched with any target token in a preset cache, when no matched target token exists, matching failure information is sent to the terminal, so that after the terminal receives the matching failure information, a preset login page is displayed, the login page is used for receiving user information and a login instruction input by a user, a login request is generated based on the user information and the login instruction, and the login request is sent to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem; and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request. Therefore, by setting the cache and setting the valid time for the token in the cache, the service time of the token is prolonged, and the main system is not required to verify each service request, so that the problems that in the prior art, the service time of the token is the fixed time of the token itself during generation and cannot be prolonged, and the problem that the token is required to be taken to access the authorization server during each request authentication are solved, so that after the fixed time, the user can still perform service processing under the condition of not performing identity verification, the service processing efficiency is improved, and the user experience is also improved.
It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and may be performed in other orders unless explicitly stated herein. Moreover, at least a portion of the steps in the flow chart of the figure may include multiple sub-steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of other steps.
The foregoing is only a partial embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.
Claims (10)
1. A method for processing service request is applied to a subsystem, and comprises the following steps:
when a service request initiated by a terminal is received, extracting an original token from the service request;
matching the original token with any target token in a preset cache;
when no matched target token exists, sending matching failure information to the terminal, so that after the terminal receives the matching failure information, a preset login page is displayed, wherein the login page is used for receiving user information and a login instruction input by a user, generating a login request based on the user information and the login instruction, and sending the login request to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
and when the received verification result is that the verification is successful, performing corresponding service processing on the service request.
2. The method for processing service request according to claim 1, further comprising:
and when the matched target token exists, performing corresponding service processing on the service request, and refreshing the preset effective time of the target token.
3. The method for processing service request according to claim 1 or 2, further comprising:
and when the received verification result is verification failure, suspending the service request until the received verification result is verification success or the service request is overdue, and discarding the service request.
4. A method for processing a service request according to claim 1 or 2, wherein the step of extracting the original token from the service request comprises:
extracting the original token from a Header and/or a Cookie of the service request;
a manner in which there is no matching target token, comprising:
the original token extracted from the Header of the service request is not matched with any target token in the preset cache, and the original token extracted from the Cookie of the service request is not matched with any target token in the preset cache.
5. The method of claim 1, wherein before generating the verification result and sending the verification result to the subsystem, the method further comprises:
when the verification result is that the verification is successful, generating a target token of a JWT standard based on the user information and storing the target token into the preset cache;
and generating response information, writing the target token into a Header and a Cookie of the response information, and sending the response information to the terminal.
6. The method for processing service request according to claim 1, further comprising:
and when any target token fails to be matched with any original token within the valid time, deleting the target token from the preset cache.
7. A system for processing service requests, comprising:
when a subsystem receives a service request initiated by a terminal, extracting an original token from the service request;
the subsystem matches the original token with any target token in a preset cache;
when no matched target token exists, the subsystem sends matching failure information to the terminal;
when the terminal receives the matching failure information, displaying a preset login page, wherein the login page is used for receiving user information and a login instruction input by a user;
the terminal generates a login request based on the user information and the login instruction, and sends the login request to a preset main system;
the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
and when the verification result received by the subsystem is successful, performing corresponding service processing on the service request.
8. An apparatus for processing service requests, comprising:
the receiving module is used for receiving a service request initiated by a terminal;
the extracting module is used for extracting an original token from the service request;
the matching module is used for matching the original token with any target token in a preset cache;
the sending module is used for sending matching failure information to the terminal when no matching target token exists, so that the terminal displays a preset login page after receiving the matching failure information, the login page is used for receiving user information and a login instruction input by a user, generating a login request based on the user information and the login instruction, and sending the login request to a preset main system, so that the main system verifies the user information in the login request, generates a verification result and sends the verification result to the subsystem;
and the processing module is used for carrying out corresponding service processing on the service request when the received verification result is that the verification is successful.
9. An electronic device, comprising:
a processor, a memory, and a bus;
the bus is used for connecting the processor and the memory;
the memory is used for storing operation instructions;
the processor is configured to execute the method for processing the service request according to any one of claims 1 to 6 by calling the operation instruction.
10. A computer-readable storage medium for storing computer instructions which, when executed on a computer, cause the computer to perform the method of processing a service request of any of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910959090.XA CN110730171A (en) | 2019-10-10 | 2019-10-10 | Service request processing method, device and system, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910959090.XA CN110730171A (en) | 2019-10-10 | 2019-10-10 | Service request processing method, device and system, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110730171A true CN110730171A (en) | 2020-01-24 |
Family
ID=69219910
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910959090.XA Pending CN110730171A (en) | 2019-10-10 | 2019-10-10 | Service request processing method, device and system, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110730171A (en) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111447184A (en) * | 2020-03-09 | 2020-07-24 | 上海数据交易中心有限公司 | Single sign-on method, device, system and computer readable storage medium |
| CN111835793A (en) * | 2020-08-05 | 2020-10-27 | 天津美腾科技股份有限公司 | Communication method and device for Internet of things access, electronic equipment and storage medium |
| CN112199659A (en) * | 2020-12-03 | 2021-01-08 | 湖北亿咖通科技有限公司 | Access method, system and electronic device for multi-service platform of vehicle |
| CN112464201A (en) * | 2020-11-02 | 2021-03-09 | 中国建设银行股份有限公司 | Token automatic issuing system, method and storage medium |
| CN112910904A (en) * | 2021-02-03 | 2021-06-04 | 叮当快药科技集团有限公司 | Login method and device of multi-service system |
| CN113055186A (en) * | 2021-03-29 | 2021-06-29 | 建信金融科技有限责任公司 | Cross-system service processing method, device and system |
| CN114327956A (en) * | 2021-12-28 | 2022-04-12 | 阿波罗智联(北京)科技有限公司 | Request processing method and device for vehicle-mounted application, electronic equipment and storage medium |
| CN115001808A (en) * | 2022-05-31 | 2022-09-02 | 中国银行股份有限公司 | Domain user login method, device, equipment and medium |
| CN115314326A (en) * | 2022-10-11 | 2022-11-08 | 中化现代农业有限公司 | Method and system for realizing single sign-on based on WeChat applet |
| WO2022262322A1 (en) * | 2021-06-18 | 2022-12-22 | 京东方科技集团股份有限公司 | Authentication method, apparatus and system, electronic device, and storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101964791A (en) * | 2010-09-27 | 2011-02-02 | 北京神州泰岳软件股份有限公司 | Communication authenticating system and method of client and WEB application |
| CN102984169A (en) * | 2012-12-11 | 2013-03-20 | 中广核工程有限公司 | Single sign-on method, equipment and system |
| CN103179134A (en) * | 2013-04-19 | 2013-06-26 | 中国建设银行股份有限公司 | Single sign on method and system based on Cookie and application server thereof |
| CN105847220A (en) * | 2015-01-14 | 2016-08-10 | 北京神州泰岳软件股份有限公司 | Authentication method and system, and service platform |
| WO2017107732A1 (en) * | 2015-12-24 | 2017-06-29 | 广州爱九游信息技术有限公司 | Login status synchronization method and system |
| CN109309683A (en) * | 2018-10-30 | 2019-02-05 | 泰华智慧产业集团股份有限公司 | The method and system of client identity verifying based on token |
-
2019
- 2019-10-10 CN CN201910959090.XA patent/CN110730171A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101964791A (en) * | 2010-09-27 | 2011-02-02 | 北京神州泰岳软件股份有限公司 | Communication authenticating system and method of client and WEB application |
| CN102984169A (en) * | 2012-12-11 | 2013-03-20 | 中广核工程有限公司 | Single sign-on method, equipment and system |
| CN103179134A (en) * | 2013-04-19 | 2013-06-26 | 中国建设银行股份有限公司 | Single sign on method and system based on Cookie and application server thereof |
| CN105847220A (en) * | 2015-01-14 | 2016-08-10 | 北京神州泰岳软件股份有限公司 | Authentication method and system, and service platform |
| WO2017107732A1 (en) * | 2015-12-24 | 2017-06-29 | 广州爱九游信息技术有限公司 | Login status synchronization method and system |
| CN109309683A (en) * | 2018-10-30 | 2019-02-05 | 泰华智慧产业集团股份有限公司 | The method and system of client identity verifying based on token |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111447184A (en) * | 2020-03-09 | 2020-07-24 | 上海数据交易中心有限公司 | Single sign-on method, device, system and computer readable storage medium |
| CN111835793A (en) * | 2020-08-05 | 2020-10-27 | 天津美腾科技股份有限公司 | Communication method and device for Internet of things access, electronic equipment and storage medium |
| CN112464201A (en) * | 2020-11-02 | 2021-03-09 | 中国建设银行股份有限公司 | Token automatic issuing system, method and storage medium |
| CN112464201B (en) * | 2020-11-02 | 2024-03-01 | 中国建设银行股份有限公司 | Automatic token issuing system, method and storage medium |
| CN112199659A (en) * | 2020-12-03 | 2021-01-08 | 湖北亿咖通科技有限公司 | Access method, system and electronic device for multi-service platform of vehicle |
| CN112910904A (en) * | 2021-02-03 | 2021-06-04 | 叮当快药科技集团有限公司 | Login method and device of multi-service system |
| CN112910904B (en) * | 2021-02-03 | 2023-05-09 | 叮当快药科技集团有限公司 | Login method and device of multi-service system |
| CN113055186A (en) * | 2021-03-29 | 2021-06-29 | 建信金融科技有限责任公司 | Cross-system service processing method, device and system |
| CN113055186B (en) * | 2021-03-29 | 2023-04-07 | 中国建设银行股份有限公司 | Cross-system service processing method, device and system |
| WO2022262322A1 (en) * | 2021-06-18 | 2022-12-22 | 京东方科技集团股份有限公司 | Authentication method, apparatus and system, electronic device, and storage medium |
| CN114327956A (en) * | 2021-12-28 | 2022-04-12 | 阿波罗智联(北京)科技有限公司 | Request processing method and device for vehicle-mounted application, electronic equipment and storage medium |
| CN115001808A (en) * | 2022-05-31 | 2022-09-02 | 中国银行股份有限公司 | Domain user login method, device, equipment and medium |
| CN115314326A (en) * | 2022-10-11 | 2022-11-08 | 中化现代农业有限公司 | Method and system for realizing single sign-on based on WeChat applet |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110730171A (en) | Service request processing method, device and system, electronic equipment and storage medium | |
| US10554655B2 (en) | Method and system for verifying an account operation | |
| KR102141836B1 (en) | Two factor authentication | |
| US10681050B2 (en) | Ephemeral applications | |
| US8831570B2 (en) | Systems and methods for providing location-based application authentication using location token service | |
| CN110958218B (en) | Data transmission method based on multi-network communication and related equipment | |
| US9571282B1 (en) | Authentication on a computing device | |
| CN109146437B (en) | Virtual resource processing method, client and storage medium | |
| US10637664B2 (en) | User-directed identity verification over a network | |
| CN108718337B (en) | Website account login, verification and verification information processing method, device and system | |
| US8468584B1 (en) | Authentication code with associated confirmation words | |
| CN108833590B (en) | Voice recognition service proxy server and proxy method | |
| CN113259342A (en) | Login verification method, device, computer equipment and medium | |
| US11741082B2 (en) | Systems and methods for automated recovery of blockchain-based accounts | |
| CN106161356B (en) | Method and system for rapidly logging in website through client | |
| CN109359449B (en) | Authentication method, device, server and storage medium based on micro service | |
| US20200021579A1 (en) | Methods for randomized multi-factor authentication with biometrics and devices thereof | |
| US8412836B2 (en) | User authentication across multiple network stacks | |
| CN107787494B (en) | Recovery of login across reboots | |
| US11340965B2 (en) | Method and system for performing voice activated tasks | |
| CN115941217A (en) | Method for secure communication and related product | |
| US8955070B2 (en) | Controlled password modification method and apparatus | |
| CN106790385B (en) | Content providing system, sharing method and device | |
| CN111159765B (en) | Information processing method and system | |
| US9027038B2 (en) | Methods and apparatus for constructing a secure and flexible operating system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 801-2, floor 8, building 3, No. 22, Ronghua Middle Road, Beijing Economic and Technological Development Zone, Daxing District, Beijing Applicant after: Wanghai Kangxin (Beijing) Technology Co.,Ltd. Address before: Room 07, Room 2, Building B, 12 Hongda North Road, Beijing Daxing District, Beijing Applicant before: BEIJING NEUSOFT VIEWHIGH TECHNOLOGY Co.,Ltd. |
|
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200124 |