API management method and device based on Shiro, electronic equipment and storage medium
By introducing interface filters into the Shiro framework, secure API management is achieved, solving the security risks caused by the lack of gateway deployment in small and medium-sized enterprises, and reducing development costs and system risks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA TELECOM CLOUD TECH CO LTD
- Filing Date
- 2025-11-27
- Publication Date
- 2026-04-17
AI Technical Summary
Small and medium-sized enterprises often fail to deploy gateways in their JavaSE and JavaEE projects, leading to significant security risks in API management and a large workload associated with gateway connections.
The Shiro framework introduces an interface filter to achieve API security management by judging the target Uniform Resource Locator, interface type, and filtering rule table. This includes configuring the interface filter table, filtering rule table, and alarm rule table, and performing interface verification and alarm processing.
It eliminates the need for gateways, reducing development workload, lowering development costs, mitigating system security risks, and enabling flexible API security management.
Smart Images
Figure CN121879730A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the technical field of interface management, specifically relating to a method, apparatus, electronic device, and storage medium for API management based on Shiro. Background Technology
[0002] Apache Shiro is a powerful and easy-to-use Java security framework that provides authentication, authorization, encryption, and session management features. It is currently widely used in Java SE and Java EE projects.
[0003] like Figure 1 As shown, Shiro can connect to the access API (Application Programming Interface) via a gateway and to the business interface.
[0004] Gateways can be used to intercept and verify APIs, but this method involves a large amount of work, and many small and medium-sized enterprises do not have gateways deployed, which poses a significant security risk. Summary of the Invention
[0005] In view of the above problems, a method, apparatus, electronic device, and storage medium based on Shiro API management are proposed to overcome or at least partially solve the above problems, including: A method for API management based on Shiro, applied to the Shiro framework, wherein the Shiro framework includes an interface filter and is connected to an application programming interface (API); the method includes: The interface filter is invoked to determine whether the target Uniform Resource Locator (URL) corresponding to the target application programming interface being called matches. When the target Uniform Resource Locator (URL) matches, it is determined whether the target interface type corresponding to the target access application programming interface (API) matches. When the target interface type matches, determine whether the target access hits the filtering rule table; When the target access hits the filtering rule table, a target alarm rule is determined for the target access, and the target access is processed according to the target alarm rule.
[0006] In some embodiments, the Shiro framework is configured with an interface filtering table, which contains multiple Uniform Resource Locators (URLs) to be verified. The step of determining whether the target URL corresponding to the currently invoked target application programming interface (API) matches successfully includes: Determine whether the target Uniform Resource Locator matches the plurality of interface Uniform Resource Locators to be verified; When the target Uniform Resource Locator (URL) matches any one of the plurality of interface URLs to be verified, the target URL is determined to be a successful match.
[0007] In some embodiments, the interface filtering table is further configured with interface types to be filtered, and determining whether the target interface type corresponding to the target access application programming interface matches includes: Determine the target interface type corresponding to the target access application programming interface, wherein the target interface type includes obsolete type or filtered type; When the target interface type is a filter type, it is determined that the target interface type matches successfully.
[0008] In some embodiments, the interface filtering table is further configured with a filtering rule table, the filtering rule table being configured with filtering rules, and determining whether the target access hits the filtering rule table includes: Determine whether the target access matches the filtering rule; When the target access matches the filtering rule, it is determined that the target access hits the filtering rule table.
[0009] In some embodiments, the filtering rules include at least one of the following: The target supports tenant information, target user information, target address information, blacklist information, whitelist information, and interface access time information.
[0010] In some embodiments, the filtering rule table further includes hit rules, and determining whether the target access hits the filtering rule includes: Determine whether the request header and / or request body match the filtering rule; When the request header and / or request body match the filtering rule, it is determined that the target access has hit the filtering rule.
[0011] In some embodiments, the interface filter table is further configured with an alarm rule table, wherein determining the target alarm rule for the target access includes: The target alarm rule is determined based on the alarm rule table.
[0012] This application also provides a device for API management based on Shiro, applied to the Shiro framework, wherein the Shiro framework is provided with an interface filter and is connected to an application programming interface; the device includes: The first judgment module is used to call the interface filter to determine whether the target Uniform Resource Locator corresponding to the target access application programming interface currently being called matches successfully. The second judgment module is used to determine whether the target interface type corresponding to the target access application programming interface is matched when the target Uniform Resource Locator is matched. The third judgment module is used to determine whether the target access hits the filtering rule table when the target interface type matches. The management module is used to determine the target alarm rule for the target access when the target access hits the filter rule table, and to process the target access according to the target alarm rule.
[0013] In some embodiments, the Shiro framework is configured with an interface filter table, which contains a plurality of interface Uniform Resource Locators (URLs) to be verified. The first judgment module is used to determine whether the target URL matches the plurality of interface URLs to be verified. When the target URL matches any one of the plurality of interface URLs to be verified, the target URL is determined to be a successful match.
[0014] In some embodiments, the interface filtering table is further configured with interface types to be filtered, and the second judgment module is used to determine the target interface type corresponding to the target access application programming interface, wherein the target interface type includes obsolete type or filtering type; when the target interface type is a filtering type, it is determined that the target interface type matches.
[0015] In some embodiments, the interface filter table is further configured with a filter rule table, the filter rule table is configured with filter rules, and the third judgment module is used to determine whether the target access hits the filter rule; when the target access hits the filter rule, it is determined that the target access hits the filter rule table.
[0016] In some embodiments, the filtering rules include at least one of the following: The target supports tenant information, target user information, target address information, blacklist information, whitelist information, and interface access time information.
[0017] In some embodiments, the filtering rule table further includes a hit rule, and the third judgment module is used to determine whether the request header and / or request body hits the filtering rule; when the request header and / or request body hits the filtering rule, it is determined that the target access hits the filtering rule.
[0018] In some embodiments, the interface filter table is further configured with an alarm rule table, and the management module is used to determine the target alarm rule based on the alarm rule table.
[0019] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described Shiro-based API management method.
[0020] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described Shiro-based API management method.
[0021] The embodiments of this application have the following advantages: In this embodiment, an interface filter is invoked to determine whether the target Uniform Resource Locator (URI) corresponding to the currently invoked target access application programming interface (API) matches. If the target URI matches, the target interface type corresponding to the target access API matches. If the target interface type matches, the target access hits the filter rule table. If the target access hits the filter rule table, a target alarm rule is determined for the target access, and the target access is processed according to the target alarm rule.
[0022] This application extends the Shiro framework by adding an interface filter, enabling secure API management that is convenient, flexible, and eliminates the need for a gateway. This reduces development workload and costs while also lowering system security risks. Attached Figure Description
[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a schematic diagram of a gateway-based API management approach in related technologies; Figure 2 This is a flowchart illustrating the steps of a Shiro-based API management method according to an embodiment of this application. Figure 3 This is a schematic diagram illustrating an API management implementation based on Shiro according to an embodiment of this application; Figure 4 This is a flowchart illustrating the steps of another method for API management based on Shiro, according to an embodiment of this application. Figure 5 This is a flowchart illustrating the steps of an API management process based on Shiro, according to an embodiment of this application. Figure 6 This is a schematic diagram of the structure of an API management device based on Shiro, according to an embodiment of this application. Detailed Implementation
[0024] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0025] Attacks targeting web system APIs are becoming increasingly common, and system protection measures are relatively limited. Defense is mainly carried out through gateways, but many small and medium-sized enterprises do not deploy gateways themselves.
[0026] To address this, this application extends the Shiro framework by adding an interface filter, enabling secure API management that is convenient, flexible, and eliminates the need for a gateway. This reduces development workload and costs while also mitigating system security risks.
[0027] For specific details, please refer to Figure 2 , Figure 2 A flowchart illustrating the steps of a Shiro-based API management method according to an embodiment of this application is shown.
[0028] like Figure 2 As shown, this Shiro-based API management method may include the following steps: Step 201: Call the interface filter to determine whether the target Uniform Resource Locator (URL) corresponding to the target application programming interface being called matches.
[0029] In some embodiments, such as Figure 3 As shown, the Shiro framework can be configured with an interface filter, which enables the Shiro framework to integrate management functions for validating and intercepting APIs.
[0030] The Shiro framework connects to the Access Application Programming Interface (API) to directly manage it. Compared to the gateway-based management methods in related technologies, this application eliminates the need for a gateway, reducing development workload, lowering development costs, and mitigating security risks.
[0031] like Figure 3 As shown, the Shiro framework can also set up a login authentication filter. API requests first pass through the login authentication filter for identity and permission authentication; if the identity and permission authentication is successful, the interface filter is called for interface verification.
[0032] Once the interface verification is successful, the corresponding business interface can be called. This application embodiment does not impose any restrictions on this.
[0033] In some embodiments, when a target access interface request is received, the embodiments of this application may first determine the target Uniform Resource Locator (URL) of the target access application programming interface through which the interface request passes.
[0034] After determining the target Uniform Resource Locator (URL), the interface filter can first analyze and judge it to determine whether it needs to be validated.
[0035] For example, a set of Uniform Resource Locators (URLs) that need to be verified can be preset. If the target URL matches any one of these URLs, the target URL can be determined to be a successful match.
[0036] If the target Uniform Resource Locator (URL) is determined to be a match, step 202 can be executed; otherwise, if the target URL is determined to be a mismatch, it means that the interface does not need to be validated.
[0037] At this point, you can directly request the interface accessed by the target to execute subsequent steps.
[0038] Step 202: When the target Uniform Resource Locator (URL) matches, determine whether the target interface type corresponding to the target access application programming interface (API) matches.
[0039] In some embodiments, when it is determined that the target Uniform Resource Locator (URL) matches successfully, it can be determined that the interface request for that interface needs to be validated; at this time, the target interface type corresponding to the target access application programming interface can be further determined.
[0040] For example, the target interface type can include an obsolete type or a filter type. An obsolete type indicates that the API is no longer online and access can be directly denied without validation. A filter type indicates that validation is required for the interface request corresponding to that API.
[0041] After determining the target interface type corresponding to the target access application programming interface, the interface filter can determine whether the target interface type matches.
[0042] If the request fails, it indicates that the target interface type is obsolete, and access can be denied directly. Otherwise, if the request passes, step 203 can be executed.
[0043] Step 203: When the target interface type matches, determine whether the target access hits the filtering rule table.
[0044] In some embodiments, when it is determined that the target interface type matches, it can be determined that the interface request for the target to access the application programming interface needs to be verified; at this time, it can be further determined whether the target access hits the filtering rule table.
[0045] The filtering rule table can be configured according to actual needs, such as configuring blacklists and whitelists, etc., and this application embodiment does not impose any limitations on this. Flexible configuration of the filtering rule table can solve the problem that gateway connection rules cannot be flexibly customized according to business requirements.
[0046] For example, if the feature information in a target access matches a field in a filtering rule table, it can be determined that the target access hits the filtering rule table.
[0047] The fields in the filtering rules table may include the filtering rules set therein, such as blacklists and whitelists, etc., but this application embodiment does not limit this.
[0048] In practical applications, if a target access hits the filtering rule table, it indicates that there is a problem with the target access, and it can be directly rejected.
[0049] Conversely, if the target access does not hit the filtering rule table, it can be identified that there is no problem with the target access. In this case, subsequent steps can be performed in response to the interface request. This application embodiment does not limit this.
[0050] In some embodiments, different access application programming interfaces (APIs) are configured with corresponding filtering rule tables. After determining the target API, the corresponding filtering rule table can be obtained and managed based on the ID of the filtering rule table configured for that target API.
[0051] Step 204: When a target access hits the filter rule table, determine the target alarm rule for the target access, and process the target access according to the target alarm rule.
[0052] In some embodiments, if a target access hits a filtering rule table, it can be determined that the target access needs to be intercepted; in this case, the interface request of the target access can be intercepted directly.
[0053] Conversely, if the target access does not hit the filtering rule table, it can be determined that the target access does not need to be blocked.
[0054] At this point, the subsequent steps in response to the interface request can be executed directly based on the interface request.
[0055] In some embodiments, when it is determined that the target access needs to be intercepted, a corresponding target alarm rule can also be determined, and the target access can be processed according to the target alarm rule, such as interception, sending alarm information, etc. This application embodiment does not limit this.
[0056] In this embodiment, an interface filter is invoked to determine whether the target Uniform Resource Locator (URI) corresponding to the currently invoked target access application programming interface (API) matches. If the target URI matches, it is determined whether the target interface type corresponding to the target access API matches. If the target interface type matches, it is determined whether the target access hits the filter rule table. If the target access hits the filter rule table, a target alarm rule is determined for the target access, and the target access is processed according to the target alarm rule.
[0057] This application extends the Shiro framework by adding an interface filter, enabling secure API management that is convenient, flexible, and eliminates the need for a gateway. This reduces development workload and costs while also lowering system security risks.
[0058] Reference Figure 4 The diagram illustrates a flowchart of another method for API management based on Shiro, according to an embodiment of this application, which may include the following steps: Step 401: The Shiro framework is configured with an interface filter table, which contains multiple interface URPs to be verified; determine whether the target URP matches the multiple interface URPs to be verified.
[0059] In the embodiments of this application, such as Figure 3 As shown, the Shiro framework can be configured with an interface filter, which enables the Shiro framework to integrate management functions for validating and intercepting APIs.
[0060] The Shiro framework connects to the Access Application Programming Interface (API) to directly manage it. Compared to the gateway-based management methods in related technologies, this application eliminates the need for a gateway, reducing development workload, lowering development costs, and mitigating security risks.
[0061] like Figure 3 As shown, the Shiro framework can also set up a login authentication filter. API requests first pass through the login authentication filter for identity and permission authentication; if the identity and permission authentication is successful, the interface filter is called for interface verification.
[0062] In this embodiment of the application, the Shiro framework can be configured with an interface filter table, which can be configured with multiple interface Uniform Resource Locators to be verified for the purpose of managing APIs; the interface Uniform Resource Locator to be verified can refer to the URL (Uniform Resource Locator) of the application programming interface that needs to be verified.
[0063] In some embodiments, when a target access interface request is received, the embodiments of this application may first determine the target Uniform Resource Locator (URL) of the target access application programming interface through which the interface request passes.
[0064] After determining the target Uniform Resource Locator (URL), the interface filter can first analyze and judge it to determine whether it needs to be validated.
[0065] For example, after determining the target Uniform Resource Locator (URL), the interface filter can determine whether the target URL matches multiple interface URLs to be verified in the interface filter table.
[0066] Step 402: When the target Uniform Resource Locator (URI) matches any one of the multiple interface URIs to be verified, the target URI is determined to be a successful match.
[0067] In some embodiments, if the target Uniform Resource Locator (URL) matches any one of the multiple URLs to be verified in the interface filter table, the target URL can be determined to be a successful match; at this time, step 403 can be executed.
[0068] Conversely, if the target ULR does not match any of the ULRs of the interfaces to be verified, then the target ULR is considered to have matched successfully. In this case, verification of the target access is not required.
[0069] Step 403: The interface filter table is also configured with the types of interfaces to be filtered; when the target Uniform Resource Locator matches, the target interface type corresponding to the target access application programming interface is determined. The target interface type includes obsolete types or filtered types.
[0070] In some embodiments, in addition to configuring multiple interface Uniform Resource Locators to be verified, the interface filtering table can also be configured with interface types to be filtered, which can be filtering types.
[0071] After determining that the target Uniform Resource Locator (URL) matches, the interface filter can first determine the target interface type corresponding to the target access application programming interface (API); for example, the target interface type can be an obsolete type or a filtered type.
[0072] Step 404: When the target interface type is a filter type, the target interface type is determined to be a match.
[0073] In some embodiments, if the target interface type is an obsolete interface type, it can be determined that the target interface type does not match the interface type to be filtered; in this case, the target access can be directly rejected.
[0074] Conversely, if the target interface type is a filtering type, it can be determined that the target interface type matches the interface type to be filtered; at this time, it can be determined that the target interface type matches successfully, and step 404 can be continued.
[0075] Step 405: The interface filter table is also configured with a filter rule table, which contains filter rules. When the target interface type matches, it is determined whether the target access hits the filter rule.
[0076] In some embodiments, in addition to configuring multiple interface Uniform Resource Locators to be verified, the interface filtering table may also be configured with a filtering rule table; the filtering rule table may be configured with one or more filtering rules.
[0077] For example, a filtering rule may include multiple fields for matching; when a target access matches a field, it can be said that the target access hits the filtering rule and needs to be checked.
[0078] In this embodiment of the application, after determining that the target interface type matches, it can be further determined whether the target access matches the filtering rules in the filtering rule table.
[0079] In some embodiments of this application, the filtering rules include at least one of the following: The target supports tenant information, target user information, target address information, blacklist information, whitelist information, and interface access time information.
[0080] In some embodiments, the fields of the filtering rule may include any one or more of the following: target supported tenant information, target user information, target address information, blacklist information, whitelist information, and interface access time information.
[0081] The target supporting tenant information can refer to the information of the tenant that needs to be verified in the initiating access, such as the unique identifier of these tenants. If the target access contains target supporting tenant information, then the target access is determined to have hit the filtering rule table.
[0082] Target user information can refer to the information of the user whose request needs to be verified, such as the unique identifier of these users. If target user information exists in the target request, then the target request is determined to have hit the filtering rule table.
[0083] Blacklist information can include both blacklists and whitelists; API access time information can refer to the time during which the API can be accessed.
[0084] If the user or tenant corresponding to the target access is in the blacklist, then the target access is determined to have hit the filtering rule table. If the user or tenant corresponding to the target access is not in the whitelist, then the target access is determined to have hit the filtering rule table.
[0085] If the time of the target access is not within the interface access time information, then the target access is determined to have hit the filtering rule table.
[0086] In some embodiments, the filtering rules may also include access frequency; for example, if an interface is accessed frequently, it can be determined that the target access initiated by the target access application programming interface hits the filtering rule table.
[0087] In some embodiments of this application, the filtering rule table also includes hit rules. Based on this, step 405 above can be implemented through the following sub-steps: Sub-step 11: Determine whether the request header and / or request body of the target access match the filtering rules.
[0088] In some embodiments, the filtering rule table may further include hit rules, which may refer to the hit filtering rules in the request header and / or request weight.
[0089] When determining whether a target access hits the filtering rule table, you can first check whether the request header and / or request body of the target access hit the filtering rule.
[0090] Sub-step 12: When the request header and / or request body of the target access match the filtering rule, determine that the target access has hit the filtering rule.
[0091] If the request headers and / or request body of the target access contain information that matches the fields of the filtering rules, then it can be determined that the request headers and / or request body of the target access match the filtering rules.
[0092] When determining whether the request headers and / or request body of the target access match the filtering rules, it can be determined that the target access has hit the filtering rules.
[0093] Step 406: When the target access hits the filtering rule, determine that the target access hits the filtering rule table.
[0094] In some embodiments, if the target access hits any one of the filtering rules in the filtering rule table, it can be determined that the target access hits the filtering rule table; at this time, step 406 can be further executed.
[0095] If the target access does not match any filtering rule in the filtering rule table, it can be determined that the target access has not matched the filtering rule table; in this case, the target access does not need to be validated.
[0096] Step 407: The interface filter table is also configured with an alarm rule table; when a target access hits the filter rule table, the target alarm rule is determined according to the alarm rule table.
[0097] In some embodiments, the interface filter table may also be configured with an alarm rule table, which may be configured with a variety of alarm rules.
[0098] After determining the target access to the filtering rule table, the target alarm rules for the target access can be determined from the alarm rule table.
[0099] In some embodiments, different access application programming interfaces (APIs) are configured with corresponding alarm rule tables. After determining the target API, the corresponding alarm rule table can be obtained and managed based on the ID of the alarm rule table configured for that target API.
[0100] Step 408: Process the target access according to the target alarm rules.
[0101] Then, based on the target alarm rule, alarms and blocking can be performed on the target access. This application embodiment does not limit the specific target alarm rule.
[0102] In this embodiment, the Shiro framework is configured with an interface filtering table, which contains multiple interface Uniform Resource Locators (URLs) to be verified. The system determines whether a target URL matches any of the multiple URLs to be verified. If the target URL matches any one of the multiple URLs to be verified, the target URL is considered to have passed the match. The interface filtering table also contains interface types to be filtered. If the target URL matches, the system determines the target interface type corresponding to the target access application programming interface (API). The target interface type includes obsolete types or filtered types. If the target interface type is a filtered type, the target interface type is considered to have passed the match. The interface filtering table also contains a filtering rule table, which contains filtering rules. If the target interface type matches, the system determines whether the target access hits a filtering rule. If the target access hits a filtering rule, the target access is considered to have hit the filtering rule table.
[0103] The interface filter table is also configured with an alarm rule table; when a target access hits the filter rule table, the target alarm rule is determined according to the alarm rule table; and the target access is processed according to the target alarm rule.
[0104] This application extends the Shiro framework by adding an interface filter, enabling secure API management that is convenient, flexible, and eliminates the need for a gateway. This reduces development workload and costs while also lowering system security risks.
[0105] In addition, this application allows for flexible configuration of each table, enabling customization based on business needs.
[0106] Reference Figure 5 The following is a flowchart illustrating the logic of an interface filter according to an embodiment of this application: Step 1: Based on the Shiro framework, add 3 new system tables, namely: Interface filter table; Filtering rule table; Alarm rules table.
[0107] The interface filtering table supports configuring the Uniform Resource Locator (URL) of the interface to be verified, the type of the interface to be filtered, the filtering rule table ID, and the alarm rule table ID. The filtering rule table supports configuring hit rules (request headers, request bodies) and filtering rules (supporting blacklists and whitelists based on tenant, user, IP, etc., and interface access time). The alarm rule table supports configuring alarm types (SMS, email) and alarm account information; Step 2: Add a Shiro interface filter, which supports custom filtering and alarm logic via factory mode. The default logic is as follows: The interface filter table is used to match the Uniform Resource Locator (URL) of the interface to be verified using regular expressions. If there is no match, the interface is allowed; if there is a match, proceed to step three. Step 3: The interface filter determines the interface filtering type. If it is a deprecated type, proceed to step 6; if it is a filtering type, proceed to step 4. Step 4: Determine if the interface has a configured filtering rule table and if the filtering rule table is matched; if not, allow the interface to pass; otherwise, proceed to Step 5. Step 5: Determine if the interface matches the filtering rule: First, determine if interface access time information is configured; If configured, determine whether it falls within the time period corresponding to the interface access time information; If so, further determine whether a blacklist is configured, and whether it is on the blacklist; If it is not in the blacklist, then further determine whether a whitelist is configured and whether it is in the whitelist. If it is in the whitelist, then the interface is allowed.
[0108] Conversely, if interface access time information is not configured, further determination is made as to whether a blacklist is configured. If no blacklist is configured, then further determine whether a whitelist should be configured; If no whitelist is configured, the request will be allowed directly.
[0109] If the access time is outside the time period specified in the API access time information, proceed to step six; if the access time is within the blacklist, proceed to step six; if the access time is outside the whitelist, proceed to step six.
[0110] Step 6. Determine if an alarm rule in the alarm rule table is hit. If it is hit, send an alarm message and deny access; if it is not hit, deny access directly. To install the interface filter, follow these steps: import the Shiro jar package, configure the interface filter table, filter rule table, and alarm rule table, and configure the filter using ShiroConfig. Then it will work correctly.
[0111] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should know that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps may be performed in other orders or simultaneously.
[0112] Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required for the embodiments of this application.
[0113] Reference Figure 6 The diagram shows a structural schematic of an API management device based on Shiro, according to an embodiment of this application.
[0114] It is applied to the Shiro framework, which has interface filters and connects to the application programming interface.
[0115] like Figure 6 As shown, the device may include the following modules: The first judgment module 601 is used to call the interface filter to determine whether the target Uniform Resource Locator corresponding to the target access application programming interface currently being called matches successfully. The second judgment module 602 is used to determine whether the target interface type corresponding to the target access application programming interface is matched when the target Uniform Resource Locator matches successfully. The third judgment module 603 is used to determine whether the target access hits the filtering rule table when the target interface type matches. The management module 604 is used to determine the target alarm rule for the target access when the target access hits the filter rule table, and to process the target access according to the target alarm rule.
[0116] In one optional embodiment of this application, the Shiro framework is configured with an interface filter table, which contains multiple interface Uniform Resource Locators to be verified. The first judgment module 601 is used to determine whether the target Uniform Resource Locator (URI) matches multiple interface URIs to be verified; when the target URI matches any one of the multiple interface URIs to be verified, the target URI is determined to be a successful match.
[0117] In one optional embodiment of this application, the interface filtering table is further configured with the types of interfaces to be filtered; The second judgment module 602 is used to determine the target interface type corresponding to the target access application programming interface. The target interface type includes obsolete type or filter type. When the target interface type is a filter type, it is determined that the target interface type matches.
[0118] In one optional embodiment of this application, the interface filter table is further configured with a filter rule table, and the filter rule table is configured with filter rules; The third judgment module 603 is used to determine whether the target access hits the filtering rules; when the target access hits the filtering rules, it is determined that the target access hits the filtering rule table.
[0119] In one optional embodiment of this application, the filtering rules include at least one of the following: The target supports tenant information, target user information, target address information, blacklist information, whitelist information, and interface access time information.
[0120] In one optional embodiment of this application, the filtering rule table further includes hit rules; The third judgment module 603 is used to determine whether the request header and / or request body match the filtering rules; when the request header and / or request body match the filtering rules, it is determined that the target access has hit the filtering rules.
[0121] In one optional embodiment of this application, the interface filter table is further configured with an alarm rule table; The management module 604 is used to determine the target alarm rule based on the alarm rule table.
[0122] In this embodiment, an interface filter is invoked to determine whether the target Uniform Resource Locator (URI) corresponding to the currently invoked target access application programming interface (API) matches. If the target URI matches, the target interface type corresponding to the target access API matches. If the target interface type matches, the target access hits the filter rule table. If the target access hits the filter rule table, a target alarm rule is determined for the target access, and the target access is processed according to the target alarm rule.
[0123] This application extends the Shiro framework by adding an interface filter, enabling secure API management that is convenient, flexible, and eliminates the need for a gateway. This reduces development workload and costs while also lowering system security risks.
[0124] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described Shiro-based API management method.
[0125] This application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the above-described Shiro-based API management method.
[0126] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.
[0127] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0128] Those skilled in the art will understand that the embodiments of this application can be provided as methods, apparatus, or computer program products.
[0129] Therefore, embodiments of this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.
[0130] Furthermore, embodiments of this application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0131] The embodiments of this application are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to the embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.
[0132] These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which are executable by the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0133] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0134] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0135] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.
[0136] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.
[0137] Moreover, the terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or terminal device.
[0138] Without further restrictions, an element defined by the phrase "including one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.
[0139] The above provides a detailed description of the method, apparatus, electronic device, and storage medium for API management based on Shiro. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application.
[0140] Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A method for API management based on Shiro, characterized in that, Applied to the Shiro framework, which includes an interface filter and is connected to an application programming interface (API); the method includes: The interface filter is invoked to determine whether the target Uniform Resource Locator (URL) corresponding to the target application programming interface being called matches. When the target Uniform Resource Locator (URL) matches, it is determined whether the target interface type corresponding to the target access application programming interface (API) matches. When the target interface type matches, determine whether the target access hits the filtering rule table; When the target access hits the filtering rule table, a target alarm rule is determined for the target access, and the target access is processed according to the target alarm rule.
2. The method according to claim 1, characterized in that, The Shiro framework is configured with an interface filter table, which contains multiple Uniform Resource Locators (URLs) to be verified. The step of determining whether the target URL corresponding to the currently invoked application programming interface (API) matches successfully includes: Determine whether the target Uniform Resource Locator matches the plurality of interface Uniform Resource Locators to be verified; When the target Uniform Resource Locator (URL) matches any one of the plurality of interface URLs to be verified, the target URL is determined to be a successful match.
3. The method according to claim 2, characterized in that, The interface filtering table is also configured with interface types to be filtered. The step of determining whether the target interface type corresponding to the target access application programming interface matches is included: Determine the target interface type corresponding to the target access application programming interface, wherein the target interface type includes obsolete type or filtered type; When the target interface type is a filter type, it is determined that the target interface type matches successfully.
4. The method according to claim 2, characterized in that, The interface filtering table is also configured with a filtering rule table, which is configured with filtering rules. Determining whether the target access hits the filtering rule table includes: Determine whether the target access matches the filtering rule; When the target access matches the filtering rule, it is determined that the target access hits the filtering rule table.
5. The method according to claim 4, characterized in that, The filtering rules include at least one of the following: The target supports tenant information, target user information, target address information, blacklist information, whitelist information, and interface access time information.
6. The method according to claim 4, characterized in that, The filtering rule table also includes hit rules, and determining whether the target access hits the filtering rule includes: Determine whether the request header and / or request body match the filtering rule; When the request header and / or request body match the filtering rule, it is determined that the target access has hit the filtering rule.
7. The method according to claim 2, characterized in that, The interface filter table is also configured with an alarm rule table. Determining the target alarm rule for the target access includes: The target alarm rule is determined based on the alarm rule table.
8. A device for API management based on Shiro, characterized in that, Applied to the Shiro framework, which includes an interface filter and is connected to an application programming interface (API); the method includes: The first judgment module is used to call the interface filter to determine whether the target Uniform Resource Locator corresponding to the target access application programming interface currently being called matches successfully. The second judgment module is used to determine whether the target interface type corresponding to the target access application programming interface is matched when the target Uniform Resource Locator is matched. The third judgment module is used to determine whether the target access hits the filtering rule table when the target interface type matches. The management module is used to determine the target alarm rule for the target access when the target access hits the filter rule table, and to process the target access according to the target alarm rule.
9. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the Shiro-based API management method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the Shiro-based API management method as described in any one of claims 1 to 7.