Token automatic renewal method, cross-system non-inductive renewal method, device and medium

Abstract

The invention discloses an automatic token renewal method, which is applied to a service system and comprises the following steps: acquiring a service request initiated by a user; judging whether a current token corresponding to the service request is valid or not; if the current token is invalid, storing the service request to a processing queue; performing parameter updating on a current token corresponding to the service request to generate an updated token; replacing the current token of the service request with the update token to obtain an updated service request; and issuing the updated service request from the processing queue to the corresponding Internet of Things equipment. According to the method disclosed by the invention, the parameter update and replacement are automatically performed when the token fails, so that the failure of a service request caused by authentication interruption is avoided, and the continuity and response efficiency of the system are improved; meanwhile, by means of a processing queue temporary storage mechanism, it is ensured that the request is not lost, non-sensitive token refreshing is achieved, and the stability and safety of interaction of the Internet of Things equipment are guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of token renewal, in particular to a token automatic renewal method, a cross-system non-sensing renewal method, a device and a medium. BACKGROUND

[0002] With the development of robots, robots usually need to verify the validity of data or services during use to ensure the security during data or service access. In the prior art, a token mechanism is usually used for identity authentication and permission control. When a user session expires, the system often directly interrupts the current operation and forces a re-login, resulting in a fragmented business process and impaired user experience. Therefore, an expired processing scheme that can realize non-sensing of users is needed to complete the automatic renewal of tokens without affecting business continuity. SUMMARY

[0003] The embodiments of the present application provide a token automatic renewal method, a cross-system non-sensing renewal method, a device and a medium to solve the problem of forced interruption of operation and repeated login of users due to token expiration in related technologies, realize non-sensing renewal of business requests, and improve user experience.

[0004] In a first aspect, the present application provides a token automatic renewal method applied to a business system, including: obtaining a business request initiated by a user; determining whether a current token corresponding to the business request is valid; if the current token is invalid, storing the business request to a processing queue; updating the current token corresponding to the business request to generate an updated token; replacing the current token of the business request with the updated token to obtain an updated business request; and issuing the updated business request from the processing queue to a corresponding Internet of Things device.

[0005] In some embodiments, after determining whether the current token corresponding to the business request is valid, the method further includes: obtaining a target address of the business request; when the target address belongs to a preset blocking address list, aborting the business request; and when the target address does not belong to the preset blocking address list and the current token is invalid, updating the current token.

[0006] In some embodiments, after storing the business request to the processing queue if the current token is invalid, the method further includes: if the business request exists a loading interface, hiding the loading interface and / or releasing resources occupied by the loading interface.

[0007] Secondly, this invention provides a cross-system seamless renewal method, applied to interaction scenarios between a login system and a business system, comprising: obtaining a business request initiated by a user through the login system, the business request carrying a current token generated by the login system; determining whether the IoT device corresponding to the business request is in an active state; if the IoT device is in an active state, determining whether the current token corresponding to the business request is valid, thereby identifying an invalid business request in the business request; refreshing the current token corresponding to the invalid business request to generate an updated token; replacing the current token in the business request with the updated token, and sending the business request to the IoT device.

[0008] In some embodiments, after refreshing the current token corresponding to the failed service request and generating an updated token, the method further includes: determining whether the sent service request was successful; if the request fails, setting the user's login status in the login system to an unlogged-in state; obtaining the user's login verification code through the login system's development toolkit; logging into the login system based on the login verification code, and resending the service request to the IoT device.

[0009] In some embodiments, after determining the startup status of the IoT device corresponding to the service request, the method further includes: If the startup status is not started, the session between the login system and the business system will be refreshed based on the login system's development toolkit. If the refresh is successful, the current token will be updated and the user will be automatically logged into the login system. If the refresh fails, the system will query whether the user's corresponding login authorization code exists based on the development toolkit and perform the login operation according to the query result.

[0010] In some embodiments, logging into the login system based on the query results includes: when the query result indicates that a login authorization code exists, automatically logging into the login system based on the login authorization code; when the query result indicates that no login authorization code exists, prompting the user to perform a login operation.

