Multi-plugin authorization token management method, electronic device, and storage medium

Abstract

This disclosure proposes a multi-plugin authorization token management method, electronic device, and storage medium. In response to detecting an update response of a shared authorization token, the method creates an update lock process. If the update lock process successfully preempts the lock, it acquires new token information and updates the shared authorization token based on this information. If the update lock process fails to preempt the lock, after monitoring the already created lock process to release its lock process, it reads the updated shared authorization token to perform authorization login based on the updated shared authorization token. In the absence of preemption of the update lock process, authorization login is performed based on the updated shared authorization token from the already created lock process after it is released. This avoids the waste of computing resources caused by constantly refreshing and preempting lock processes. In this embodiment, the lock process preemption mechanism described above avoids simultaneous read / write operations by multiple plug-ins to a certain extent, thereby reducing data conflicts.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a multi-plugin authorization token management method, electronic device, and storage medium. Background Technology

[0002] With the development of computer technology, more and more functional programs are integrated into the same development environment in the form of plugins. Different plugins integrated into the same development environment typically store their authorization tokens in their respective private processes. Each time a different plugin is called within this development environment, it is necessary to retrieve the authorization token and other information from the corresponding plugin's private process. When frequently calling different plugins, this process becomes overly cumbersome and results in a poor user experience.

[0003] In existing technologies, shared storage space is typically used to store the shared authorization tokens of each plugin to solve the above problems. However, shared storage space cannot avoid data conflicts during the simultaneous reading and writing process of multiple plugins, and maintenance requires real-time reliance on resident processes, which consumes a lot of computing resources. Summary of the Invention

[0004] This disclosure presents a multi-plugin authorization token management method, electronic device, and storage medium.

[0005] The first aspect of this disclosure provides a method for managing authorization tokens for multiple plugins, applicable to any one of multiple plugins, wherein the shared authorization tokens of the multiple plugins are stored in a shared storage space, and the method includes: In response to the detection of an update response to the shared authorization token, an update lock process is created; the update response refers to the need to write a new shared authorization token. If the lock update process successfully preempts, it obtains new token information and updates the shared authorization token based on the new token information; If the lock update process fails to preempt, after monitoring the lock creation process to release the lock, the updated shared authorization token is read so that authorized login can be performed based on the updated shared authorization token.

[0006] In this embodiment of the disclosure, before updating the shared authorization token based on the new token information, the method further includes: Verify whether the identification information and version number of the new token information match the shared authorization token; If it matches the shared authorization token, then update the shared authorization token based on the new token information; If the shared authorization token does not match, the update lock process is released and stops updating the shared authorization token.

[0007] In this embodiment of the disclosure, the method further includes: If the duration of the update lock process exceeds a preset duration threshold, the update lock process is released.

[0008] In this embodiment of the disclosure, the method further includes: In response to receiving change information about the shared authorization token; the change information includes any one of creation, modification, and deletion; Based on the changed information, the modified shared authorization token is read, and authorized login is performed based on the modified shared authorization token.

[0009] In this embodiment of the disclosure, the method further includes: The attribute information of the shared authorization token is periodically read from the shared storage space; the attribute information includes operation time, operation type, and token identifier. Detect whether the attribute information of the current period has changed compared with the attribute information of the previous period; In the event of a change in attribute information, verify whether the shared authorization token for the current period is a forged token; Based on the verification results, the running status of the plugin is determined.

[0010] In this embodiment of the disclosure, verifying whether the shared authorization token for the current period is a forged token includes: Verify whether the shared authorization token of the current period conforms to the target format of the ciphertext to be decrypted; If the shared authorization token of the current period is a ciphertext to be decrypted that conforms to the target format, then the ciphertext to be decrypted is decrypted to obtain the client identifier of the shared authorization token of the current period; If the client identifier verification is successful, the system checks whether the authorization period has expired. If the authorization period has expired, the token is considered forged; if the authorization period has not expired, the token is not forged.

