Supply planning system-oriented client persistent login method

Abstract

The invention discloses a supply plan system-oriented client persistent login method, which comprises the following steps of: acquiring an access token, a refresh token and an access token timestamp from a server based on successfully authenticated user login information; when a request is sent to a server, triggering a request interceptor to obtain an access token timestamp, and judging whether the access token timestamp is expired; and after the refresh token is added in the request, a request authentication interface carrying the refresh token is sent to the server side, or after the access token is added in the request, whether the access token added in the request is valid is judged, and if the access token is valid, the request authentication interface carrying the access token is sent to the server side. Therefore, whether the access token is refreshed or not can be judged in advance at the client through the access token timestamp, so that the problem that a user needs to perform login authentication again due to the fact that the access token is found to be expired only after the request arrives at the server is avoided, the login frequency of the user is reduced, and the use experience of the user is improved.

Description

Technical Field

[0001] The present application relates to the field of computer communication technology, and in particular to a client persistent login method, device, electronic device and storage medium for a supply planning system. Background Art

[0002] The supply planning system mainly includes three modules: demand forecasting, supply planning, and inventory management. The supply planner logs in to the supply planning system through identity information to operate. When the identity information is successfully logged in, the server communicating with the system client will generate a token (a token used for identity authentication and authorization) and issue it to the client. The client uses the token as a credential in subsequent requests to prove its identity and authority to the server. The token usually contains some encrypted information, such as: user ID, role, access rights, etc.

[0003] In order to ensure the security of the system database, the token has an expiration date. Once the expiration date is exceeded, the server will refuse to respond to requests with expired tokens. Therefore, in order to keep the user logged in, the token must be refreshed regularly to update its expiration date. If the token is not refreshed, when the supply planner fills in a large demand plan, it will take a long time to edit the content of the page table. When the editing is completed and clicks Save, it is found that the login timeout has occurred, resulting in data loss, which will seriously affect work efficiency. Token generally includes access token access_token and refresh token refresh_token. The access token is the token carried by the client when making a service request, and the refresh token is the token that must be carried in the token refresh request issued by the client. Although refresh_token can extend the validity period of access_token through timed refresh, the validity period of refresh_token itself is also limited. When refresh_token expires, the server refuses to respond and prompts the user to re-authenticate and log in before continuing to access. After re-login, the system usually clears the user's previous login status, session information and related cache, which means that the user will lose access to restricted resources that have been accessed before. If the validity period of the client user token is extended, the client retains the token for a long time, which may affect the database security. Summary of the invention

[0004] The embodiments of the present application provide a client persistent login method, device, electronic device and storage medium for a supply planning system. After a supply planner successfully logs in to the system client, the server generates a set of access tokens, refresh tokens and access token timestamps and sends them to the client. When the client sends a request, it determines whether the access token timestamp is expired, and carries the access token or refresh token in the request, so that the client's access token is refreshed in time, avoiding the problem of work interruption caused by the supply planner's work process due to token expiration and the need for re-login authentication, thereby improving the work efficiency within the supply planning system and ensuring the database security of the system.

[0005] In a first aspect, an embodiment of the present application provides a client persistent login method for a supply planning system, which is applied to a client and includes:

[0006] Based on the successfully authenticated user login information, an access token, a refresh token and an access token timestamp are obtained from the server and cached locally on the client. The validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token.

[0007] When sending a request to the server, trigger the request interceptor to obtain the access token timestamp, and determine whether the access token timestamp is expired. If it is expired, add a refresh token to the request, otherwise add an access token to the request; and

[0008] After adding the refresh token to the request, send a request authentication interface carrying the refresh token to the server, or,

[0009] After adding the access token in the request, determine whether the access token added in the request is valid. If valid, send a request authentication interface carrying the access token to the server. Otherwise, intercept the request and prompt the user to log in again for authorization.

[0010] In a possible embodiment, the step of determining whether the access token added in the request is valid includes:

[0011] Get the access token cached locally on the client;

[0012] It is determined whether the access token added in the request is consistent with the obtained access token. If they are consistent, the access token added in the request is a valid access token; otherwise, the access token added in the request is an invalid access token.

[0013] In a possible embodiment, after the step of sending the request authentication interface carrying the refresh token to the server, the method further includes:

[0014] The client receives response information returned by the server based on the request;

[0015] In the case where the refresh token received by the server is invalid, the response information is a first unauthorized status code;

[0016] In the case where the refresh token received by the server is expired, the response information is a second unauthorized status code;

[0017] In the case that the access token received by the server is valid and not expired, the response information is a set of refreshed access token, refresh token and access token timestamp.

[0018] In a possible embodiment, after the step of sending the request authentication interface carrying the access token to the server, the method further includes:

[0019] The client receives response information returned by the server based on the request;

[0020] In the case where the access token received by the server is invalid, the response information is a third unauthorized status code;

[0021] In the case where the access token received by the server is expired, the response information is a fourth unauthorized status code;