[0011] Thirdly, the present invention provides an automatic token renewal device, comprising: a first request acquisition module for acquiring a service request initiated by a user; a first token judgment module for judging whether the current token corresponding to the service request is valid; a request storage module for storing the service request in a processing queue if the current token is invalid; a first token update module for updating the parameters of the current token corresponding to the service request to generate an update token; a first token replacement module for replacing the current token of the service request with the update token to obtain an updated service request; and a request delivery module for delivering the updated service request from the processing queue to the corresponding Internet of Things device.

[0012] Fourthly, the present invention provides a cross-system seamless renewal device, comprising: a second request acquisition module, used to acquire a service request initiated by a user through a login system, the service request carrying a current token generated by the login system; a device status judgment module, used to determine whether the IoT device corresponding to the service request is in an active state; a second token judgment module, used to determine whether the current token corresponding to the service request is valid if the IoT device is in an active state, so as to identify the invalid service request in the service request; a second token update module, used to refresh the current token corresponding to the invalid service request and generate an updated token; and a second token replacement module, used to replace the current token in the service request with the updated token and send the service request to the IoT device.

[0013] Fifthly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described automatic token renewal method or cross-system seamless renewal method.

[0014] In a sixth aspect, the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described automatic token renewal method or cross-system seamless renewal method.

[0015] In summary, the automatic token renewal method disclosed herein, applied to a business system, includes: obtaining a business request initiated by a user; determining whether the current token corresponding to the business request is valid; if the current token is invalid, storing the business request in a processing queue; updating the parameters of the current token corresponding to the business request to generate an updated token; replacing the current token of the business request with the updated token to obtain an updated business request; and sending the updated business request from the processing queue to the corresponding IoT device. This method, by automatically updating and replacing parameters when a token expires, avoids business request failures due to authentication interruptions, thereby improving system continuity and response efficiency; simultaneously, by utilizing a processing queue temporary storage mechanism, it ensures that requests are not lost, achieving seamless token refresh and guaranteeing the stability and security of IoT device interactions. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of an embodiment of the present invention for automatic token renewal; Figure 2 This is another flowchart of automatic token renewal in one embodiment of the present invention; Figure 3 This is a flowchart of a cross-system seamless signature renewal method according to an embodiment of the present invention; Figure 4 This is another flowchart of a cross-system seamless signature renewal method in one embodiment of the present invention; Figure 5 This is a schematic block diagram of an automatic token renewal device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a cross-system seamless signature renewal device according to an embodiment of the present invention; Figure 7 This is a schematic block diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0018] As an example, such as Figure 1 As shown, an automatic token renewal method is provided for application in a business system, including the following steps: S101, Obtain the business request initiated by the user; S102, determine whether the current token corresponding to the business request is valid; S103, If the current token expires, the business request will be stored in the processing queue; S104, Update the parameters of the current token corresponding to the business request to generate an updated token; S105, replace the current token of the business request with the update token to obtain the updated business request; S106, the updated business request is sent from the processing queue to the corresponding IoT device.

[0019] As an example, in step S101, the business requests initiated by the user can be monitored in real time so that the business request can be obtained in a timely manner when the user initiates the business request.

[0020] The business requests may include, for example, device control requests, data query requests, or status synchronization requests, which are not limited in this disclosure. It should be understood that each business request carries a corresponding current token, which may contain authentication information such as the user's identity and permissions, token validity period, and access scope, used to verify the legitimacy of the request. This disclosure does not limit the specific information contained in the current token.

[0021] It should be understood that the business system can be a cloud platform system for managing IoT devices, capable of connecting to various types of terminal devices and handling their authentication and communication needs, or it can be an independent service component for token renewal. This disclosure does not limit it in this regard. Any system architecture or platform that can realize the automatic token renewal function is within the protection scope of this invention.

[0022] As an example, in step S102, the validity of the current token can be determined by verifying its expiration time. Specifically, the current token can be analyzed to obtain its expiration time, which is then compared with the current time of the business system. If the current time of the business system exceeds the expiration time, the current token is deemed invalid; otherwise, if the current time of the business system does not exceed the expiration time, the current token is deemed valid.

[0023] As an example, in step S103, when it is determined that the current token is invalid, in order to avoid the loss or interruption of business requests, it can be temporarily stored in the processing queue for buffering, so as to wait for the token to be updated before the business requests in the processing queue are sent out.

