API key management method and device based on frequency and time

Abstract

In the embodiment of the present invention, a frequency- and time-based API key management method, device and electronic device are provided, which belong to the field of data processing technology. The method includes: storing the basic data of all API keys in a database DB, and dynamically storing the keys and their dynamic data in a cache HC through a minimum heap data structure HD; selecting a first key KF for a service request from the minimum heap data structure HD of the cache HC according to the dynamic data; after obtaining the first key KF, checking the current state of the first key KF to obtain an updated second key KS; performing a temporary offline operation on the second key KS according to the state of the second key KS; determining the maximum number of requests NA allowed by the second key KS according to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time. The present invention improves the balance and flexibility of API key distribution.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a frequency- and time-based API key management method, device, and electronic device. Background Art

[0002] An API key is a credential used to identify and authorize access to an API. It is like a "key" that allows a software application or service to access the functions and data contained in an API provided by another application with authorization. An API key is usually a string of letters, numbers, and special characters. The specific format and length depends on the design of the API provider. Some API keys may also contain other information such as version number and user ID to provide more precise access control.

[0003] API keys ensure that only authorized users or applications can access the API. Without effective key management, malicious attackers may obtain keys and abuse the API, which may lead to data leakage, service interruption or other security issues. By assigning different API keys to different users or applications, the access level to the API can be precisely controlled according to business needs and user permissions.

[0004] The existing technology has the following defects in the process of API key management:

[0005] 1. Chaotic usage and unmanageable

[0006] In many enterprises or development projects, there may be multiple different teams, business departments, or applications developed at different times that use API keys, but there is a lack of unified specifications and coordination mechanisms for the acquisition, storage, and use of these keys. For example, some teams hard-code API keys directly in the code, while others store them in configuration files, with different formats and names, resulting in a decentralized and disordered management of API keys within the entire organization.

[0007] This chaotic usage increases the risk of key leakage because decentralized management makes it difficult to ensure that each storage and usage link follows security best practices. For example, it is difficult to ensure that all hard-coded keys are under secure code version control. Once the code is leaked, the keys are also exposed.

[0008] 2. Poor maintainability and inability to expand keys in a timely manner

[0009] As the business develops, the application's demand for API access may continue to increase, and the number of API keys needs to be expanded accordingly to meet the access needs of more users, different business scenarios, or new functional modules. However, existing technologies often do not have a convenient and efficient mechanism to quickly generate and distribute new API keys. For example, it may be necessary to manually perform tedious addition operations in multiple different configuration files or database tables, and it is also necessary to manually associate the new key with the corresponding user or business permissions. This process is prone to errors and time-consuming. When the API provider updates the relevant rules for the key (such as requiring an increase in the key length, a change in the format, etc.), it is difficult to make corresponding adjustments and adaptations to the large number of existing keys in a timely manner, which may cause some API calls to fail, affecting the normal development of the business.

[0010] Failure to expand keys in a timely manner will hinder the expansion of new businesses and the access of new users, affecting the company's development speed and market competitiveness. For example, an e-commerce platform wants to access a new logistics query API to provide users with better services, but the function cannot be launched on time because it cannot quickly obtain and configure new API keys. Failure to adjust keys in a timely manner according to API provider rule changes may cause errors in a large number of business processes that rely on the API, reduce system stability and user experience, and may even cause some functions to be unable to be used normally for a long time.

[0011] 3. No state management, low usage

[0012] In many cases, there is a lack of clear recording and tracking mechanisms for whether API keys are in different states such as available, disabled, or expired. For example, when a business cooperation ends, the corresponding API key should theoretically be disabled, but due to the lack of status management, the key may still remain in the system and may still be called by mistake, or when the key has expired, the relevant personnel are not reminded to update or process it in time, resulting in API call failure. Without effective statistics and analysis of the use of keys (such as frequency of use, usage time, associated business modules, etc.), it is impossible to know which keys are used frequently and which are almost not used, making it difficult to reasonably allocate and optimize key resources according to actual business needs.

[0013] Since the usage rate of keys is unclear, there may be a large number of keys that have been allocated but rarely used, occupying system resources, increasing management costs without playing a corresponding role, resulting in a waste of resources.

[0014] 4. Lack of self-recovery and frequency limiting measures

[0015] When faced with some unexpected situations, such as incorrect key configuration, brief network failure affecting key verification, etc., which lead to API call failure, the system lacks an automatic recovery mechanism to try to re-verify the key or take other remedial measures. Manual intervention is often required to troubleshoot and solve the problem, resulting in a long fault recovery time and affecting the timeliness of the business.

[0016] Without effective frequency limiting measures to constrain the frequency of API key usage, a key may be called frequently in a short period of time, exceeding the API provider's limits or causing excessive pressure on system resources. It may even be used by malicious attackers to perform brute force attacks, and the system cannot automatically intercept and limit it.

[0017] The above problems become technical problems that need to be solved. Summary of the invention

[0018] In view of this, an embodiment of the present invention provides a frequency- and time-based API key management method, device, and electronic device, which at least partially solve the problems existing in the prior art.