[0022] In the case that the access token received by the server is valid and not expired, the response information is the normal return of business data in response to the client request.

[0023] In a second aspect, an embodiment of the present application provides a client persistent login method for a supply planning system, which is applied to a server, including:

[0024] In response to the information that the client user successfully logs in and authenticates, an access token, a refresh token and an access token timestamp are generated and sent to the client, wherein the validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token;

[0025] Receiving a request from the client carrying an access token or a refresh token, and when responding, triggering interception of the response to obtain the access token or the refresh token carried by the response;

[0026] Returning the response data to the client based on the request carrying the access token; or,

[0027] The response data is returned to the client based on the request carrying the refresh token.

[0028] In a possible embodiment, the step of returning the response information to the client based on the request includes:

[0029] When the server receives a request carrying a refresh token and responds, the response interceptor is triggered to intercept the refresh token and determine whether the refresh token is valid. If the refresh token is invalid, a first unauthorized status code is returned to the client. If the refresh token is valid, it is further determined whether the refresh token is expired. If the refresh token is expired, a second unauthorized status code is returned to the client. If the refresh token is not expired, a set of refreshed access tokens, refresh tokens and access token timestamps are returned to the client.

[0030] In a possible embodiment, the step of returning the response information to the client based on the request includes:

[0031] When the server receives a request carrying an access token and responds, the response interceptor is triggered to intercept the access token and determine whether the access token is valid. If the access token is invalid, a third unauthorized status code is returned to the client. If the access token is valid, it is further determined whether the access token is expired. If the access token is expired, a fourth unauthorized status code is returned to the client. If the access token is not expired, the business data is returned normally in response to the client's request.

[0032] In a third aspect, an embodiment of the present application provides a client, including:

[0033] A token acquisition module is used to acquire an access token, a refresh token and an access token timestamp based on the successfully authenticated user login information, and cache them locally on the client. The validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token.

[0034] A request interceptor is triggered when a request is sent to the server to obtain the access token timestamp and determine whether the access token timestamp is expired. If expired, a refresh token is added to the request, otherwise an access token is added to the request;

[0035] A first sending module, configured to send a request authentication interface carrying the refresh token to the server after adding the refresh token to the request;

[0036] The second sending module is used to determine whether the access token added in the request is valid after adding the access token in the request. If valid, a request authentication interface carrying the access token is sent to the server. Otherwise, the request is intercepted and the user is prompted to log in again for authorization.

[0037] In a fourth aspect, an embodiment of the present application provides a server, including:

[0038] A generation module, configured to generate an access token, a refresh token and an access token timestamp in response to information that the client user successfully logs in and authenticates, and send the same to the client, wherein the validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token;

[0039] A response interceptor, used to receive a request from the client carrying an access token or a refresh token, and intercept the request to obtain the access token or the refresh token carried by the request;

[0040] A first response module, configured to return the response data to the client based on the request carrying the access token;

[0041] The second response module is used to return the response data to the client based on the request carrying the refresh token.

[0042] In a fifth aspect, an embodiment of the present application provides a token refreshing device, including:

[0043] The client described in the third aspect and the server described in the fourth aspect are communicatively connected with each other.

[0044] In a sixth aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor executes the client persistent login method for the supply planning system described in the first aspect or the second aspect above.

[0045] In a seventh aspect, the present application provides a computer-readable storage medium, which includes a program code. When the storage medium is run on an electronic device, the program code is used to enable the electronic device to execute the client persistent login method for the supply planning system described in the first and second aspects above.

[0046] In an eighth aspect, an embodiment of the present application provides a computer program product, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; when a processor of an electronic device reads the computer instructions from the computer-readable storage medium, the processor executes the computer instructions, so that the electronic device executes the client persistent login method for the supply planning system described in the first or second aspect above.

[0047] The beneficial effects of this application are as follows:

[0048] An embodiment of the present application provides a client persistent login method for a supply planning system, wherein the method applied to the client side includes: based on the user login information of the successfully authenticated user, obtaining an access token, a refresh token and an access token timestamp from the server, and caching them locally on the client, wherein the validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token; triggering a request interceptor to obtain the access token timestamp when sending a request to the server, and determining whether the access token timestamp is expired, and if so, adding a refresh token to the request, otherwise adding an access token to the request; and after adding the refresh token to the request, sending a request authentication interface carrying the refresh token to the server, or, after adding the access token to the request, determining whether the access token added in the request is valid, and if so, sending a request authentication interface carrying the access token to the server, otherwise intercepting the request and prompting the user to re-login for authorization. In this way, the access token timestamp can be used to determine in advance on the client side whether to refresh the access token, so as to avoid the user having to log in again and authenticate due to the expiration of the access token after the request reaches the server, thereby reducing the number of user authentication times, improving the operating experience of personnel in the supply planning system, and ensuring the data security of the supply planning system.