[0011] In this embodiment of the disclosure, determining the running status of the plugin based on the verification results includes: If the verification result is successful, authorized login is performed based on the shared authorization token for the current period; If the verification result is unsuccessful, and the client identifier verification fails or the authorization period expires, the plugin's authorization token will not be updated.

[0012] In this embodiment of the disclosure, after updating the shared authorization token based on the new token information, the method further includes: The updated token information is sent to the multiple plugins so that the multiple plugins can authorize login based on the updated shared authorization token after receiving the updated token information.

[0013] A second aspect of this disclosure provides a multi-plugin authorization token management device, applicable to any one of multiple plugins, wherein the shared authorization tokens of the multiple plugins are stored in a shared storage space, and the device includes: A process creation module is used to create an update lock process in response to the detection of an update response to the shared authorization token; the update response refers to the need to write a new shared authorization token. The update module is used to obtain new token information and update the shared authorization token based on the new token information if the update lock process successfully preempts it. The waiting module is used to read the updated shared authorization token after monitoring the lock creation process to release the lock process if the lock update process fails to preempt it, so as to perform authorized login based on the updated shared authorization token.

[0014] According to a third aspect of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being executed by the processor to cause the electronic device to perform the method as described in the first aspect or any optional embodiment of the first aspect.

[0015] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided having a computer program stored thereon, the program being executed by a processor to implement the method as described in the first aspect or any optional embodiment of the first aspect.

[0016] The technical solutions provided in this disclosure have at least the following technical effects or advantages: The multi-plugin authorization token management method in this embodiment is applied to any one of multiple plugins. The shared authorization tokens of these plugins are stored in a shared storage space. In response to a detected update response to the shared authorization token, the method creates an update lock process, where the update response indicates the need to write a new shared authorization token. If the update lock process successfully preempts the request, it obtains the new token information and updates the shared authorization token based on this information. If the update lock process fails to preempt the request, after detecting the release of a lock process already created, it reads the updated shared authorization token to perform authorization login based on the updated token. In the absence of preemption of the update lock process, authorization login is performed based on the updated shared authorization token after the lock process is released, avoiding the waste of computing resources caused by constantly refreshing and preempting lock processes. This embodiment, through the aforementioned lock process preemption mechanism, avoids simultaneous read / write operations by multiple plugins to a certain extent, thereby reducing data conflicts.

[0017] Additional aspects and advantages of this disclosure will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this disclosure. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart of a multi-plugin authorization token management method provided in an embodiment of this disclosure is shown; Figure 2 A schematic diagram of the structure of a multi-plugin authorization token management device provided in yet another embodiment of this disclosure is shown; Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure is shown; Figure 4 A schematic diagram of a storage medium provided according to an embodiment of the present disclosure is shown. Detailed Implementation

[0019] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0020] It should be noted that, unless otherwise stated, the technical or scientific terms used in this disclosure shall have the ordinary meaning as understood by one of ordinary skill in the art to which this disclosure pertains.

[0021] With the development of computer technology, more and more functional programs (such as code completion, code refactoring, and intelligent question answering) are integrated into various integrated development environments (IDEs) in the form of plugins to improve development efficiency and user experience. In actual development scenarios, multiple heterogeneous plugins may run on the same terminal device. These plugins belong to different product lines of the same service provider and run in different IDEs, different language runtimes, and independent processes.

[0022] In existing technologies, different plugins integrated into the same development environment typically store authorization tokens in their respective private processes. When a user frequently calls different plugins within the same development environment, the authorization token must be retrieved from each plugin's private process to complete authentication and authorization. This process not only leads to issues such as repeated logins and inconsistent login states, but also becomes cumbersome and negatively impacts the user experience in scenarios involving frequent switching between multiple plugins.