[0024] The specific form of the processing queue can be a first-in, first-out (FIFO) queue structure to ensure that after the current token is updated, business requests are processed sequentially according to their original initiation order, thereby ensuring the orderliness and reliability of the business system's response. However, it is not limited to this; other types of buffering mechanisms, such as priority queues or circular buffers, can also be used, flexibly configured according to actual business needs to improve processing efficiency and resource utilization.

[0025] Optionally, when the current token is determined to be invalid, an error code can be generated to indicate that the current token is invalid, and the error code can be used to instruct the business system to perform an update process for the current token.

[0026] It should be understood that after determining that the current token has expired, if the user indicates or the preset business system rules determine that the current token will not be updated (i.e., the expired current token will not be renewed), the corresponding business request can also be stored in the pending processing list, so as to wait for subsequent processing instructions to be triggered or specific conditions to be met before the renewal operation is performed, so as to ensure the integrity of the business request.

[0027] As an example, in step S104, the parameters of the current token can be updated according to a pre-set update strategy to generate a new update token, so that business requests can regain access rights using the updated token, ensuring business continuity.

[0028] The current token can be updated by re-signing or re-encrypting it to generate a corresponding updated token. It should be understood that the validity period of the updated token can be a new valid time period, such as from the time of update to a preset time length, to ensure that the updated token has a valid lifespan. The preset time length is, for example, 15 days, 30 days, etc., and this disclosure does not limit it.

[0029] As an example, in step S105, the current token in the business request can be replaced with an update token to obtain an updated business request, thereby ensuring that the business request carries valid authentication information and continues to be executed.

[0030] For example, the original current token field in the business request can be replaced with the field corresponding to the update token, while keeping other parameters of the request unchanged, to ensure that the integrity and consistency of the business request are not affected after the replacement.

[0031] As an example, in step S105, after the service request is updated, the intercepted service requests can be retrieved sequentially from the pending list, and the service request delivery process can be retried using the update token, thereby delivering the updated service request to the corresponding IoT device, ensuring that the token renewal is completed without the user's awareness, and enabling the corresponding IoT device to receive and respond to the instructions normally.

[0032] The Internet of Things (IoT) devices include, for example, smart lawnmowers, robotic vacuum cleaners, and logistics robots, but this disclosure does not limit them to any particular type.

[0033] Optionally, when sending the updated business requests from the processing queue to the corresponding IoT devices, they can be processed sequentially according to the first-in-first-out principle to ensure the rationality of the request execution order and the stability of the system response; alternatively, the updated business requests can be prioritized and the processing order can be allocated according to the business type or device status to ensure that key instructions are executed first, thereby improving system response efficiency and user experience. This disclosure does not limit the specific sending method.

[0034] In summary, this invention proposes an automatic token renewal method for application in a business system, comprising: acquiring a business request initiated by a user; determining whether the current token corresponding to the business request is valid; if the current token is invalid, storing the business request in a processing queue; updating the parameters of the current token corresponding to the business request to generate an updated token; replacing the current token of the business request with the updated token to obtain an updated business request; and sending the updated business request from the processing queue to the corresponding IoT device. This method, by automatically updating and replacing parameters when the token expires, avoids business request failures due to authentication interruptions, thereby improving the continuity and response efficiency of the business system; simultaneously, by utilizing a processing queue temporary storage mechanism, it ensures that requests are not lost, achieving seamless token refresh and guaranteeing the stability and security of IoT device interactions.

[0035] As an example, such as Figure 2 As shown, after step S102, which determines whether the current token corresponding to the business request is valid, it also includes: S201, Obtain the target address of the service request; S202, If the target address belongs to the preset blocked address list, the service request is terminated; S203: If the target address is not in the preset blocked address list and the current token is invalid, then update the current token.

[0036] As an example, in step S201, the business request can be parsed to obtain the target address information in the business request. The target address information can be information of the type such as IP address and domain name, which is not limited in this disclosure.

[0037] As an example, in step S202, if the target address belongs to the preset blocked address list, it means that the service request does not need to be processed further. At this time, the processing flow of the service request can be stopped immediately to avoid wasting resources. For example, when the service request is a user-initiated logout request, and the target address of the service request is the interface address corresponding to logout, and the interface address is in the preset blocked address list, the system will directly terminate the subsequent processing of the request, that is, it will no longer update the current token of the service request and discard the service request to prevent invalid operations from consuming system resources.