[0049] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0051] Figure 1 This is a schematic diagram of an application scenario in an embodiment of the present application;

[0052] Figure 2 This is a flowchart of an implementation method of a client persistent login method for a supply planning system in an embodiment of the present application;

[0053] Figure 3 This is a flowchart of an implementation method of a client persistent login method for a supply planning system on the client side in an embodiment of the present application;

[0054] Figure 4This is a flowchart of an implementation of a client persistent login method for a supply planning system on the server side in an embodiment of the present application;

[0055] Figure 5 A schematic diagram of the structure of a client in an embodiment of the present application;

[0056] Figure 6 This is a schematic diagram of the composition structure of a server used in an embodiment of the present application;

[0057] Figure 7 A schematic diagram of the hardware structure of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical scheme and advantages of the present application clearer, the technical scheme in the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be arbitrarily combined with each other. In addition, although the logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.

[0059] The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the invention described herein can be implemented in sequences other than those illustrated or described herein.

[0060] The following is a brief introduction to the design concept of the embodiment of the present application:

[0061] The supply planning system mainly includes the following three modules: demand forecasting, which is used to analyze historical sales volume and market trends to predict product demand in the future (it can be a week, a month, or a year), which helps to schedule production, optimize inventory, and reduce the risk of out-of-stock and backlog; supply planning, which is used to specify detailed production plans based on market demand, enterprise capabilities, and resource conditions, taking into account uncertain factors to ensure stable and reliable production; inventory management, which is used to dynamically manage and control products inside and outside the enterprise, ensure accurate inventory, and adjust and replenish inventory in time according to demand forecasts. The data in the supply planning system is edited and maintained by supply planners. In order to ensure the security of system data, each supply planner needs to be authenticated when logging into the system and is given system operation permissions corresponding to his or her identity.

[0062] Token is a token used for authentication and authorization, which usually contains some encrypted information, such as user ID, role, access rights, etc. When the supply planner performs an operation, after providing authentication information and logging in successfully, the server will generate a token and issue it to the client. The client uses the token as a credential in subsequent requests to prove its identity and authority to the server. However, when the supply planner fills in a large demand plan, it takes a long time to edit the content of the page table. Since the client retains the token for a long time, it may affect the database security including the user's identity information. Therefore, the token has an expiration date. Once the expiration date is exceeded, the server will refuse to use the expired token for request. This will cause the supply planner to find that the login timeout has occurred when he clicks Save after completing the editing, and he needs to log in to the system again, which will lead to the loss of the edited data, seriously affecting the work efficiency of the supply planner. In order to keep the user logged in, the token must be refreshed regularly to update its validity period. If the token is not refreshed, the user will need to re-authenticate, which will cause inconvenience and reduce the user's experience of using the web page. Traditional authentication mechanisms require users to provide usernames and passwords for each request, which is relatively cumbersome and prone to data loss, requiring users to repeat operations.

[0063] In view of this, the embodiments of the present application provide a method, device, electronic device and storage medium for client persistent login of a supply planning system, aiming to improve the operating experience of the supply planning system while protecting the user's data security. The client persistent login method for the supply planning system of the present application is implemented through interaction between the client and the server, wherein the client is an application terminal for the user to operate the system, and the server is a server device that responds to the client's request or instruction, and is used to generate a token and issue it to the client. When the client sends a request, the token is verified and the response information is returned according to the request. Specifically, the client-side persistent login method for the supply planning system described from the client side includes: first, based on the user login information of the successful authentication, the access token, refresh token and access token timestamp are obtained from the server and cached locally on the client, and the validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token; then, when sending a request to the server, the request interceptor is triggered to obtain the access token timestamp, and it is determined whether the access token timestamp is expired. If it is expired, a refresh token is added to the request, otherwise an access token is added to the request; finally, after adding the refresh token to the request, a request authentication interface carrying the refresh token is sent to the server, or after adding the access token to the request, it is determined whether the access token added in the request is valid. If it is valid, a request authentication interface carrying the access token is sent to the server, otherwise the request is intercepted and the user is prompted to log in again for authorization. In this way, the client's access token timestamp can be used to determine whether the access token is close to the expiration time point, and the access token is refreshed in advance, avoiding the need for the user to re-login and authenticate due to token expiration during the request response process, which affects the user experience.