[0023] To address the aforementioned issues, existing technologies propose a shared storage-based solution: all plugin authorization tokens are stored in a single shared storage area, allowing plugins to reuse and synchronize their login states by reading tokens from this shared area. However, this solution still suffers from the following drawbacks in practical applications: Firstly, there is the issue of data conflicts: Since multiple plugins run in different processes, data conflicts may occur when multiple plugins simultaneously perform read and write operations on the shared storage space (especially concurrent token refresh operations). For example, if multiple plugins simultaneously use old tokens that are about to expire to send refresh requests to the authorization server, since the refresh token can only be used successfully once, the plugin that initiates the refresh later will be judged as having expired login due to the old token being invalid, leading to an abnormal phenomenon of "kicking each other offline" among the plugins, thus compromising login stability.

[0024] Secondly, there's the issue of resource consumption: Existing shared storage solutions typically rely on a persistent background service process to maintain the read / write, monitoring, and synchronization logic of the shared storage area. This persistent process continuously consumes system memory and computing resources, and its lifecycle and exception recovery require additional management, increasing system complexity and maintenance costs. It is particularly unsuitable for lightweight development environments that are sensitive to resource consumption or do not allow the introduction of additional background processes.

[0025] In summary, existing technologies suffer from high data conflict risks, weak real-time synchronization capabilities, and high resource overhead in multi-plugin login state synchronization. Therefore, there is an urgent need for a multi-plugin login state collaborative management solution that does not require a persistent background process, can effectively avoid concurrent read / write conflicts between multiple processes, and can achieve real-time synchronization of login states.

[0026] In view of this, this disclosure proposes a multi-plugin authorization token management method to solve the above problems. For example... Figure 1 As shown, the multi-plugin authorization token management method of this disclosure is applied to any one of multiple plugins, and the shared authorization token of the multiple plugins is stored in a shared storage space, and may include the following steps: In step S11, in response to the detection of an update response to the shared authorization token, an update lock process is created; the update response means that a new shared authorization token needs to be written.

[0027] For example, an update response refers to a trigger signal indicating that the shared authorization token needs to be updated. This response can be triggered by various events, such as: the plugin detecting that the current token is about to expire (e.g., the remaining validity period is less than a preset threshold), the plugin receiving a token expiration indication from the authorization server, or the plugin detecting that the token version number in the shared storage area is inconsistent with the local version. Those skilled in the art can flexibly set the triggering conditions for the update response, and this invention does not limit this. The update lock process refers to a mutual exclusion mechanism used to coordinate token update operations among multiple processes. This process achieves leader election by atomically and exclusively creating a lock file, rather than through centralized scheduling via a persistent background service. This process can exit automatically after completing the token writing, without occupying system resources for an extended period. Atomic exclusive creation means that when multiple processes simultaneously attempt to create a lock file under the same path, the operating system guarantees that only one process can successfully create it, while the creation operations of the remaining processes will fail.

[0028] During implementation, each plugin periodically checks the expiration time of the token in the shared storage area. When the remaining validity period is lower than a preset threshold (e.g., 5 minutes), an update response is triggered. In another implementation, the authorization server can also include an indication that the authorization token is about to expire when returning or authorizing the shared authorization token. The plugin will then trigger an update response when the remaining validity period is lower than a preset threshold (e.g., 5 minutes).

[0029] In step S12, if the lock update process successfully preempts the lock, it obtains new token information and updates the shared authorization token based on the new token information.

[0030] For example, successful preemption means that when multiple plugins simultaneously attempt to create lock files under the same path, the operating system determines that the preempting plugin is the only successful creator, thus gaining cross-process mutual exclusion permissions. The plugin that successfully preempts is designated as the primary refresher, responsible for performing subsequent token acquisition and update operations. The new token information refers to the token obtained by the primary refresher plugin after initiating a token rotation request to the authorization server. Updating the shared authorization token means that the primary refresher encapsulates and encrypts the newly acquired token information according to a unified structure and writes it to the shared storage area to overwrite the original old token. This operation ensures that other plugins can obtain the latest token information when subsequently reading the shared storage area.