[0038] As an example, in step S203, when the target address is not in the blocking list and the current token has expired, it means that the service request needs to continue to be processed but the authentication credentials have expired. At this time, the token update mechanism is triggered to update the current token and generate an update token. The update token is used to replace the token of the service request, forming an updated service request. The updated service request is then redeployed from the processing queue to the target IoT device to ensure service continuity.

[0039] In an optional embodiment, after step S103, i.e., if the current token expires, the service request is stored in the processing queue, the method further includes: if the service request has a loading interface, the loading interface is hidden and / or the resources occupied by the loading interface are released, so as to reduce client resource consumption and improve user experience.

[0040] In other words, if it is determined that the current token of the business request is invalid and the request has been stored in the processing queue, since updating the current token takes a certain amount of time, the system can immediately hide the loading interface or release related resources to avoid users making mistakes or experiencing lag due to long loading wait times. After the current token is updated, the request processing is resumed and the necessary interface display is retried, thereby achieving a seamless transition in front-end interaction and further optimizing system response efficiency and user experience.

[0041] As an example, such as Figure 3 As shown, a seamless cross-system signature renewal method is provided, applicable to interaction scenarios between login systems and business systems, including the following steps: S301, Obtain the business request initiated by the user through the login system. The business request carries the current token generated by the login system. S302, determine whether the IoT device corresponding to the business request is in the startup state; S303, If the IoT device is in the startup state, determine whether the current token corresponding to the business request is valid in order to identify invalid business requests in the business request. S304, refresh the current token corresponding to the failed service request and generate an update token; S305 will update the token to replace the current token in the business request and send the business request to the IoT device.

[0042] As an example, in step S301, the login system can be monitored to capture user-initiated business requests in real time and extract the current token issued by the login system.

[0043] It should be understood that the login system and the business system are deployed independently. The login system is used for user authentication and to generate access tokens, while the business system uses the tokens to verify user permissions and process business requests to be sent to IoT devices.

[0044] As an example, in step S302, when a service request initiated by a user is received, the running status of the corresponding IoT device can be queried to determine whether it is in the startup state. If the device is not started, the request is temporarily stored and the device is waited to come online. If it is started, the subsequent token validity verification is continued to ensure that the service request is only processed when the IoT device can respond, thus avoiding resource waste caused by invalid communication.

[0045] As an example, in step S303, after determining that the IoT device is in the startup state, it can further verify whether the current token is valid and determine the invalid business requests in the business requests where the current token is invalid, so as to trigger the renewal process in a timely manner when the current token is invalid.

[0046] The validity of a token can be determined by verifying its issuance time, validity period, and token signature. This disclosure does not limit the specific method for determining the validity of a token.

[0047] As an example, in step S304, the parameters of the current token can be updated according to a pre-set update strategy to generate a new update token, so that business requests can regain access rights using the updated token, ensuring business continuity.

[0048] The current token can be refreshed by re-signing or re-encrypting it to generate a corresponding updated token. It should be understood that the validity period of the updated token can be a new valid time period, such as from the time of update to a preset time length, to ensure that the updated token has a valid lifespan. The preset time length is, for example, 15 days, 30 days, etc., and this disclosure does not limit it.

[0049] As an example, in step S305, the current token in the business request can be replaced with an update token to obtain an updated business request, thereby ensuring that the business request carries valid authentication information and continues to be executed, and is sent to the corresponding IoT device for subsequent processing, ensuring that the user can complete the token renewal without noticing.

[0050] For example, the original current token field in the business request can be replaced with the field corresponding to the update token, while keeping other parameters of the request unchanged, to ensure that the integrity and consistency of the business request are not affected after the replacement.

[0051] In summary, this disclosure proposes a cross-system seamless renewal method for applications between login systems and business systems. The method includes: obtaining a business request initiated by a user through the login system, the request carrying a current token generated by the login system; determining whether the IoT device corresponding to the business request is in an active state; if the IoT device is active, determining whether the current token corresponding to the business request is valid to identify invalid business requests; refreshing the current token corresponding to the invalid business request to generate an updated token; replacing the current token in the business request with the updated token, and sending the business request to the IoT device. This method automatically updates and replaces parameters when the token expires, avoiding business request failures due to authentication interruptions, thereby improving business system continuity and response efficiency, and achieving seamless renewal for users. Simultaneously, by determining whether the IoT device is active before executing the renewal process, it avoids sending invalid requests to offline devices, reducing system resource waste and communication overhead, and improving overall processing efficiency.