[0064] The main technical solution of the client persistent login method for the supply planning system of this application is: after the client user logs in successfully, the server will generate a token for it as an identity credential, and the server will send the identity credential to the client cache. Token is usually a long string generated by the server, which contains the user's identity information and the expiration time of the identity information and other related information, generally including access token access_token and refresh token refresh_token. The server uses a key to sign the token to ensure its authenticity and integrity. When the server generates a token, it generates an access token timestamp. The access token timestamp is a time node generated at the same time as the access token. The time node records the expiration time of the access token generated this time, and the time node will be less than the actual validity period of the access token. When the client sends an access request for the first time, the token is obtained through the interceptor and stored locally, such as LocalStorage. When the user sends a request again through the client, the client will obtain the token from the local cache and determine whether the access token is about to expire through the access token timestamp. If it is about to expire (that is, the time node of the set access token timestamp has been reached), the refresh token is added to the Authorization field of the request header, and the server is requested to refresh the access token. The server will return a new access token in the response and use it as part of the response header. The client's request interceptor will check whether there is a new access token in the response and save it locally. If the access token is not about to expire, it will be directly added to the Authorization field of the request header. The server will parse and verify the access token carried in the request header to verify the user's identity. If the access token does not expire within a certain period of time, the backend server will process the client user's request normally. In this way, in subsequent requests, the client will continue to use the latest access token for identity authentication. The advantage of this application is that the user only needs to obtain a token once after a successful login and save it locally. In subsequent requests, users no longer need to manually enter their username and password for identity authentication, which improves the user experience. When a user actively logs out, they need to log in again to obtain a new token, which ensures the security of the user's identity information and effectively prevents the token from being maliciously used.

[0065] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application may be combined with each other if there is no conflict.

[0066] like Figure 1As shown, it is a schematic diagram of an application scenario provided by an embodiment of the present application. In the schematic diagram of the application scenario, a terminal device 101 and a server 102 are included. Among them, the terminal device 101 is an electronic device used by the target object, i.e., the client user, and the electronic device can be a personal computer, a mobile phone, a tablet computer, a notebook, an e-book reader, a car terminal, etc. The application (or client) of the supply planning system can be installed and run in the terminal device 101. The server 102 is the service end that responds to the client request in this application. The terminal 101 and the server 102 can be directly or indirectly connected via wired or wireless communication, and this application is not limited here. The server 102 here may include: one or more servers that can provide various services to the terminal. For example, a permission server that can provide permission services (such as permission services, billing services, etc.) for any application running in the terminal; for another example, an application server that can provide application services (such as game loading services, game function services, etc.) to the terminal. It should be noted that the server mentioned in the embodiment of the present application can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. The target object can use the various clients installed and running in the terminal device 101, and upload identity information through the client for login authentication. The server generates a token based on the identity information of the client to protect the database security of the client system in the terminal device 101.

[0067] There is no restriction on the number of the terminal devices 101 and / or servers 102 .

[0068] The following describes the client persistent login method for the supply planning system provided by the exemplary embodiment of the present application in combination with the above-mentioned application scenarios and with reference to the accompanying drawings. It should be noted that the above-mentioned application scenarios are only shown to facilitate the understanding of the spirit and principles of the present application, and the implementation methods of the present application are not subject to any limitations in this regard.

[0069] refer to Figure 2 , is an implementation flow chart of a client persistent login method for a supply planning system provided in an embodiment of the present application. After the user successfully logs in and authenticates on the client, the specific implementation flow of the client persistent login method for the supply planning system is as follows:

[0070] S201, the client sends a login request to the server and applies for an access token, a refresh token, and an access token timestamp.

[0071] S202, the server generates an access token, a refresh token and an access token timestamp based on the user login information of the client that has successfully authenticated the client, and sends them to the client. The client obtains the access token, the refresh token and the access token timestamp from the server and caches them locally on the client.

[0072] S203, the client sends a request to the server based on the user instruction to trigger the request interceptor to obtain the access token timestamp, and determines whether the access token timestamp is expired.

[0073] S2031: If the access token timestamp expires, after adding a refresh token to the request, a request authentication interface carrying the refresh token is sent to the server.

[0074] S2032: If the access token timestamp has not expired, add the access token to the request. After the client adds the access token to the request, it further determines whether the access token added to the request is valid.

[0075] S20321: If the access token is valid, a request authentication interface carrying the access token is sent to the server.

[0076] S20322: If the access token added to the request is invalid, intercept the request and prompt the user to log in again for authorization.

[0077] S204, the server responds after receiving the request from the client, and the response carries the same token as in the request. When the server responds, the response interceptor of the server is triggered to intercept the response and obtain the token carried in the response. At this time, the token intercepted by the response interceptor is an access token or a refresh token.

[0078] S205, when the server receives a request carrying a refresh token and responds, the response interceptor is triggered to intercept the refresh token in the response. The response will also carry a refresh token consistent with the received request to determine whether the refresh token is valid.

[0079] S2051: If the refresh token is invalid, return a first unauthorized status code to the client.

[0080] S2052: If the refresh token is valid, further determine whether the refresh token is expired.

[0081] S20521: If the refresh token expires, a second unauthorized status code is returned to the client.

[0082] S20522: If the refresh token has not expired, a set of refreshed access token, refresh token and access token timestamp is returned to the client.

[0083] S206, when the server receives a request carrying an access token and responds, the response interceptor is triggered to intercept the access token in the response. The response will also carry an access token consistent with the received request, and determine whether the access token is valid.

[0084] S2061: If the access token is invalid, return a third unauthorized status code to the client.