[0031] After successfully creating the lock file, the primary refresh plugin initiates a token rotation request to the authorization server. This method results in the shortest lock holding time, allowing other plugins to obtain new tokens as quickly as possible. The primary refresh plugin can also check whether the token in the shared storage area has been updated by other processes after creating the lock file. If it has, there's no need to initiate a rotation request; it can directly reuse the new token and release the lock, thus avoiding unnecessary token rotation requests and reducing the load on the authorization server.

[0032] The primary refresher plugin creates a lock file and gains the right to elect a master. However, during the time it sends a token rotation request to the authorization server and obtains a new token, due to network latency, scheduling delays, or other reasons, another plugin (e.g., through other synchronization mechanisms or abnormal recovery processes) may have already completed updating the authorization token and written it to the shared storage area. If the primary refresher does not perform any verification after obtaining the new token and directly overwrites the shared storage area based on its own new token, the following problems will occur: First, an older token may overwrite a newer token, causing a token version rollback; second, it may overwrite a valid token just written by another plugin, causing inconsistencies between the tokens cached locally by other plugins and the tokens in the shared storage area, leading to login state confusion. Therefore, in some embodiments, before updating the shared authorization token based on the new token information, the method further includes: verifying whether the identification information and version number of the new token information match the shared authorization token; if they match the shared authorization token, updating the shared authorization token based on the new token information; if they do not match the shared authorization token, releasing the update lock process and stopping the update of the shared authorization token.

[0033] For example, the identification information refers to the set of information used to uniquely identify the entity to which the token belongs. This information may include a client identifier (Client ID) and a user identifier (User ID), payload, expiration time, etc. The client identifier identifies the authorized client corresponding to the token, and the user identifier identifies the logged-in user corresponding to the token. The identification information can confirm whether a newly acquired token and a token in the shared storage area belong to the same client and the same user. The version number is a numerical value or string used to identify the iteration order of the authorization token. This version number can be generated by the authorization server when issuing the token and distributed along with it, or it can be generated incrementally by the primary refresher based on the existing version number in the shared storage area when writing the token. The higher the version number, the newer the token. By comparing the version numbers, it can be determined whether the token in the shared storage area has been updated.

[0034] In the implementation process, the authorization server can generate a monotonically increasing version number when issuing a token and distribute it as an additional field along with the token. This method ensures the version number is centrally managed by the authorization server, globally unique, and ordered, eliminating the need for individual plugins to maintain it. Alternatively, the main refresh plugin can read the current token's version number from the shared storage area when writing the token, increment it by one, and write this as the new token's version number. The advantage of this method is that it does not rely on additional support from the authorization server and is simple to implement.

[0035] The corresponding identifier and version number are parsed from the newly acquired authorization token information. The new identifier is compared with the identifier in the authorization token to be updated; and the new version number is compared with the version number corresponding to the authorization token to be updated. If the identifier is consistent and the new version number is a newly added version number of the authorization token to be updated, it is determined to be a match for the shared authorization token, and the authorization token is updated. If there is a mismatch between the identifier and the version number, the update token is abandoned and the update lock process is released to avoid confusion in the authorization token update.

[0036] During the authorization token update process, after successfully creating the lock file, the main refresh plugin may fail to complete the authorization token update operation for an extended period due to network anomalies, authorization server response timeouts, process suspension, or crashes. If the lock file is not released for a long time, other plugins will be unable to acquire the lock, causing the entire login state synchronization mechanism to stagnate. Therefore, in some embodiments, the method further includes: if the duration of the lock update process exceeds a preset duration threshold, then the lock update process is released.