[0052] As an example, such as Figure 4 As shown, in step S305, after replacing the current token in the service request with the update token and sending the service request to the IoT device, the following steps are also included: S401, determine whether the sent business request was successful; S402, If the request fails, set the user's login status in the login system to not logged in. S403, obtain the user's login verification code through the login system's development toolkit; S404, logs into the system based on the login verification code and then sends the business request to the IoT device again.

[0053] As an example, in step S401, the success of a business request can be determined by receiving response information returned by the IoT device. If the response information contains a preset success flag, the request is considered successful; otherwise, it is considered a failure. Alternatively, the execution actions of the IoT device can be monitored. If the IoT device completes the action corresponding to the business request within a preset time window, the request is considered successful; otherwise, it is considered a failure. However, this disclosure does not limit the method for determining whether a business request is successful.

[0054] As an example, in step S402, when the judgment result is that the business request failed, it means that the token update can no longer pass the verification. In other words, the preset refresh mechanism for the current token has failed to restore valid authentication. At this time, it can be considered that the user's login status has expired or there is an anomaly, and it is necessary to force a re-login authentication to ensure system security and the authenticity and validity of the user's identity. Therefore, the user's login status in the login system can be reset to an unlogged-in status, thereby enabling re-login.

[0055] As an example, in step S403, the login verification code can be obtained by calling the interface for obtaining the login verification code through the development toolkit of the login system. The login verification code can be generated based on the user's identity information and session key, and has timeliness and uniqueness, but is not limited thereto. This disclosure does not limit the specific method of obtaining the login verification code.

[0056] It should be understood that the login verification code is used to verify whether a user has legitimate login privileges. That is, by verifying the login verification code, it can be determined whether a user can log in to the login system.

[0057] As an example, in step S404, an automatic re-login request is initiated using the obtained login verification code. After the identity re-authentication is completed, it indicates that the user's identity information has been verified and the user's login status is restored. At this time, as the user logs in again, the login system can generate a new token and inject the new token into the corresponding business request to replace the update token in the business request and re-initiate the request to the IoT device.

[0058] As an example, in step S302, after determining whether the IoT device corresponding to the business request is in the startup state, the method further includes: if the startup state is not started, then refresh the session between the login system and the business system based on the development toolkit of the login system; if the refresh is successful, then update the current token and automatically log in to the login system; if the refresh fails, then query whether there is a login authorization code corresponding to the user based on the development toolkit, and perform the login operation according to the query result.

[0059] Specifically, when the startup status is determined to be "not started," it indicates that the IoT device has not yet established a valid connection or is in a dormant state. Therefore, to prevent users from cold-starting the IoT device, the system's development kit can be used to silently refresh the session status in the background to determine if the connection with the IoT device has been successful. If the session refresh is successful, it means that inter-system communication has been restored, and the current token can be updated and automatic login can be completed, avoiding manual user intervention and achieving seamless login. If the session refresh fails, the development kit can be used to query whether a valid user login authorization code exists, and the appropriate login strategy can be selected based on the query results.

[0060] Furthermore, when the query result indicates the existence of a login authorization code, the system automatically logs the user in based on the code. When the query result indicates the absence of a login authorization code, the user is prompted to log in. In other words, when the system cannot detect a valid login authorization code, it means the user has not completed authorization or the authorization information has expired. In this case, the user needs to be redirected to the authentication page to re-complete the identity verification and authorization process. This can be done by displaying the login page and guiding the user to enter their account and password, or by completing the login through a third-party authentication method. When the system detects a valid login authorization code, it can directly use the code to complete the automatic login process without requiring the user to re-enter credentials, achieving seamless login and improving the user experience.