[0085] S2062: If the access token is valid, further determine whether the access token is expired.

[0086] S20621, if the access token expires, returning a fourth unauthorized status code to the client,

[0087] S20622: If the access token has not expired, the service data is returned normally in response to the request of the client.

[0088] Finally, the client receives the response information returned by the server based on the request. Since the tokens carried in the client's request are different, the response information returned by the server is also different. Specifically, when the client adds a refresh token in the request, it will receive the following three response information from the server: when the refresh token received by the server is invalid, the response information is the first unauthorized status code; when the refresh token received by the server is expired, the response information is the second unauthorized status code; when the access token received by the server is valid and not expired, the response information is a set of refreshed access tokens, refresh tokens and access token timestamps. When the client adds an access token in the request, it will receive the following three response information from the server: when the access token received by the server is invalid, the response information is the third unauthorized status code; when the access token received by the server is expired, the response information is the fourth unauthorized status code; when the access token received by the server is valid and not expired, the response information is a normal return of business data in response to the client request.

[0089] refer to Figure 3 , is an implementation flow chart of a client persistent login method for a supply planning system provided in an embodiment of the present application. This embodiment describes the specific process of the method from the client side. The method is applied to the client, and the specific implementation process is as follows:

[0090] S301, based on the successfully authenticated user login information, obtain the access token, refresh token and access token timestamp from the server and cache them locally on the client. The validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token.

[0091] When a user uses an application system, he logs in to the client by entering his identity information. Generally, the application system will set a system logout time. That is, when a user uses the application system, if he does not actively log out of the system for a long time, in order to ensure the security of user information, the system will automatically log out of the client according to the set logout time. During the validity period of the system logout, the client database security is protected by the token. Tokens generally include access tokens and refresh tokens. When a user sends a request through the client, the client's request interceptor adds the access token to the request header and sends it to the server for parsing and verification; the refresh token is used to refresh the access token, replace the expired access token in time, and extend the validity period of the client token to a certain extent, thereby ensuring the security and continuity of the user's use of the system. The access token timestamp records the expiration time node of the access token. The validity period of the access token is greater than the validity period of the access token timestamp. The client can obtain the expiration time of the access token in real time through the access token timestamp to ensure that the access token is refreshed before it expires, avoiding the expired access token in the request sent by the client.

[0092] S302, when sending a request to the server, triggering the request interceptor to obtain the access token timestamp, and determining whether the access token timestamp is expired, if expired, adding a refresh token to the request, otherwise adding an access token to the request.

[0093] Usually, a request interceptor is set up on the client side, and in the request interceptor, the access token from the client's local cache is carried in the request header for each application (API) that needs to be authenticated. The present application also caches the access token timestamp locally on the client side. When the client sends a request to the server side, the request interceptor is triggered to first obtain the access token timestamp cached locally on the client side. If the access token timestamp has expired, it means that the access token is about to expire and needs to be refreshed. At this time, the request interceptor adds a refresh token to the request header, requests the server side to refresh the access token, and returns it to the client side for local cache. Specifically, if the access token timestamp has expired, the process proceeds to the following step S303. If the access token timestamp has not expired, it means that the validity period of the access token is still sufficient to complete a request. At this time, the process proceeds to the following step S304.

[0094] S303: After adding the refresh token to the request, a request authentication interface carrying the refresh token is sent to the server.

[0095] S304, after adding the access token in the request, determine whether the access token added in the request is valid. If valid, send a request authentication interface carrying the access token to the server. Otherwise, intercept the request and prompt the user to log in again for authorization.

[0096] In some embodiments, the step of determining whether the access token added in the request is valid includes: obtaining an access token cached locally on the client; determining whether the access token added in the request is consistent with the obtained access token, if they are consistent, the access token added in the request is a valid access token, otherwise the access token added in the request is an invalid access token.

[0097] After adding the access token to the request, the validity of the added access token is judged again to prevent the client user from modifying the login information or user permissions on his own, such as sending a request using other authenticated user permissions. Therefore, before the client's request is sent, it is once again determined whether the access token added to the request is consistent with the access token cached locally on the client. If they are consistent, the added access token is confirmed to be a valid token, and the request interceptor allows the request to be sent to the server. If it is determined that the added access token is inconsistent with the access token cached locally on the client, the token added to the request is considered to be an invalid token, the request is intercepted, and the user is prompted that the login information is invalid and the user is required to log in again for authorization.

[0098] In some embodiments, after the step of sending a request authentication interface carrying the refresh token to the server, the method also includes: the client receives response information returned by the server based on the request; when the refresh token received by the server is invalid, the response information is a first unauthorized status code; when the refresh token received by the server is expired, the response information is a second unauthorized status code; when the access token received by the server is valid and not expired, the response information is a set of refreshed access token, refresh token and access token timestamp.