[0037] After the primary refresh plugin completes token rotation and writes the new token information to the shared storage area, other plugins can detect the change in the shared storage area through listening or active polling. However, listening may fail to detect the change in time due to loss of operating system events; and the period of active polling may cause other plugins to still use the old authorization token cached locally for a long time, while the refresh token corresponding to the old authorization token has been abandoned by the authorization server, causing the protected resource access requests initiated by other plugins during this period to be rejected because the authorization token has expired. In addition, after other plugins detect the change, they still need to read, decrypt, and verify the new token information themselves, which introduces a certain processing delay. Therefore, in some embodiments, after updating the shared authorization token based on the new token information, the method further includes: sending the updated token information to multiple plugins so that multiple plugins can authorize login based on the updated shared authorization token after receiving the updated token information.

[0038] For example, during implementation, the main refresh plugin can send notification messages to other plugins via local inter-process communication (IPC) mechanisms (such as named pipes, local sockets, shared memory, etc.). These notification messages can use a triplet of "access token + refresh token + account identifier" as the updated token information. This allows the plugin receiving the updated token information to verify whether its current authorization token is the latest one. If it is not the latest authorization token, it updates the authorization token and logs out and logs in; if it is the latest authorization token, it maintains the logged-in status, avoiding repeated logouts and logins.

[0039] In step S13, if the lock update process fails to preempt, after monitoring the lock creation process to release the lock, the updated shared authorization token is read so that authorized login can be performed based on the updated shared authorization token.

[0040] For example, plugins that fail to acquire the lock cannot initiate a token rotation request to the authorization server. If these plugins do not take any action after failing to acquire the lock, they will not be able to detect whether the shared authorization token has been updated by the main refresher, nor will they be able to obtain a new token in a timely manner. If these plugins continue to use the old token cached locally, and the refresh token corresponding to the old token has been discarded by the authorization server, their subsequent authorization access requests will fail. In addition, if plugins that fail to acquire the lock repeatedly attempt to acquire the lock while waiting, it will cause unnecessary system overhead and resource consumption. Therefore, in this embodiment of the disclosure, if the lock update process fails to acquire the lock, after monitoring the lock creation process to release the lock process, the updated shared authorization token is read so that authorization login can be performed based on the updated shared authorization token, which reduces system overhead and resource consumption to a certain extent.

[0041] In the implementation, plugins that fail to acquire the lock detect the release of the lock file by listening for changes in the shared storage area. Alternatively, plugins that fail to acquire the lock detect the release of the lock file by periodically polling its existence.

[0042] In a multi-plugin login state synchronization scheme based on a shared storage area, each plug-in needs to be aware of changes to the shared authorization token in real time. However, simply being aware of the change is not enough to complete login state synchronization. Plug-ins also need to clearly define how to read and process the modified shared authorization token after sensing different types of change information (creation, modification, deletion). If the processing logic is unclear, it may lead to plug-ins still using the old token for authorization login when the shared authorization token is deleted, or failing to update the local session in a timely manner after the token is modified, resulting in inconsistent login states. Therefore, in some embodiments, the method further includes: responding to obtaining change information of the shared authorization token; the change information includes any one of creation, modification, and deletion; reading the modified shared authorization token based on the change information; and performing authorization login based on the modified shared authorization token.

[0043] For example, change information refers to events or signals indicating that the shared authorization token has changed. This information includes three types: creation (the shared authorization token is written to the shared storage area for the first time), modification (the shared authorization token is overwritten by a new token), and deletion (the shared authorization token is removed from the shared storage area). In implementation, change information can be obtained through passive event listening; that is, the plugin registers file system change events with the operating system, and the operating system actively notifies the plugin when the shared authorization token is created, modified, or deleted. The advantage of this method is its high real-time performance and fast response speed.

[0044] Another implementation method is to obtain change information through active polling. This involves the plugin periodically checking the last modification time or file status of the shared authorization token, generating change information upon detection, and verifying the changes. The advantage of this method is that it does not rely on the operating system's event notification mechanism, resulting in high reliability. However, the response speed depends on the polling cycle. For example, it periodically reads the attribute information of the shared authorization token from the shared storage space; the attribute information includes the operation time, operation type, and token identifier; it checks whether the attribute information of the current cycle has changed compared to the previous cycle; if the attribute information has changed, it verifies whether the shared authorization token of the current cycle is forged; based on the verification result, it determines the plugin's running status.