[0019] In a first aspect, an embodiment of the present invention provides a frequency and time-based API key management method, including:

[0020] The basic data of all API keys are stored in the database DB, and the keys and their dynamic data are dynamically stored in the cache HC through the minimum heap data structure HD;

[0021] According to the dynamic data, a first key KF for serving the request is selected from a minimum heap data structure HD of the cache HC;

[0022] After obtaining the first key KF, the current state of the first key KF is checked. If the first key KF is used normally, the usage and usage time of the first key KF are updated. If the first key KF is abnormal, the interface is called to update the state of the first key KF and send relevant alarm information to the monitoring system to obtain the updated second key KS;

[0023] According to the state of the second key KS, the second key KS is temporarily offlined, and according to a preset time period, it is determined whether the second key KS after being temporarily offline has reached the upper limit of usage, and if so, the number of times of usage of the second key KS is automatically reset;

[0024] According to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ to the API interface by the second key KS per unit time, the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS is determined, where min() is the minimum function and Tc is the unit time window length, indicating the time period of rate limitation.

[0025] According to a specific implementation of an embodiment of the present invention, the basic data of all API keys are stored in a database DB, and the keys and their dynamic data are dynamically stored in a cache HC through a minimum heap data structure HD, including:

[0026] Determine the API key basic data fields that need to be stored;

[0027] Use the database table creation statement to create a table for storing API key basic data according to the designed table structure;

[0028] When generating a new API key or importing an existing API key, write the corresponding code logic in the application to assemble the API key and its corresponding basic data into data records according to the table structure requirements;

[0029] Perform an insert operation through the database connection object to insert the data record into the API key basic data table created previously;

[0030] Write SQL statements to query API key basic data based on different conditions, execute the query statements in the application and process the returned result sets;

[0031] When the basic data of the API key changes, write an UPDATE statement to locate the record that needs to be updated according to the conditions and update the value of the corresponding field;

[0032] When you need to delete the basic data of an API key, write a DELETE FROM statement to delete the corresponding records according to the preset conditions.

[0033] According to a specific implementation of an embodiment of the present invention, the basic data of all API keys are stored in a database DB, and the keys and their dynamic data are dynamically stored in a cache HC through a minimum heap data structure HD, and further includes:

[0034] After selecting the cache system, configure the connection parameters of the cache system and initialize the connection object with the cache HC in the application;

[0035] Create a class that represents a minimum heap node. The node class contains at least member variables for storing API key related information and related properties for building a minimum heap structure.

[0036] Implement the corresponding constructor to initialize the node object, as well as methods to get and set the values ​​of each node attribute;

[0037] Write logic to insert a new node containing the API key and its dynamic data into the min-heap. During the insertion, according to the characteristics of the min-heap, the node position is adjusted to maintain the min-heap structure by comparing the values ​​of the newly inserted node with the existing nodes.

[0038] After swapping the top node with the last node, delete the last node, and then adjust the heap structure downward from the top of the heap. Compare the values ​​of the current node and the child nodes. If they do not meet the minimum heap condition, swap their positions. Continue adjusting until the entire heap meets the minimum heap property again.

[0039] If the dynamic data of the API key changes, delete the original node first and then reinsert the updated node;

[0040] When you need to add the API key and its dynamic data to the cached minimum heap, first build the corresponding minimum heap node, then use the interface provided by the cache system to store the node data in the cache, and call the minimum heap insertion operation method to maintain the correctness of the minimum heap structure in the cache;

[0041] When the minimum node in the minimum heap needs to be obtained, the top node data of the heap is read from the cache and processed according to the needs. If the dynamic data changes after processing, the update node operation method is called to update the minimum heap structure in the cache;

[0042] When the API key no longer needs to be maintained in the cache, the corresponding minimum heap node data is deleted from the cache, and the minimum heap delete minimum node operation method is called to adjust the minimum heap structure of the remaining nodes.

[0043] According to a specific implementation of the embodiment of the present invention, selecting a first key KF for a service request from a minimum heap data structure HD of a cache HC according to the dynamic data includes:

[0044] Determine the top element of the minimum heap data structure HD according to the dynamic data;

[0045] After determining the top element of the heap, the value of the key field is obtained through the access method and assigned to the first key KF.

[0046] According to a specific implementation of the embodiment of the present invention, after acquiring the first key KF, checking the current state of the first key KF includes:

[0047] Check whether the key format meets the preset requirements, including whether the key length is correct and whether it contains specific character combinations;

[0048] Verify its validity by comparing it with pre-stored legitimate key characteristics or associated information;

[0049] After recording the usage information of the key used this time, obtain the current timestamp and update the timestamp to the field recording the most recent usage time in the storage key attribute;

[0050] After the usage and usage time are updated, if the first key KF is in a normal state and the attributes have been updated, the updated first key KF is directly assigned to the second key KS;