[0099] Specifically, when the access token timestamp expires, the request sent by the client carries a refresh token, that is, the client requests the server to refresh the locally cached access token in advance before the access token expires, and the server will also respond based on the received refresh token. Similarly, in order to prevent users from modifying user permissions or login information on their own and to ensure data security, the server will further determine whether the refresh token carried in the request is valid before responding. If the refresh token is invalid, the server returns the first unauthorized status code to the client, specifically a "401" code. At this time, the client needs to log in again to authorize before sending the request. If the refresh token is valid, then further determine whether the refresh token has expired. If the refresh token has also expired, the server returns the second unauthorized status code to the client, specifically a "403" code. At this time, the user needs to re-authenticate and log in before sending the request again. If the refresh token sent by the client to the server is valid and has not expired, the server will respond to the client's request and regenerate a set of refreshed access tokens, refresh tokens and access token timestamps for it. The access token timestamp records the production time node and validity time node of the refreshed access token, and the validity period of the access token timestamp will also be less than the validity period of the access token generated during the same period.

[0100] In some embodiments, after the step of sending a request authentication interface carrying the access token to the server, the method also includes: the client receives response information returned by the server based on the request; when the access token received by the server is invalid, the response information is a third unauthorized status code; when the access token received by the server is expired, the response information is a fourth unauthorized status code; when the access token received by the server is valid and not expired, the response information is a normal return of business data in response to the client request.

[0101] Specifically, when the timestamp of the access token has not expired, the request sent by the client carries the access token, that is, the client first confirms locally that the access token has not expired and sends it to the server, and the server responds according to the normal request access process. When the server returns a response, it will trigger the response interceptor of the server to intercept the response data and determine whether the access token carried in the response data is valid. If it is an invalid access token, the third unauthorized status code is returned to the client, specifically the "402" code. At this time, the client needs to re-login and authorize to obtain the response data. If the access token carried in the response data is valid, it will further determine whether the access token has expired. If it is an expired access token, the fourth unauthorized status code is returned to the client, specifically the "404" code. At this time, the client user needs to re-authenticate and log in. If the access token carried in the response data is valid and has not expired, the server will normally return the business data corresponding to the request to the client.

[0102] refer to Figure 4 , is an implementation flow chart of a client persistent login method for a supply planning system provided in an embodiment of the present application. This embodiment describes the specific process of the method from the server side. The method is applied to the server side. In practice, the server side is specifically manifested as a back-end server, which is connected to the front-end client device in communication. The specific implementation process is as follows:

[0103] S401, in response to the information of successful login authentication of the client user, generate an access token, a refresh token and an access token timestamp, and send them to the client, the validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token.

[0104] After the user successfully logs in and authenticates in the front-end client application, the back-end server as the server will generate an access token for the client as the identity credential for logging in to the corresponding application interface. In order to ensure the information security and validity of the access token, a refresh token needs to be generated on the server at the same time to ensure that when the access token expires, the user does not need to log in again, but directly requests the server to refresh the access token. Furthermore, in order to reduce the number of times the server obtains expired access tokens, the server generates an access token timestamp while generating the access token, and provides it to the client at the same time, so that the client can judge whether the access token is expired locally, predict in advance whether the access token is about to expire, and update the access token cached locally on the client in a timely and effective manner accordingly, avoiding the need for users to log in again and authenticate due to the server receiving an expired access token, which can reduce the number of repeated logins by users, enhance database security, and improve user experience.

[0105] S402, receiving a request from the client carrying an access token or a refresh token, and triggering interception of the response when responding to obtain the access token or the refresh token carried by the response.

[0106] The server sets a response interceptor. When the server receives a request from the client and responds, the response interceptor is triggered to intercept the response and obtain the access token or refresh token carried in the response.

[0107] S403: Return the response information to the client based on the request carrying the access token; or, return the response information to the client based on the request carrying the refresh token.

[0108] In some embodiments, the step of returning the response information to the client based on the request includes: when the server receives a request carrying a refresh token and responds, triggering a response interceptor to intercept the refresh token and determine whether the refresh token is valid; if the refresh token is invalid, returning a first unauthorized status code to the client; if the refresh token is valid, further determining whether the refresh token is expired; if the refresh token is expired, returning a second unauthorized status code to the client; if the refresh token has not expired, returning a set of refreshed access tokens, refresh tokens, and access token timestamps to the client.

[0109] In some embodiments, the step of returning the response information to the client based on the request includes: when the server receives a request carrying an access token and responds, triggering a response interceptor to intercept the access token and determine whether the access token is valid; if the access token is invalid, returning a third unauthorized status code to the client; if the access token is valid, further determining whether the access token is expired; if the access token is expired, returning a fourth unauthorized status code to the client; if the access token has not expired, returning business data normally in response to the client's request.

[0110] In this embodiment, a response interceptor is set to intercept the response data returned by the back-end server, and a response is determined based on the token carried in the response data, thereby achieving a seamless refresh of the client token and improving database security.