[0045] For example, attribute information refers to the metadata information of the shared authorization token, used to describe the token's operational status and identity. This information includes the operation time (the time when the most recent operation occurred), the operation type (create, modify, or delete), and the token identifier (a string or numerical value used to uniquely identify the token). Attribute information is usually stored in a fixed location in the shared storage area, with low read overhead. Current cycle / previous cycle refers to the time granularity of active polling. The current cycle refers to the moment of this polling, and the previous cycle refers to the moment of the last polling. The plugin records the attribute information currently read in each polling cycle and compares it with the attribute information recorded in the previous cycle. A forged token refers to a token that has not been issued by an authorized server, has been maliciously tampered with, or has been forged. Forged tokens may be written into the shared storage area by malware in an attempt to impersonate legitimate tokens. The process of verifying a forged token may include checking whether the token's digital signature, integrity check value (such as Message Authentication Code, MAC), issuer identifier, and client identifier (ClientID) are consistent with expectations. Running status: refers to the login state of the plugin after verification. This state can include maintaining the login state (the token is valid and unchanged, continue using the local cache), updating the login state (the token has changed and verification is successful, update the local session), performing a logout (the token has been deleted or verification failed, clear the local session), or ignoring the change (the token has changed but verification failed, neither update nor logout).

[0046] During implementation, the plugin compares the operation time, operation type, and token identifier in the old and new attribute information one by one. If any field changes, it is considered a change. The plugin verifies the digital signature of the token, that is, it uses the public key of the authorization server to decrypt the signature part in the token and compares it with the hash value of the token payload. If they match, it is considered a valid token. The plugin directly maps the verification result to the running state: verification passed and token identifier changed → update login state; verification passed and token identifier unchanged → maintain login state; verification failed → ignore change; operation type is deletion → log out.

[0047] In a multi-plugin login state synchronization scheme based on a shared storage area, a plug-in cannot directly trust the shared authorization token after sensing a change, because the shared storage area may be written with forged data by malware, or the token file may be corrupted due to write interruption. Without a systematic verification process, the following problems may occur: First, directly attempting to decrypt data in an unexpected format may lead to parsing errors or program crashes; second, using tokens from other applications or clients may cause identity confusion; third, using expired tokens for authorized access may result in request failure. Therefore, in some embodiments, verifying whether the shared authorization token for the current period is forged includes: verifying whether the shared authorization token for the current period conforms to the target format of the ciphertext to be decrypted; if the shared authorization token for the current period is the target format of the ciphertext to be decrypted, then decrypting the ciphertext to be decrypted to obtain the client identifier of the shared authorization token for the current period; if the client identifier verification passes, verifying whether the authorization time has expired; if the authorization time has expired, it is a forged token; if the authorization time has not expired, it is not a forged token.

[0048] For example, the target format refers to the pre-agreed encoded structure of the ciphertext to be decrypted. This format may include fields such as a format version number, encryption algorithm identifier, initialization vector (IV), ciphertext body, and integrity check value (e.g., Message Authentication Code, MAC). Ciphertext conforming to the target format can be correctly identified and processed by the decryption module. The ciphertext to be decrypted refers to the encrypted token data stored in the shared storage area. In its undecrypted state, this data is unreadable binary or encoded text data. Only ciphertext conforming to the target format will proceed to the subsequent decryption process.

[0049] If the token does not conform to the target format, it is directly determined as an incompatible change. Neither the local session is updated nor a logout is performed; only the change is logged and ignored. If the token does not conform to the target format and appears multiple times consecutively, it is determined that the shared storage area may have been maliciously tampered with. A security alert may be triggered, and the user may be advised to log in again. The decrypted client identifier is precisely compared with the identifier of the unified authorization client currently used by the plugin. If they match completely, the verification is considered successful. The plugin reads the expiration time field from the token payload and compares it with the current system time. If the current time has exceeded the expiration time, the authorization period has expired.