[0051] If an abnormality occurs in the first key KF, an interface specifically used for updating the key status is called, the identification information of the first key KF and a detailed description of the abnormal status are passed to the interface, and an alarm message body containing key KF related information is constructed, and the alarm message is sent to the monitoring system through the communication interface connected to the monitoring system.

[0052] According to a specific implementation of the embodiment of the present invention, the temporarily offline operation of the second key KS according to the state of the second key KS includes:

[0053] In the key management system, by recording the field of the key status, the status flag corresponding to the second key KS is modified to be temporarily offline;

[0054] At each service interface that relies on the key for operation, when it is detected that the key to be used is the second key KS that is temporarily offline, subsequent calling operations on the second key KS are blocked.

[0055] According to a specific implementation of an embodiment of the present invention, judging whether the second key KS after the temporary offline has reached the upper limit of usage according to a preset time period, and if so, automatically resetting the number of times the second key KS is used, includes:

[0056] The obtained cumulative usage times are compared with the preset usage upper limit value. If the cumulative usage times are greater than or equal to the preset usage upper limit, it is determined that the second key KS has reached the usage upper limit;

[0057] When it is determined through the above judgment that the second key KS has reached the upper limit of usage, the number of times the second key KS is used is reset to 0 in the database table storing information related to the number of times the key is used.

[0058] According to a specific implementation of an embodiment of the present invention, the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS is determined according to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time, including:

[0059] Set t to the current usage time from the last key reset, n(t) represents the number of requests for the second key KS initiated by time t, r(t) represents the weight coefficient dynamically calculated based on system load and security risk at time t, f(t) represents the request frequency correction function related to time t, λ(t) represents the key importance coefficient based on key usage history data and current system environment analysis, ω(t) represents the interference factor affected by the external network environment, g(t) represents the service peak characteristic function corresponding to time t, and h(t) represents the security constraint function based on security audit results and potential risk prediction;

[0060] Based on the weight coefficient r(t), the request frequency correction function f(t), the key importance coefficient λ(t), and the interference factor ω(t), the maximum number of requests per unit time NQ is dynamically adjusted to obtain the adjusted maximum number of requests per unit time NQ'(t):

[0061]

[0062] Based on the further impact of the business peak characteristic function g(t) on the adjusted maximum number of requests per unit time, the adjusted maximum number of requests per unit time NQ''(t) is obtained:

[0063]

[0064] Based on the remaining time in the current time window Tc being Tc-t, the maximum number of requests per unit time NQ''(t) after re-adjustment and the safety constraint function h(t) are used to calculate the maximum number of requests M(t) in the remaining time:

[0065]

[0066] Defining functions It represents the sum of the number of requests initiated in the entire time window Tc and the maximum number of requests in the remaining time up to the current time t. The calculation formula is as follows:

[0067]

[0068] Determine the maximum number of requests NA allowed by the second key KS, and the calculation formula is:

[0069] .

[0070] In a second aspect, an embodiment of the present invention further provides an API key management device based on frequency and time, including:

[0071] The storage module stores the basic data of all API keys in the database DB, and dynamically stores the keys and their dynamic data in the cache HC through the minimum heap data structure HD;

[0072] A selection module, which selects a first key KF for the service request from a minimum heap data structure HD of the cache HC according to the dynamic data;

[0073] The inspection module, after acquiring the first key KF, inspects the current state of the first key KF. If the first key KF is used normally, the usage and usage time of the first key KF are updated. If the first key KF is abnormal, the interface is called to update the state of the first key KF and send relevant alarm information to the monitoring system to obtain the updated second key KS.

[0074] A reset module temporarily offlines the second key KS according to the state of the second key KS, and determines whether the second key KS after the temporary offline operation has reached the upper limit of usage according to a preset time period, and if so, automatically resets the number of times the second key KS is used;

[0075] The determination module determines the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS according to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time, where min() is the minimum function and Tc is the unit time window length, indicating the time period of rate limitation.

[0076] In a third aspect, an embodiment of the present invention further provides an electronic device, the electronic device comprising:

[0077] at least one processor; and,

[0078] a memory communicatively connected to the at least one processor; wherein,

[0079] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method described in any of the first aspects or any of the implementations of the first aspect.

[0080] In a fourth aspect, an embodiment of the present invention further provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable the computer to execute the method described in the first aspect or any implementation of the first aspect.

[0081] In the fifth aspect, an embodiment of the present invention further provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer executes the method described in the first aspect or any implementation of the first aspect.

[0082] The scheme in the embodiment of the present invention includes: storing the basic data of all API keys in a database DB, and dynamically storing the keys and their dynamic data in a cache HC through a minimum heap data structure HD; selecting a first key KF for a service request from the minimum heap data structure HD of the cache HC according to the dynamic data; after obtaining the first key KF, checking the current state of the first key KF, if the first key KF is used normally, updating the usage and usage time of the first key KF, if the first key KF is abnormal, calling an interface to update the state of the first key KF and sending relevant alarm information to a monitoring system to obtain an updated second key KS; according to the state of the second key KS, temporarily offline the second key KS, judging whether the second key KS after the temporary offline has reached the usage upper limit according to a preset time period, and if so, automatically resetting the number of uses of the second key KS; according to the maximum allowed number of calls NC assigned to the second key KS after the automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time, determining the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS , min() is the minimum function, Tc is the unit time window length, indicating the time period of rate limitation. This solution has the following beneficial effects:

[0083] 1) Efficient load balancing: By using factors such as the number of times used, margin, and usage time as selection criteria, a more reasonable and balanced API key distribution is achieved.

[0084] 2) Automated adaptability: Based on the defined reset and status adjustment rules, the flexibility and availability of the system are improved.

[0085] 3) Complete state management: By tracking the use of API keys, key status is managed to improve the reliability and scalability of the system.

[0086] 4) Real-time performance monitoring: Through monitoring and alarm mechanisms, more timely and accurate updates on system status can be obtained.

[0087] 5) Strong versatility: The designed algorithms and data structures can be applied to various API key management scenarios and have a wide range of application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0089] Figure 1 A flowchart of a frequency and time-based API key management method provided by an embodiment of the present invention;

[0090] Figure 2 A flowchart of another method for managing API keys based on frequency and time provided in an embodiment of the present invention;

[0091] Figure 3 A schematic diagram of the structure of an API key management device based on frequency and time provided in an embodiment of the present invention;

[0092] Figure 4 A schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0093] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0094] The following describes the embodiments of the present disclosure through specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present disclosure.

[0095] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0096] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The drawings only show components related to the present disclosure rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0097] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects described may be practiced without these specific details.

[0098] The disclosed embodiment provides a frequency and time-based API key management method. The frequency and time-based API key management method provided in this embodiment can be executed by a computing device, which can be implemented as software, or as a combination of software and hardware, and the computing device can be integrated in a server, terminal device, etc.

[0099] See also Figure 1 and Figure 2 The present disclosure provides a frequency and time-based API key management method, including:

[0100] S101, storing the basic data of all API keys in the database DB, and dynamically storing the keys and their dynamic data in the cache HC through the minimum heap data structure HD.

[0101] The basic data of all API keys are stored in the database DB. The basic data here covers key information such as the unique identifier of the key (such as the key ID), the string content of the key itself (usually encrypted and stored to ensure security), the user or application information corresponding to the key, the creation time, the initial permission settings, etc. As a persistent storage medium, the database can ensure the long-term and reliable storage of these basic data, which is convenient for subsequent query, update, and audit operations.

[0102] Cache HC and minimum heap data structure HD to store dynamic data: Cache HC is used at the same time, and the minimum heap data structure HD is used in it to dynamically store keys and their related dynamic data. The introduction of cache is mainly to improve the access speed of data and reduce the performance overhead caused by frequent reading of data from the database. The minimum heap data structure has specific advantages. For example, keys and their dynamic data can be sorted and stored according to certain pre-set rules (such as "priority" measured by factors such as recent use time and frequency of use), which facilitates quick positioning and acquisition of keys that meet specific conditions, so that subsequent service requests to obtain keys can efficiently select appropriate keys.

[0103] S102: Select a first key KF for the service request from a minimum heap data structure HD of the cache HC according to the dynamic data.

[0104] The first key KF for the service request is selected from the minimum heap data structure HD in the cache HC, and the selection is based on the dynamic data previously stored in the minimum heap. These dynamic data can reflect the current activity, importance, or other characteristics related to the adaptability of the key to the service request. For example, if the dynamic data records the most recent use time of each key, according to the characteristics of the minimum heap (the value of the parent node is less than or equal to the value of the child node, which corresponds to a better "selection priority"), then the key with an earlier recent use time (that is, it has not been used for a relatively long time) will be selected first to achieve the purpose of balanced key use.

[0105] Through this selection method, it is ensured that the selected first key KF can better adapt to the current service request scenario, improve the efficiency and rationality of the overall API call, avoid always using a few fixed keys, and dynamically allocate key resources according to the actual business operation situation.

[0106] S103, after obtaining the first key KF, check the current status of the first key KF. If the first key KF is used normally, update the usage and usage time of the first key KF. If the first key KF is abnormal, call the interface to update the status of the first key KF and send relevant alarm information to the monitoring system to obtain the updated second key KS.

[0107] Under normal use, after obtaining the first key KF, first check its current status. If the first key KF is in normal use, it means that the key can continue to effectively participate in service request operations, and then update its usage and usage time. Updating usage helps to count the frequency of use of the key in the business, thereby providing a data basis for subsequent operations such as determining whether the usage limit has been reached; updating usage time can record its latest usage, which is convenient for subsequent operations such as activity analysis and key rotation decisions based on the time dimension.

[0108] If the first key KF has an abnormality, such as verification failure, abnormal access mode detection, or errors in interaction with the API server, it is necessary to call a special interface to update the status of the key, such as marking it as "abnormal", "unavailable", etc., and send relevant alarm information to the monitoring system. After the monitoring system receives the alarm information, the operation and maintenance personnel or relevant management personnel can know and intervene in troubleshooting in time, take corresponding measures, and finally obtain the updated second key KS to ensure that subsequent service requests can continue to be based on the key in a reasonable state.