[0111] Based on the same inventive concept, the present application embodiment also provides a client and a server. Figure 5 A schematic diagram of the structure of a client 500 may include:

[0112] The token acquisition module 501 is used to acquire the access token, the refresh token and the access token timestamp based on the successfully authenticated user login information, and cache them locally on the client. The validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token.

[0113] The request interceptor 502 is triggered when a request is sent to the server to obtain the access token timestamp and determine whether the access token timestamp is expired. If it is expired, a refresh token is added to the request, otherwise an access token is added to the request;

[0114] A first sending module 503, configured to send a request authentication interface carrying the refresh token to the server after adding the refresh token to the request;

[0115] The second sending module 504 is used to determine whether the access token added in the request is valid after adding the access token in the request. If valid, a request authentication interface carrying the access token is sent to the server. Otherwise, the request is intercepted and the user is prompted to log in again for authorization.

[0116] like Figure 6 A schematic diagram of the composition structure of a server 600 may include:

[0117] A generation module 601 is used to generate an access token, a refresh token and an access token timestamp in response to information that the client user successfully logs in and authenticates, and send the access token to the client. The validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token.

[0118] A response interceptor 602, used to receive a request from the client carrying an access token or a refresh token, and intercept the request to obtain the access token or the refresh token carried by the request;

[0119] A first response module 603, configured to return the response data to the client based on the request carrying the access token;

[0120] The second response module 604 is used to return the response data to the client based on the request carrying the refresh token.

[0121] Based on the same inventive concept, the embodiment of the present application also provides a token refreshing device, which includes the above-mentioned client 600 and server 600, which are connected via communication.

[0122] In some possible implementations, the client 500 and the server 600 according to the present application may include at least a processor and a memory. The memory stores program code, and when the program code is executed by the processor, the processor executes the steps of the client persistent login method for the supply planning system according to various exemplary embodiments of the present application described in this specification. For example, the processor of the client 500 may execute the following steps: Figure 3 The steps of the client persistent login method for the supply planning system are shown in FIG. 6 . The processor at the server 600 may execute the following steps: Figure 4 The steps of the client persistent login method for the supply planning system are shown in .

[0123] Based on the same inventive concept, an electronic device is also provided in the embodiment of the present application, which can implement the functions of the aforementioned client persistent login method device for the supply planning system, and specifically, can be used to implement the functions of the client 500 or the server 600, refer to Figure 7 , the electronic device comprises:

[0124] At least one processor 701, and a memory 702 connected to the at least one processor 701. The specific connection medium between the processor 701 and the memory 702 is not limited in the embodiment of the present application. Figure 7 In the example, the processor 701 and the memory 702 are connected via a bus 700. Figure 7 The connections between other components are shown in bold lines, and are not intended to be limiting. The bus 700 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 7 Only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. Alternatively, the processor 701 can also be called a controller, and there is no limitation on the name.

[0125] In the embodiment of the present application, the memory 702 stores instructions that can be executed by at least one processor 701. The at least one processor 701 can execute the client persistent login method for the supply planning system discussed above by executing the instructions stored in the memory 702. The processor 701 can implement Figure 5 The client or Figure 6 The functions of each module in the server are shown.

[0126] Among them, the processor 701 is the control center, which can use various interfaces and lines to connect the various parts of the entire control device, and through running or executing instructions stored in the memory 702 and calling the data stored in the memory 702, the various functions of the control device and the processing data, the control device can be monitored as a whole.

[0127] In one possible design, the processor 701 may include one or more processing units, and the processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the modem processor may not be integrated into the processor 701. In some embodiments, the processor 701 and the memory 702 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on separate chips.

[0128] Processor 701 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the client persistent login method for the supply planning system disclosed in the embodiments of the present application can be directly embodied as a hardware processor execution, or a combination of hardware and software modules in the processor.

[0129] The memory 702 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 702 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 702 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 702 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0130] By programming the processor 701, the code corresponding to the client persistent login method for the supply planning system described in the above embodiment can be fixed into the chip, so that the chip can execute the code when running. Figure 2 , Figure 3 and Figure 4 The steps of the client persistent login method for the supply planning system in the embodiment shown are as follows: How to design and program the processor 701 is a technology well known to those skilled in the art and will not be described in detail here.

[0131] Based on the same inventive concept, an embodiment of the present application further provides a storage medium storing computer instructions. When the computer instructions are executed on a computer, the computer executes the client persistent login method for the supply planning system discussed above.

[0132] In some possible implementations, various aspects of the client persistent login method for a supply planning system provided in the present application may also be implemented in the form of a program product, which includes a program code. When the program product is run on an apparatus, the program code is used to enable the control device to execute the steps of the client persistent login method for a supply planning system according to various exemplary implementations of the present application described above in this specification.