[0050] In some embodiments, if the verification result is successful, authorization login is performed based on the shared authorization token of the current period; if the verification result is unsuccessful, and the client identifier verification fails or the authorization time expires, the plugin's authorization token is not updated.

[0051] For example, a verification result of "pass" means that the shared authorization token for the current period has passed all verification steps in sequence: format verification, client identifier verification, and authorization time verification. A verification result of "fail" means that the shared authorization token for the current period failed at any verification step or the authorization token does not exist (has been deleted).

[0052] In response to verification failures, in this embodiment of the disclosure, if an authorization token exists but any verification step fails, the plugin can neither update the authorization token nor perform a logout operation, and continue to retain the original conversation; if the authorization token does not exist, a logout operation can be performed.

[0053] The authorization token management method for multiple plugins provided in this disclosure is applied to any one of multiple plugins. The shared authorization tokens of the multiple plugins are stored in a shared storage space. In response to the detection of an update response to the shared authorization token, the method creates an update lock process, where the update response indicates that a new shared authorization token needs to be written. If the update lock process successfully preempts the lock, it obtains the new token information and updates the shared authorization token based on the new token information. If the update lock process fails to preempt the lock, after monitoring the release of the lock process by an already created lock process, it reads the updated shared authorization token to perform authorization login based on the updated shared authorization token. In the absence of preemption of the update lock process, authorization login is performed based on the updated shared authorization token in the already created lock process after the lock process is released. This avoids the problem of wasted computing resources caused by constantly refreshing and preempting the lock process. Through the above-mentioned lock process preemption mechanism, this disclosure, to a certain extent, avoids simultaneous read and write operations by multiple plugins, thereby reducing data conflicts.

[0054] Corresponding to the above implementation methods for managing authorization tokens across multiple plugins, this disclosure also provides an apparatus for managing authorization tokens across multiple plugins. This apparatus is used to execute the above-described methods. Figure 1 A multi-plugin authorization token management method illustrated in any of the embodiments. For example... Figure 2 As shown, the authorization token is applied to any one of multiple plugins, and the shared authorization tokens of the multiple plugins are stored in a shared storage space. The authorization token management device for the multiple plugins includes: The process creation module 201 is used to create an update lock process in response to detecting an update response of the shared authorization token; the update response refers to the need to write a new shared authorization token. The update module 202 is used to obtain new token information and update the shared authorization token based on the new token information if the update lock process successfully preempts it. The waiting module 203 is used to read the updated shared authorization token after monitoring the lock creation process to release the lock process if the update lock process fails to preempt it, so as to perform authorized login based on the updated shared authorization token.

[0055] The multi-plugin authorization token management device and the multi-plugin authorization token management method provided in the above embodiments of this disclosure are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0056] This disclosure also provides an electronic device for performing the above-described data transmission method. Please refer to... Figure 3 This illustrates a schematic diagram of an electronic device provided by some embodiments of the present disclosure. For example... Figure 3 As shown, the electronic device includes: a processor 300, a memory 301, a bus 302, and a communication interface 303. The processor 300, the communication interface 303, and the memory 301 are connected via the bus 302. The memory 301 stores a computer program that can run on the processor 300. When the processor 300 runs the computer program, it executes the aforementioned provisions of this disclosure. Figure 1 The method provided by any of the illustrated embodiments.

[0057] The memory 301 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 303 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0058] Bus 302 can be an ISA bus, PCI bus, or EISA bus, etc. Buses can be divided into address buses, data buses, control buses, etc. Memory 301 is used to store programs; after receiving execution instructions, processor 300 executes the program, as described above. Figure 1 The method disclosed in any of the illustrative embodiments can be applied to or implemented by the processor 300.