[0109] S104, according to the state of the second key KS, temporarily offline the second key KS, and determine whether the second key KS after being temporarily offline has reached the usage upper limit according to a preset time period. If so, automatically reset the usage count of the second key KS.

[0110] The decision on whether to temporarily shut down the second key KS is based on its status, which takes into account many factors, such as whether there have been multiple anomalies but it has not been completely confirmed to be unavailable, whether there are potential risks in the current system operating environment, etc. The temporary offline operation is intended to suspend the use of the key in some uncertain or potentially dangerous situations to avoid larger problems, such as data leakage or service failure.

[0111] After the temporary offline is executed, the preset time period is used to determine whether the key has reached the usage limit. The preset time period here is a time period pre-set according to business needs and key management policies. By comparing the cumulative number of times the key is used during this time period with the specified usage limit, if the limit has been reached, the number of uses is automatically reset. Automatic reset allows the key to continue to play a role in subsequent business, re-participate in service requests under the premise of complying with security and usage rules, and realize the recycling and effective management of key resources.

[0112] S105, based on the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ to the API interface by the second key KS per unit time, determine the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS, where min() is the minimum function, and Tc is the unit time window length, indicating the time period of rate limitation.

[0113] According to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ for the key to the API interface per unit time, the maximum number of requests NA allowed for the second key KS is determined by the formula NA=min(NC,NQ⋅Tc). Two levels of restrictions are considered here. On the one hand, the overall control of the number of times the key is used throughout the life cycle (reflected by NC) prevents excessive use from causing a decrease in key security or non-compliance with business regulations; on the other hand, the frequency of key use per unit time (reflected by NQ and Tc) is limited to avoid excessive use of keys in a short period of time, which may cause excessive pressure on system resources or security risks.

[0114] The minimum function min() is used to take the smaller value of the two as the final maximum number of requests NA. More stringent restrictions can be followed, whether it is the overall number limit or the frequency limit per unit time. As long as one of the conditions reaches the upper limit, the number of requests cannot be increased. This ensures the security and rationality of the use of API keys and meets the overall requirements of business operations.

[0115] Steps S101-S105 construct a relatively complete and detailed API key management process, which regulates multiple aspects from data storage, key selection, state management to usage restrictions, etc., which helps to solve some defects in the existing technology in API key management and improve the security, efficiency and maintainability of key management.

[0116] According to a specific implementation of an embodiment of the present invention, the basic data of all API keys are stored in a database DB, and the keys and their dynamic data are dynamically stored in a cache HC through a minimum heap data structure HD, including:

[0117] Determine the API key basic data fields that need to be stored;

[0118] Use the database table creation statement to create a table for storing API key basic data according to the designed table structure;

[0119] When generating a new API key or importing an existing API key, write the corresponding code logic in the application to assemble the API key and its corresponding basic data into data records according to the table structure requirements;

[0120] Perform an insert operation through the database connection object to insert the data record into the API key basic data table created previously;

[0121] Write SQL statements to query API key basic data based on different conditions, execute the query statements in the application and process the returned result sets;

[0122] When the basic data of the API key changes, write an UPDATE statement to locate the record that needs to be updated according to the conditions and update the value of the corresponding field;

[0123] When you need to delete the basic data of an API key, write a DELETE FROM statement to delete the corresponding records according to the preset conditions.

[0124] According to a specific implementation of an embodiment of the present invention, the basic data of all API keys are stored in a database DB, and the keys and their dynamic data are dynamically stored in a cache HC through a minimum heap data structure HD, and further includes:

[0125] After selecting the cache system, configure the connection parameters of the cache system and initialize the connection object with the cache HC in the application;

[0126] Create a class that represents a minimum heap node. The node class contains at least member variables for storing API key related information and related properties for building a minimum heap structure.

[0127] Implement the corresponding constructor to initialize the node object, as well as methods to get and set the values ​​of each node attribute;

[0128] Write logic to insert a new node containing the API key and its dynamic data into the min-heap. During the insertion, according to the characteristics of the min-heap, the node position is adjusted to maintain the min-heap structure by comparing the values ​​of the newly inserted node with the existing nodes.

[0129] After swapping the top node with the last node, delete the last node, and then adjust the heap structure downward from the top of the heap. Compare the values ​​of the current node and the child nodes. If they do not meet the minimum heap condition, swap their positions. Continue adjusting until the entire heap meets the minimum heap property again.

[0130] If the dynamic data of the API key changes, delete the original node first and then reinsert the updated node;

[0131] When you need to add the API key and its dynamic data to the cached minimum heap, first build the corresponding minimum heap node, then use the interface provided by the cache system to store the node data in the cache, and call the minimum heap insertion operation method to maintain the correctness of the minimum heap structure in the cache;

[0132] When the minimum node in the minimum heap needs to be obtained, the top node data of the heap is read from the cache and processed according to the needs. If the dynamic data changes after processing, the update node operation method is called to update the minimum heap structure in the cache;