[0133] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0134] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A client persistent login method for a supply planning system, characterized in that: Applied to the client, including: Based on the successfully authenticated user login information, an access token, a refresh token and an access token timestamp are obtained from the server and cached locally on the client. The validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token. When sending a request to the server, trigger the request interceptor to obtain the access token timestamp, and determine whether the access token timestamp is expired. If it is expired, add a refresh token to the request, otherwise add an access token to the request; and After adding the refresh token to the request, send a request authentication interface carrying the refresh token to the server, or, After adding the access token in the request, determine whether the access token added in the request is valid. If valid, send a request authentication interface carrying the access token to the server. Otherwise, intercept the request and prompt the user to log in again for authorization.

2. The method according to claim 1, characterized in that: The step of determining whether the access token added in the request is valid comprises: Get the access token cached locally on the client; It is determined whether the access token added in the request is consistent with the obtained access token. If they are consistent, the access token added in the request is a valid access token; otherwise, the access token added in the request is an invalid access token.

3. The method according to claim 1, characterized in that: After the step of sending the request authentication interface carrying the refresh token to the server, the method further includes: The client receives response information returned by the server based on the request; In the case where the refresh token received by the server is invalid, the response information is a first unauthorized status code; In the case where the refresh token received by the server is expired, the response information is a second unauthorized status code; In the case that the access token received by the server is valid and not expired, the response information is a set of refreshed access token, refresh token and access token timestamp.

4. The method according to claim 1, characterized in that: After the step of sending the request authentication interface carrying the access token to the server, the method further includes: The client receives response information returned by the server based on the request; In the case where the access token received by the server is invalid, the response information is a third unauthorized status code; In the case where the access token received by the server is expired, the response information is a fourth unauthorized status code; In the case that the access token received by the server is valid and not expired, the response information is the normal return of business data in response to the client request.

5. A client persistent login method for a supply planning system, applied to a server, characterized in that: include: In response to the information that the client user successfully logs in and authenticates, an access token, a refresh token and an access token timestamp are generated and sent to the client, wherein the validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token; Receiving a request from the client carrying an access token or a refresh token, triggering interception of the response when responding, and obtaining the access token or the refresh token carried by the response; Returning the response data to the client based on the request carrying the access token; or, The response data is returned to the client based on the request carrying the refresh token.

6. The method according to claim 5, characterized in that The step of returning the response information to the client based on the request comprises: When the server receives a request carrying a refresh token and responds, the response interceptor is triggered to intercept the refresh token and determine whether the refresh token is valid. If the refresh token is invalid, a first unauthorized status code is returned to the client. If the refresh token is valid, it is further determined whether the refresh token is expired. If the refresh token is expired, a second unauthorized status code is returned to the client. If the refresh token is not expired, a set of refreshed access tokens, refresh tokens and access token timestamps are returned to the client.

7. The method according to claim 5, characterized in that The step of returning the response information to the client based on the request comprises: When the server receives a request carrying an access token and responds, the response interceptor is triggered to intercept the access token and determine whether the access token is valid. If the access token is invalid, a third unauthorized status code is returned to the client. If the access token is valid, it is further determined whether the access token is expired. If the access token is expired, a fourth unauthorized status code is returned to the client. If the access token is not expired, the business data is returned normally in response to the client's request.

8. A client, characterized in that: include: A token acquisition module is used to acquire an access token, a refresh token and an access token timestamp based on the successfully authenticated user login information, and cache them locally on the client. The validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token. A request interceptor is triggered when a request is sent to the server to obtain the access token timestamp and determine whether the access token timestamp is expired. If expired, a refresh token is added to the request, otherwise an access token is added to the request; A first sending module, configured to send a request authentication interface carrying the refresh token to the server after adding the refresh token to the request; The second sending module is used to determine whether the access token added in the request is valid after adding the access token in the request. If valid, a request authentication interface carrying the access token is sent to the server. Otherwise, the request is intercepted and the user is prompted to log in again for authorization.

9. A server, characterized in that: include: A generation module, configured to generate an access token, a refresh token and an access token timestamp in response to information that the client user successfully logs in and authenticates, and send the same to the client, wherein the validity period of the access token is greater than the validity period of the access token timestamp and less than the validity period of the refresh token; A response interceptor, for receiving a request from the client carrying an access token or a refresh token and responding to the request, intercepting the response to obtain the access token or the refresh token carried by the response; A first response module, configured to return the response data to the client based on the request carrying the access token; The second response module is used to return the response data to the client based on the request carrying the refresh token.

10. A token refreshing device, characterized in that: include: The client as claimed in claim 8 and the server as claimed in claim 9, wherein the client and the server are communicatively connected.

11. An electronic device, characterized in that: The invention comprises a processor and a memory, wherein the memory stores a program code, and when the program code is executed by the processor, the processor executes any one of the methods in claims 1 to 4 or claims 5 to 7.

12. A computer-readable storage medium, characterized in that: The storage medium comprises a program code, and when the storage medium is run on an electronic device, the program code is used to enable the electronic device to execute any one of the methods described in claims 1 to 7.

Images