[0059] The processor 300 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 300 or by instructions in software form. The processor 300 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 301. The processor 300 reads the information in memory 301 and, in conjunction with its hardware, completes the steps of the above method.

[0060] The electronic device and the data transmission method provided in this disclosure are based on the same inventive concept and have the same beneficial effects as the methods they employ, operate, or implement.

[0061] This disclosure also provides a computer-readable storage medium corresponding to the data transmission method provided in the foregoing embodiments. Please refer to... Figure 4 The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored. When the computer program is run by the microprocessor, it executes the data transmission method provided in any of the aforementioned embodiments.

[0062] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0063] The computer-readable storage medium provided in the above embodiments of this disclosure and the data transmission method provided in the embodiments of this disclosure are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0064] It should be noted that: Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this disclosure may be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0065] Similarly, it should be understood that, in order to simplify this disclosure and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this disclosure, various features of this disclosure are sometimes grouped together in a single embodiment, figure, or description thereof. However, this approach to disclosure should not be construed as reflecting a schematic diagram in which the claimed disclosure requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this disclosure.

[0066] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this disclosure and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0067] The above are merely preferred embodiments of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for managing authorization tokens across multiple plugins, characterized in that, The method applies to any one of multiple plugins, wherein the shared authorization token of the multiple plugins is stored in a shared storage space, and the method includes: In response to the detection of an update response to the shared authorization token, an update lock process is created; the update response refers to the need to write a new shared authorization token. If the lock update process successfully preempts, it obtains new token information and updates the shared authorization token based on the new token information; If the lock update process fails to preempt, after monitoring the lock creation process to release the lock, the updated shared authorization token is read so that authorized login can be performed based on the updated shared authorization token.

2. The method according to claim 1, characterized in that, Before updating the shared authorization token based on the new token information, the method further includes: Verify whether the identification information and version number of the new token information match the shared authorization token; If it matches the shared authorization token, then update the shared authorization token based on the new token information; If the shared authorization token does not match, the update lock process is released and stops updating the shared authorization token.

3. The method according to claim 1, characterized in that, The method further includes: If the duration of the update lock process exceeds a preset duration threshold, the update lock process is released.

4. The method according to claim 1, characterized in that, The method further includes: In response to receiving change information about the shared authorization token; the change information includes any one of creation, modification, and deletion; Based on the changed information, the modified shared authorization token is read, and authorized login is performed based on the modified shared authorization token.

5. The method according to claim 1, characterized in that, The method further includes: The attribute information of the shared authorization token is periodically read from the shared storage space; the attribute information includes operation time, operation type, and token identifier. Detect whether the attribute information of the current period has changed compared with the attribute information of the previous period; In the event of a change in attribute information, verify whether the shared authorization token for the current period is a forged token; Based on the verification results, the running status of the plugin is determined.

6. The method according to claim 5, characterized in that, The verification of whether the shared authorization token for the current period is forged includes: Verify whether the shared authorization token of the current period conforms to the target format of the ciphertext to be decrypted; If the shared authorization token of the current period is a ciphertext to be decrypted that conforms to the target format, then the ciphertext to be decrypted is decrypted to obtain the client identifier of the shared authorization token of the current period; If the client identifier verification is successful, the system checks whether the authorization period has expired. If the authorization period has expired, the token is considered forged; if the authorization period has not expired, the token is not forged.

7. The method according to claim 6, characterized in that, Determining the running status of the plugin based on the verification results includes: If the verification result is successful, authorized login is performed based on the shared authorization token for the current period; If the verification result is unsuccessful, and the client identifier verification fails or the authorization period expires, the plugin's authorization token will not be updated.

8. The method according to claim 1, characterized in that, After updating the shared authorization token based on the new token information, the method further includes: The updated token information is sent to the multiple plugins so that the multiple plugins can authorize login based on the updated shared authorization token after receiving the updated token information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The computer program is executed by the processor to cause the electronic device to perform the method as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by a processor to implement the method as described in any one of claims 1-8.

Images