[0133] When the API key no longer needs to be maintained in the cache, the corresponding minimum heap node data is deleted from the cache, and the minimum heap delete minimum node operation method is called to adjust the minimum heap structure of the remaining nodes.

[0134] According to a specific implementation of the embodiment of the present invention, selecting a first key KF for a service request from a minimum heap data structure HD of a cache HC according to the dynamic data includes:

[0135] Determine the top element of the minimum heap data structure HD according to the dynamic data;

[0136] After determining the top element of the heap, the value of the key field is obtained through the access method and assigned to the first key KF.

[0137] According to a specific implementation of the embodiment of the present invention, after acquiring the first key KF, checking the current state of the first key KF includes:

[0138] Check whether the key format meets the preset requirements, including whether the key length is correct and whether it contains specific character combinations;

[0139] Verify its validity by comparing it with pre-stored legitimate key characteristics or associated information;

[0140] After recording the usage information of the key used this time, obtain the current timestamp and update the timestamp to the field recording the most recent usage time in the storage key attribute;

[0141] After the usage and usage time are updated, if the first key KF is in a normal state and the attributes have been updated, the updated first key KF is directly assigned to the second key KS;

[0142] If an abnormality occurs in the first key KF, an interface specifically used for updating the key status is called, the identification information of the first key KF and a detailed description of the abnormal status are passed to the interface, and an alarm message body containing key KF related information is constructed, and the alarm message is sent to the monitoring system through the communication interface connected to the monitoring system.

[0143] According to a specific implementation of the embodiment of the present invention, the temporarily offline operation of the second key KS according to the state of the second key KS includes:

[0144] In the key management system, by recording the field of the key status, the status flag corresponding to the second key KS is modified to be temporarily offline;

[0145] At each service interface that relies on the key for operation, when it is detected that the key to be used is the second key KS that is temporarily offline, subsequent calling operations on the second key KS are blocked.

[0146] According to a specific implementation of an embodiment of the present invention, judging whether the second key KS after the temporary offline has reached the upper limit of usage according to a preset time period, and if so, automatically resetting the number of times the second key KS is used, includes:

[0147] The obtained cumulative usage times are compared with the preset usage upper limit value. If the cumulative usage times are greater than or equal to the preset usage upper limit, it is determined that the second key KS has reached the usage upper limit;

[0148] When it is determined through the above judgment that the second key KS has reached the upper limit of usage, the number of times the second key KS is used is reset to 0 in the database table storing information related to the number of times the key is used.

[0149] According to a specific implementation of an embodiment of the present invention, the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS is determined according to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time, including:

[0150] Set t to the current usage time from the last key reset, n(t) represents the number of requests for the second key KS initiated by time t, r(t) represents the weight coefficient dynamically calculated based on system load and security risk at time t, f(t) represents the request frequency correction function related to time t, λ(t) represents the key importance coefficient based on key usage history data and current system environment analysis, ω(t) represents the interference factor affected by the external network environment, g(t) represents the service peak characteristic function corresponding to time t, and h(t) represents the security constraint function based on security audit results and potential risk prediction;

[0151] Based on the weight coefficient r(t), the request frequency correction function f(t), the key importance coefficient λ(t), and the interference factor ω(t), the maximum number of requests per unit time NQ is dynamically adjusted to obtain the adjusted maximum number of requests per unit time NQ'(t):

[0152]

[0153] Based on the further impact of the business peak characteristic function g(t) on the adjusted maximum number of requests per unit time, the adjusted maximum number of requests per unit time NQ''(t) is obtained:

[0154]

[0155] Based on the remaining time in the current time window Tc being Tc-t, the maximum number of requests per unit time NQ''(t) after re-adjustment and the safety constraint function h(t) are used to calculate the maximum number of requests M(t) in the remaining time:

[0156]

[0157] Defining functions It represents the sum of the number of requests initiated in the entire time window Tc and the maximum number of requests in the remaining time up to the current time t. The calculation formula is as follows:

[0158]

[0159] Determine the maximum number of requests NA allowed by the second key KS, and the calculation formula is:

[0160] .

[0161] Corresponding to the above method embodiment, see Figure 3 The embodiment of the present invention further discloses a frequency and time-based API key management device 30, comprising:

[0162] The storage module 301 stores the basic data of all API keys in the database DB, and dynamically stores the keys and their dynamic data in the cache HC through the minimum heap data structure HD;

[0163] A selection module 302 selects a first key KF for the service request from a minimum heap data structure HD of the cache HC according to the dynamic data;

[0164] The inspection module 303, after acquiring the first key KF, inspects the current state of the first key KF. If the first key KF is used normally, the usage and usage time of the first key KF are updated. If the first key KF is abnormal, the interface is called to update the state of the first key KF and send relevant alarm information to the monitoring system to obtain the updated second key KS.