[0061] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0062] In one embodiment, an automatic token renewal device is provided, which corresponds one-to-one with the automatic token renewal method described in the above embodiments. For example... Figure 5 As shown, the automatic token renewal device includes a first request acquisition module 501, a first token judgment module 502, a request storage module 503, a first token update module 504, a first token replacement module 505, and a request issuance module 506. Detailed descriptions of each functional module are as follows: The first request acquisition module 501 is used to acquire business requests initiated by users; The first token judgment module 502 is used to determine whether the current token corresponding to the business request is valid. The request storage module 503 is used to store the business request to the processing queue if the current token expires. The first token update module 504 is used to update the parameters of the current token corresponding to the business request in order to generate an updated token; The first token replacement module 505 is used to replace the current token of the business request with the updated token to obtain the updated business request; The request delivery module 506 is used to send the updated business request from the processing queue to the corresponding IoT device.

[0063] In one embodiment, the first token determination module 502 is further configured to obtain the target address of the service request; If the target address belongs to the preset blocked address list, the service request will be terminated; If the target address is not in the preset blocked address list and the current token is invalid, then the current token will be updated.

[0064] In one embodiment, the request storage module 503 is further configured to hide the loading interface and / or release the resources occupied by the loading interface if the service request has a loading interface.

[0065] This invention provides an automatic token renewal device, comprising: a first request acquisition module for acquiring a service request initiated by a user; a first token judgment module for determining whether the current token corresponding to the service request is valid; a request storage module for storing the service request in a processing queue if the current token expires; a first token update module for updating the parameters of the current token corresponding to the service request to generate an updated token; a first token replacement module for replacing the current token of the service request with the updated token to obtain an updated service request; and a request delivery module for delivering the updated service request from the processing queue to the corresponding IoT device. This device, by automatically updating and replacing parameters when the token expires, avoids service request failures due to authentication interruptions, thereby improving system continuity and response efficiency; simultaneously, by utilizing a processing queue temporary storage mechanism, it ensures that requests are not lost, achieving seamless token refresh and guaranteeing the stability and security of IoT device interactions.

[0066] In one embodiment, a cross-system seamless renewal device is provided, which corresponds one-to-one with the cross-system seamless renewal method described in the above embodiments. For example... Figure 6 As shown, the cross-system seamless renewal device includes a second request acquisition module 601, a device status judgment module 602, a second token judgment module 603, a second token update module 604, and a second token replacement module 605. Detailed descriptions of each functional module are as follows: The second request acquisition module 601 is used to acquire the business request initiated by the user through the login system. The business request carries the current token generated by the login system. The device status judgment module 602 is used to determine whether the IoT device corresponding to the business request is in the startup state. The second token judgment module 603 is used to determine whether the current token corresponding to the business request is valid when the IoT device is in the startup state, so as to identify the invalid business request in the business request. The second token update module 604 is used to refresh the current token corresponding to the failed service request and generate an update token. The second token replacement module 605 is used to replace the current token in the business request with an update token and send the business request to the IoT device.

[0067] In one embodiment, the second token replacement module 605 is further configured to determine whether the sent service request was successfully requested; If the request fails, the user's login status in the login system will be set to not logged in. Obtain the user's login verification code using the system's development toolkit; Log in to the system using the login verification code and then send the business request to the IoT device again.

[0068] In one embodiment, the device status determination module 602 is further configured to, if the startup status is not started, refresh the session between the login system and the business system based on the development toolkit of the login system; If the refresh is successful, the current token will be updated and the user will be automatically logged into the login system. If the refresh fails, the system will query the development kit to see if the user's login authorization code exists, and then perform the login operation based on the query results.

[0069] In one embodiment, the device status judgment module 602 is further configured to automatically log in to the system based on the login authorization code when the query result indicates that a login authorization code exists; If the query result indicates that no login authorization code exists, the user will be prompted to log in.

[0070] This invention provides a cross-system seamless renewal device, comprising: a second request acquisition module for acquiring a business request initiated by a user through a login system, the business request carrying a current token generated by the login system; a device status judgment module for determining whether the IoT device corresponding to the business request is in an active state; a second token judgment module for determining whether the current token corresponding to the business request is valid if the IoT device is in an active state, thereby identifying invalid business requests; a second token update module for refreshing the current token corresponding to the invalid business request and generating an updated token; and a second token replacement module for replacing the current token in the business request with the updated token and sending the business request to the IoT device. This device, by automatically updating and replacing parameters when the token expires, avoids business request failures due to authentication interruptions, thereby improving the continuity and response efficiency of the business system and achieving seamless renewal for users. Simultaneously, by determining whether the IoT device is in an active state before executing the renewal process, it avoids sending invalid requests to offline devices, reducing system resource waste and communication overhead, and improving overall processing efficiency.