[0165] The reset module 304 temporarily disconnects the second key KS according to the state of the second key KS, and determines whether the second key KS after the temporary disconnection has reached the upper limit of usage according to a preset time period. If so, the number of times of usage of the second key KS is automatically reset;

[0166] Determination module 305 determines the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS based on the maximum allowed number of calls NC allocated to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time, where min() is the minimum function, and Tc is the unit time window length, indicating the time period of rate limitation.

[0167] See also Figure 4 The embodiment of the present invention further provides an electronic device 60, the electronic device comprising:

[0168] at least one processor; and,

[0169] a memory communicatively connected to the at least one processor; wherein,

[0170] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the frequency and time-based API key management method in the aforementioned method embodiment.

[0171] An embodiment of the present invention further provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable the computer to execute the aforementioned method embodiment.

[0172] An embodiment of the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer executes the frequency and time-based API key management method in the aforementioned method embodiment.

[0173] Reference below Figure 4 , which shows a schematic diagram of the structure of an electronic device 60 suitable for implementing the embodiment of the present disclosure. The electronic device in the embodiment of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 4 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0174] like Figure 4 As shown, the electronic device 60 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the electronic device 60 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0175] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, a gage, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device 60 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 4 The electronic device 60 is shown with various devices, but it should be understood that it is not required to implement or have all the devices shown. More or fewer devices may be implemented or have instead.

[0176] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0177] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A frequency and time-based API key management method, characterized in that: include: The basic data of all API keys are stored in the database DB, and the keys and their dynamic data are dynamically stored in the cache HC through the minimum heap data structure HD. The dynamic data is the characteristic data reflecting the current activity, importance or adaptability of the key to the service request; According to the dynamic data, a first key KF for serving the request is selected from a minimum heap data structure HD of the cache HC; After obtaining the first key KF, the current state of the first key KF is checked. If the first key KF is used normally, the usage and usage time of the first key KF are updated. If the first key KF is abnormal, the interface dedicated to key state update is called to update the state of the first key KF and send relevant alarm information to the monitoring system to obtain the updated second key KS. When the state of the second key KS is that it has been abnormal for many times but has not been completely confirmed to be unusable, the second key KS is temporarily offline, and according to a preset time period, it is determined whether the second key KS after being temporarily offline has reached the upper limit of usage. If so, the number of times the second key KS is used is automatically reset; The maximum number of requests allowed by the second key KS is determined according to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time. , min() is the minimum function, Tc is the unit time window length, which indicates the time period of rate limitation.

2. The method according to claim 1, characterized in that The basic data of all API keys are stored in the database DB, and the keys and their dynamic data are dynamically stored in the cache HC through the minimum heap data structure HD, including: Determine the API key basic data fields that need to be stored; Use the database table creation statement to create a table for storing API key basic data according to the designed table structure; When generating a new API key or importing an existing API key, write the corresponding code logic in the application to assemble the API key and its corresponding basic data into data records according to the table structure requirements; Perform an insert operation through the database connection object to insert the data record into the API key basic data table created previously; Write SQL statements to query API key basic data based on different conditions, execute the query statements in the application and process the returned result sets; When the basic data of the API key changes, write an UPDATE statement to locate the record that needs to be updated according to the conditions and update the value of the corresponding field; When you need to delete the basic data of an API key, write a DELETE FROM statement to delete the corresponding records according to the preset conditions.

3. The method according to claim 2, characterized in that The method stores the basic data of all API keys in the database DB, and dynamically stores the keys and their dynamic data in the cache HC through the minimum heap data structure HD, and also includes: After selecting the cache system, configure the connection parameters of the cache system and initialize the connection object with the cache HC in the application; Create a class that represents a minimum heap node. The node class contains at least member variables for storing API key related information and related properties for building a minimum heap structure. Implement the corresponding constructor to initialize the node object, as well as methods to obtain and set the values ​​of each node attribute; Write logic to insert a new node containing the API key and its dynamic data into the min-heap. During the insertion, according to the characteristics of the min-heap, the node position is adjusted to maintain the min-heap structure by comparing the values ​​of the newly inserted node with the existing nodes. After swapping the top node with the last node, delete the last node, and then adjust the heap structure downward from the top of the heap. Compare the values ​​of the current node and the child nodes. If they do not meet the minimum heap condition, swap their positions. Continue adjusting until the entire heap meets the minimum heap property again. If the dynamic data of the API key changes, delete the original node first and then reinsert the updated node; When you need to add the API key and its dynamic data to the cached minimum heap, first build the corresponding minimum heap node, then use the interface provided by the cache system to store the node data in the cache, and call the minimum heap insertion operation method to maintain the correctness of the minimum heap structure in the cache; When the minimum node in the minimum heap needs to be obtained, the top node data of the heap is read from the cache and processed according to the needs. If the dynamic data changes after processing, the update node operation method is called to update the minimum heap structure in the cache; When the API key no longer needs to be maintained in the cache, the corresponding minimum heap node data is deleted from the cache, and the minimum heap delete minimum node operation method is called to adjust the minimum heap structure of the remaining nodes.

4. The method according to claim 3, characterized in that The selecting, according to the dynamic data, a first key KF for the service request from a minimum heap data structure HD of the cache HC comprises: Determine the top element of the minimum heap data structure HD according to the dynamic data; After determining the top element of the heap, the value of the key field is obtained through the access method and assigned to the first key KF.

5. The method according to claim 4, characterized in that After obtaining the first key KF, checking the current state of the first key KF includes: Check whether the key format meets the preset requirements, including whether the key length is correct and whether it contains specific character combinations; Verify its validity by comparing it with pre-stored legitimate key characteristics or associated information; After recording the usage information of the key used this time, obtain the current timestamp and update the timestamp to the field recording the most recent usage time in the storage key attribute; After the usage and usage time are updated, if the first key KF is in a normal state and the attributes have been updated, the updated first key KF is directly assigned to the second key KS; If an abnormality occurs in the first key KF, an interface specifically used for updating the key status is called, the identification information of the first key KF and a detailed description of the abnormal status are passed to the interface, and an alarm message body containing key KF related information is constructed, and the alarm message is sent to the monitoring system through the communication interface connected to the monitoring system.

6. The method according to claim 5, characterized in that The temporarily offline operation of the second key KS according to the state of the second key KS includes: In the key management system, by recording the field of the key status, the status flag corresponding to the second key KS is modified to be temporarily offline; At each service interface that relies on the key for operation, when it is detected that the key to be used is the second key KS that is temporarily offline, subsequent calling operations on the second key KS are blocked.

7. The method according to claim 6, characterized in that The method of judging whether the second key KS after the temporary offline has reached the upper limit of usage according to the preset time period, and if so, automatically resetting the number of times of usage of the second key KS, includes: The obtained cumulative usage times are compared with the preset usage upper limit value. If the cumulative usage times are greater than or equal to the preset usage upper limit, it is determined that the second key KS has reached the usage upper limit; When it is determined that the second key KS has reached the upper limit of usage, the number of times the second key KS is used is reset to 0 in the database table storing information related to the number of times the key is used.

8. The method according to claim 7, characterized in that The method of determining the maximum number of requests NA=min(NC,NQ⋅Tc) allowed by the second key KS according to the maximum allowed number of calls NC allocated to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time comprises: Set t to the current usage time from the last key reset, n(t) represents the number of requests for the second key KS initiated by time t, r(t) represents the weight coefficient dynamically calculated based on system load and security risk at time t, f(t) represents the request frequency correction function related to time t, λ(t) represents the key importance coefficient based on key usage history data and current system environment analysis, ω(t) represents the interference factor affected by the external network environment, g(t) represents the service peak characteristic function corresponding to time t, and h(t) represents the security constraint function based on security audit results and potential risk prediction; Based on the weight coefficient r(t), the request frequency correction function f(t), the key importance coefficient λ(t), and the interference factor ω(t), the maximum number of requests per unit time NQ is dynamically adjusted to obtain the adjusted maximum number of requests per unit time NQ'(t): Based on the further impact of the business peak characteristic function g(t) on the adjusted maximum number of requests per unit time, the adjusted maximum number of requests per unit time NQ''(t) is obtained: Based on the remaining time in the current time window Tc being Tc-t, the maximum number of requests per unit time NQ''(t) after re-adjustment and the safety constraint function h(t) are used to calculate the maximum number of requests M(t) in the remaining time: Defining functions It represents the sum of the number of requests initiated in the entire time window Tc and the maximum number of requests in the remaining time up to the current time t. The calculation formula is as follows: Determine the maximum number of requests NA allowed by the second key KS, and the calculation formula is: 。 9. A frequency and time-based API key management device, characterized in that: include: The storage module stores the basic data of all API keys in the database DB, and dynamically stores the keys and their dynamic data in the cache HC through the minimum heap data structure HD, wherein the dynamic data is characteristic data reflecting the current activity, importance or adaptability of the keys to the service request; A selection module, which selects a first key KF for the service request from a minimum heap data structure HD of the cache HC according to the dynamic data; The inspection module, after acquiring the first key KF, inspects the current state of the first key KF. If the first key KF is used normally, the usage and usage time of the first key KF are updated. If the first key KF is abnormal, the interface dedicated to key status update is called to update the state of the first key KF and send relevant alarm information to the monitoring system to obtain the updated second key KS. A reset module, when the state of the second key KS is that there have been multiple exceptions but it has not been completely confirmed to be unusable, temporarily offline the second key KS, and determine whether the second key KS after being temporarily offline has reached the upper limit of usage according to a preset time period. If so, automatically reset the number of times the second key KS is used; The determination module determines the maximum number of requests allowed by the second key KS according to the maximum allowed number of calls NC assigned to the second key KS after automatic reset and the maximum number of requests NQ of the second key KS to the API interface per unit time. , min() is the minimum function, Tc is the unit time window length, which indicates the time period of rate limitation.

10. An electronic device, characterized in that: The electronic device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the frequency and time-based API key management method described in any one of claims 1 to 8.

Images