[0071] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data used in the automatic token renewal method or the cross-system seamless renewal method. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program can implement an automatic token renewal method or a cross-system seamless renewal method.

[0072] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements an automatic token renewal method or a cross-system seamless renewal method.

[0073] In one embodiment, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements an automatic token renewal method or a cross-system seamless renewal method.

[0074] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), IAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0075] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0076] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for automatic token renewal, characterized in that, The application is applied to a business system, comprising: obtaining a business request initiated by a user; determining whether a current token corresponding to the business request is valid; if the current token is invalid, storing the business request to a processing queue; updating parameters of the current token corresponding to the business request to generate an updated token; replacing the current token of the business request with the updated token to obtain an updated business request; issuing the updated business request from the processing queue to a corresponding Internet of Things device.

2. The method of claim 1, wherein, After the determination of whether the current token corresponding to the business request is valid, further comprising: obtaining a target address of the business request; when the target address belongs to a preset blocked address list, aborting the business request; when the target address does not belong to the preset blocked address list and the current token is invalid, updating the current token.

3. The method of claim 1, wherein, After the storage of the business request to the processing queue when the current token is invalid, further comprising: if a loading interface exists for the business request, hiding the loading interface and / or releasing resources occupied by the loading interface.

4. A cross-system non-sense renewal method, characterized in that, The application is applied to an interaction scenario between a login system and a business system, comprising: obtaining a business request initiated by a user through the login system, the business request carrying a current token generated by the login system; determining whether an Internet of Things device corresponding to the business request is in a startup state; if the Internet of Things device is in the startup state, determining whether the current token corresponding to the business request is valid to determine an invalid business request in the business request; refreshing the current token corresponding to the invalid business request to generate an updated token; replacing the current token in the business request with the updated token and sending the business request to the Internet of Things device.

5. The method of claim 4, wherein, After the replacement of the current token in the business request with the updated token and the sending of the business request to the Internet of Things device, further comprising: determining whether the sent business request is successfully requested; if the request fails, setting a login state of the user in the login system to an unlogged state; obtaining a login verification code corresponding to the user through a development kit of the login system; logging in the login system based on the login verification code and sending the business request to the Internet of Things device again.

6. The method of claim 4, wherein, After the determination of the startup state of the Internet of Things device corresponding to the business request, further comprising: if the startup state is unstarted, refreshing a session between the login system and the business system based on a development kit of the login system; if the refreshing succeeds, updating the current token and automatically logging in the login system; if the refreshing fails, querying whether there is a login authorization code corresponding to the user based on the development kit and performing a login operation according to a query result.

7. The method of claim 6, wherein, The login in the login system according to the query result comprises: when the query result is that there is the login authorization code, automatically logging in the login system based on the login authorization code; when the query result is that there is no login authorization code, prompting the user to perform a login operation.

8. A token automatic renewal apparatus, characterized by, ​ The first request obtaining module is configured to obtain a service request initiated by a user. The first token judgment module is configured to judge whether a current token corresponding to the service request is valid. The request storage module is configured to store the service request in a processing queue if the current token is invalid. The first token updating module is configured to update parameters of the current token corresponding to the service request to generate an updated token. The first token replacing module is configured to replace the current token of the service request with the updated token to obtain an updated service request. The request issuing module is configured to issue the updated service request from the processing queue to a corresponding Internet of Things device.

9. A cross-system non-sense renewal apparatus, comprising: The second request obtaining module is configured to obtain a service request initiated by a user through the login system, the service request carrying a current token generated by the login system. The device state judgment module is configured to judge whether an Internet of Things device corresponding to the service request is in a starting state. The second token judgment module is configured to judge whether a current token corresponding to the service request is valid if the Internet of Things device is in the starting state, to determine an invalid service request in the service request. The second token updating module is configured to perform token refreshing on the current token corresponding to the invalid service request to generate an updated token. The second token replacing module is configured to replace the current token in the service request with the updated token, and send the service request to the Internet of Things device. The computer program is executed by the processor to implement the token automatic renewal method according to any one of claims 1 to 3 or the cross-system non-susceptible renewal method according to any one of claims 4 to 7.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. ​

Images