Interface metadata processing method and device, electronic equipment and storage medium
By using interface metadata processing methods, interface metadata can be automatically discovered, collected, and analyzed, solving the problems of insufficient accuracy and comprehensiveness in existing technologies. This enables efficient utilization and risk warning of interface metadata, and optimizes cloud network resource management.
Patent Information
- Application Number
- CN202411574150.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-06
- Publication Date
- 2025-12-09
- Estimated Expiration
- 2044-11-06
AI Technical Summary
Existing technologies for collecting and analyzing interface metadata are insufficient in terms of accuracy and comprehensiveness, failing to fully realize their value and being difficult to extend.
This paper provides a method for processing interface metadata. By reading the image file of the business project, determining the project path, performing security risk detection, decompiling the interface file, decompressing the configuration file, finding the interface address and resource list, generating interface metadata, and performing analysis and early warning, the method also constructs the interface access topology.
It enables automatic discovery, collection, and analysis of interface metadata, improving the accuracy and comprehensiveness of collection and analysis, and enabling timely detection and remediation of potential risks, thereby optimizing cloud network resource management.
Smart Images

Figure CN119743472B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of information technology, and in particular to an interface metadata processing method and device, electronic equipment and a storage medium. BACKGROUND
[0002] An interface is a set of software functions encapsulated by a server software for external software requirements, and these functions are often directly used to serve end business users or other external systems. Therefore, it is important to identify and repair problems and risks of the interface and its associated project in a timely manner before formal deployment to a production environment.
[0003] Automatic discovery and analysis of interface metadata are of positive significance for analyzing the quality and security risks of mirror files of projects associated with the interface, and for in-depth quantitative analysis of resource consumption of the business from the interface dimension. The collection and analysis results of interface metadata can provide in-depth quantitative data, help to identify and solve possible risks and operation quality information of business projects and their interfaces as early as possible before deploying the business to a production environment, and effectively reduce the labor cost on related work and improve the effectiveness and efficiency of Internet software operation and resource management. However, the collection and analysis of interface metadata in the prior art have deficiencies in accuracy and comprehensiveness, and are not easy to extend, which cannot fully play the value of interface metadata.
[0004] Terminology explanation:
[0005] Interface: also known as API, refers to an abstraction of a set of software functions exposed by a server application for different forms of software such as web pages, mobile clients or other server applications to access, usually a set of pre-defined functions, the purpose is to provide the ability for application programs to access a set of routines based on a certain software or hardware without accessing the source code or understanding the details of the internal working mechanism. In the description of the present application, the interface specifically refers to the interface exposed through the HTTP / HTTPS protocol.
[0006] Interface metadata: refers to information about the interface itself, the project associated with the interface, the release (to be deployed) file of the project, and the information about various resources called by the interface during operation.
[0007] LoRA (Low-Rank Adaptation of Large Language Models): a plug-in network that can train a style / IP / character under the premise of not modifying the SD (Stable Diffusion) model, which can reduce the GPU demand for training large language models to about one-third of the original, thus helping to train private large language models based on public large language models. SUMMARY
[0008] The present application aims to at least partially solve one of the technical problems existing in the prior art.
[0009] To this end, one object of an embodiment of the present application is to provide an interface metadata processing method which realizes automatic discovery and collection analysis of interface metadata, and improves the accuracy and comprehensiveness of collection and analysis of interface metadata.
[0010] Another object of an embodiment of the present application is to provide an interface metadata processing device.
[0011] To achieve the above technical objects, the technical solutions adopted by an embodiment of the present application include:
[0012] In one aspect, an embodiment of the present application provides an interface metadata processing method, including the following steps:
[0013] reading a mirror file of a business item, collecting business item information according to the mirror file, and determining a project specific path of the business item in the mirror file;
[0014] performing security risk detection on the content of the mirror file, and detecting whether there is a duplicate packaged file, and uploading the detection result to a server;
[0015] finding an interface file path in the mirror file according to the project specific path through decompilation technology, and decompressing a corresponding interface belonging file and a configuration file to a temporary directory;
[0016] finding a context configuration of the business item from the configuration file, and finding a corresponding interface address, a request method and an access resource list from the interface belonging file;
[0017] uploading the context configuration, the interface address, the request method and the access resource list as interface metadata of the business item to the server.
[0018] Further, in one embodiment of the present application, the interface metadata processing method further includes the following steps:
[0019] updating a software security information library of the server according to the interface metadata, and performing project early warning according to the interface metadata and the detection result;
[0020] generating a function description corresponding to each interface according to the interface metadata;
[0021] filtering invalid access logs according to the interface metadata, and performing abnormal access analysis, and further calculating an effective access amount and an access quality of each interface, and determining invalid / inefficient interfaces according to the effective access amount and the access quality;
[0022] According to the function description, each interface is classified to obtain a plurality of interface categories, and then the number of interfaces of each interface category, the interface distribution position and the total effective access amount are determined;
[0023] According to the access resource list, an interface access topology is constructed, and the interface access topology is provided to the client by the server.
[0024] Further, in an embodiment of the present application, the business item information is collected according to the mirror file, and the specific path of the business item in the mirror file is determined, which specifically includes:
[0025] A target JSON file is obtained by searching a preset file name field in the first layer of the mirror file;
[0026] The target JOSN file is parsed to obtain the business item information, and the business item information includes a project maintainer, a business item file working path, a business application file name, a mirror building time, a mirror file size, a mirror file MD5 code, a running environment requirement, an exposed port number and basic mirror data;
[0027] The compressed files in each folder inside the mirror file are read layer by layer, and it is judged whether the compressed files contain the business item file working path and the business application file name;
[0028] If yes, the specific path of the project is determined according to the file path of the compressed file.
[0029] Further, in an embodiment of the present application, the interface file path in the mirror file is found according to the specific path of the project through a decompilation technology, and the corresponding interface belonging file and configuration file are decompressed to a temporary directory, which specifically includes:
[0030] The compiled class file is found in the mirror file according to the specific path of the project;
[0031] The class file is decompiled to obtain class definition information, and the interface corresponding to the class file is determined according to the class definition information, and then the interface file path is determined;
[0032] A temporary directory is created, the corresponding interface belonging file and configuration file are determined according to the interface file path, and the interface belonging file and the configuration file are decompressed to the temporary directory.
[0033] Further, in an embodiment of the present application, the project warning is performed according to the interface metadata and the detection result, which specifically includes:
[0034] determine whether the mirror file has a security risk and whether there is a duplicate packaged file according to the detection result;
[0035] When the mirror file has a security risk and / or a duplicate packaged file, determine a project maintainer according to the interface metadata, and issue the project warning to the project maintainer;
[0036] The project warning is used to remind the project maintainer to formally deploy after repairing the mirror file.
[0037] Further, in an embodiment of the present application, the invalid access log is filtered according to the interface metadata, and abnormal access analysis is performed, and then the effective access amount and access quality of each interface are calculated, and the invalid / inefficient interface is determined according to the effective access amount and the access quality, which specifically includes:
[0038] The interface address, the request method, and the access resource list are determined according to the interface metadata;
[0039] The corresponding target service is determined according to the access resource list, and the access log of the target service is queried according to the interface address and the request method to obtain the effective access log, and the access log that does not belong to the effective access log is taken as the invalid access log;
[0040] The abnormal access source IP and the belonging geographical area are counted according to the invalid access log, and the interface actually accessed by the abnormal access source IP and the corresponding abnormal access amount are determined;
[0041] The effective access amount, access error times, and access performance data of each interface are counted according to the effective access log, and the access quality of the corresponding interface is determined according to the abnormal access amount, the access error times, and the access performance data;
[0042] Whether each interface is an invalid / inefficient interface is judged according to the effective access amount, the access quality, and a preset threshold.
[0043] Further, in an embodiment of the present application, the interface access topology is constructed according to the access resource list, which specifically includes:
[0044] The calling relationship between each interface and an external resource instance is determined according to the access resource list;
[0045] Each interface and a plurality of the external resource instances are taken as nodes, and the topology connection relationship and the actual calling direction between each node are determined according to the calling relationship;
[0046] According to the topological connection relationship and the actual calling direction, the nodes are connected to obtain the interface access topology.
[0047] In another aspect, an embodiment of the present application provides an interface metadata processing apparatus, comprising:
[0048] A project path determination module is configured to read a mirror file of a business project, collect business project information according to the mirror file, and determine a project specific path of the business project in the mirror file.
[0049] A mirror file content detection module is configured to perform security risk detection on the content of the mirror file, detect whether there is a duplicate packaged file, and upload a detection result to a server.
[0050] An interface file searching module is configured to search for an interface file path in the mirror file according to the project specific path through a decompilation technology, and decompress a corresponding interface belonging file and a configuration file to a temporary directory.
[0051] An interface metadata searching module is configured to search for a context configuration of the business project from the configuration file, and search for a corresponding interface address, a request method and an access resource list from the interface belonging file.
[0052] An interface metadata uploading module is configured to upload the context configuration, the interface address, the request method and the access resource list as interface metadata of the business project to the server.
[0053] In another aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for realizing connection communication between the processor and the memory, wherein the program is executed by the processor to realize the interface metadata processing method as described above.
[0054] In another aspect, an embodiment of the present application further provides a storage medium, which is a computer readable storage medium, for computer readable storage, and stores one or more programs, which can be executed by one or more processors to realize the interface metadata processing method as described above.
[0055] The advantages and beneficial effects of the present application will be partially given in the following description, partially will become obvious from the following description, or will be understood through the practice of the present application:
[0056] The embodiment of the application reads a mirror file of a service item, collects service item information according to the mirror file, and determines a specific item path of the service item in the mirror file; the content of the mirror file is subjected to security risk detection, and it is detected whether there is a repeated packaged file; the detection result is uploaded to a server; according to the specific item path, an interface file path in the mirror file is found through a decompilation technology; corresponding interface belonging files and configuration files are decompressed to a temporary directory; a context configuration of the service item is found from the configuration files; a corresponding interface address, a request method and an access resource list are found from the interface belonging files; the context configuration, the interface address, the request method and the access resource list are taken as interface metadata of the service item and are uploaded to the server. The embodiment of the application realizes automatic discovery and collection analysis of the interface metadata, and improves the accuracy and comprehensiveness of collection and analysis of the interface metadata. BRIEF DESCRIPTION OF DRAWINGS
[0057] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following introduces the drawings needed to be used in the embodiments of the present application, and it should be understood that the drawings introduced in the following merely for the convenience of describing part of the embodiments of the technical solutions of the present application, and for those skilled in the art, other drawings can also be obtained without paying creative labor on the premise.
[0058] Figure 1 A step flow chart of the interface metadata processing method provided by the embodiment of the present application;
[0059] Figure 2 An implementation framework schematic diagram of the interface metadata processing method provided by the embodiment of the present application;
[0060] Figure 3 Another step flow chart of the interface metadata processing method provided by the embodiment of the present application;
[0061] Figure 4 A step flow chart of step S101 provided by the embodiment of the present application;
[0062] Figure 5 A step flow chart of step S103 provided by the embodiment of the present application;
[0063] Figure 6 A step flow chart of step S201 provided by the embodiment of the present application;
[0064] Figure 7 A step flow chart of step S203 provided by the embodiment of the present application;
[0065] Figure 8 A step flow chart of step S205 provided by the embodiment of the present application;
[0066] Figure 9 A structural schematic diagram of an interface metadata processing apparatus provided by an embodiment of the present application is shown in the following figure.
[0067] Figure 10 A hardware structural schematic diagram of an electronic device provided by an embodiment of the present application is shown in the following figure.
[0068] Figure 11 A structural schematic diagram of a storage medium provided by an embodiment of the present application is shown in the following figure. DETAILED DESCRIPTION
[0069] Embodiments of the present application are described in detail below with reference to the accompanying drawings. Examples of the embodiments are shown in the drawings, in which the same or similar notations denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by reference to the drawings are exemplary only, and are used only for the purpose of explaining the present application, and should not be understood as limiting the present application. It should be noted that although functional modules are divided in the system schematic diagram, and logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a manner different from the module division in the system schematic diagram, or the order in the flowchart. For the step numbers in the following embodiments, they are only set for the purpose of facilitating the description, and the order between the steps is not limited in any way, and the execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.
[0070] In the description of the present application, the meaning of multiple is two or more, and if the first, the second is described, it is only for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features or implicitly indicating the sequence of indicated technical features. In addition, unless otherwise defined, all technical and scientific terms used herein have the same meaning as understood by those skilled in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.
[0071] A private warehouse Docker image information collection system and a collection method thereof are disclosed in the related art. First, an image to be collected is obtained from a local private image warehouse, and an image layer for information collection is added to the image to build a new image. Then, a container of the new image is started, the image content is read based on a Docker service, and the target compressed file in the image is sent to an image collection center through a network. The image information collected by this scheme only includes the image id, tag, warehouse, and success of the collection result. The interface information contained in the image internal business system cannot be collected, and a new docker image needs to be packaged and run. Considering that the image of the business system is generally about 500MB, and some exceeds 1GB, when a large number of project information needs to be collected, this scheme wastes disk, network, and computing resources.
[0072] A difference analysis method, device, storage medium, and apparatus are also disclosed in the related art. The jar package can be extracted from the docker image file, and then the interface information can be obtained from the jar file using a preset class loader. The disadvantages of this scheme include: 1) accurate information must be manually configured in advance. The acquisition of these information is not only cumbersome but also difficult or even impossible to obtain accurately in advance due to technical barriers. For example, a class loader that can be truly used (can load classes without exceptions and also obtain the annotations of the classes) may need to be specially developed for some projects. This scheme does not provide a technical method for automatically obtaining all preset information; 2) the obtained interface information is limited, and important information such as interface dependencies and potential security risks cannot be found.
[0073] Some people in the industry have proposed that interface metadata can be extracted from source code. This means that a tool for parsing information such as different code branches of Git, SVN, and other version control services needs to be developed, otherwise manual configuration is inevitable. Different code styles can lead to inaccurate parsing of all interface information, thereby increasing the development, design difficulty, and workload of the source code parsing tool. In addition, the lack of information about the deployment environment in the live network during the development stage, as well as repeated changes in design and implementation during the development stage, can easily lead to limited or even useless information that can be discovered by this scheme.
[0074] In summary, the existing technical solutions have deficiencies in accuracy and comprehensiveness in collecting and analyzing interface metadata, and are not easy to extend, which cannot fully utilize the value of interface metadata.
[0075] The present application provides an interface metadata processing method, device, electronic equipment and storage medium to achieve the following purposes:
[0076] 1) Collect the information of the project from the deployment (release) file of the business project to form the project metadata, find the path of the compressed item containing the definition interface from the deployment file, decompress the corresponding file from the deployment file according to the path, and then decompile the file to obtain the code file with unified style;
[0077] 2) Collect and analyze the rich information from the deployment file and the code file: which interfaces (APIs) are contained in a class, the complete method signature of each interface, whether a interface calls other interfaces, which external resources and versions are used by each interface, the way of using resources by each interface, which library files are depended by each interface, the security configuration of each interface, the data validity verification and exception handling of each interface, and other business project and interface metadata sets;
[0078] 3) Support a series of analyses and verifications from the interface dimension, including: ① constructing the interface access topology according to the discovered interface metadata; ② comparing and analyzing the specific security risks of the project image file according to the disclosed software security vulnerability data, the erroneous image packaging behavior and verifying the repair situation; ③ analyzing the business access log according to the interface address, excluding the actual access link error log of external access behavior, so as to accurately calculate the access quality and actual effective access amount of each interface, further supporting the analysis and viewing of the actual consumption of cloud network resources in the interface and business dimensions at any time, improving the efficiency and effect of business service guarantee and business alarm convergence and analysis, and assisting the quantitative analysis and optimization of cloud network resource cost.
[0079] The interface metadata processing method provided by the embodiments of the present application can be applied in a terminal, can also be applied in a server end, and can also be software running in a terminal or a server end. In some embodiments, the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a set-top box, etc.; the server end can be configured as an independent physical server, can also be configured as a server cluster or a distributed system composed of multiple physical servers, can also be configured as a cloud server providing basic cloud computing services such as cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN, and big data and artificial intelligence platform; and the software can be an application for implementing the interface metadata processing method, but is not limited to the above forms.
[0080] The application is operable with numerous general purpose or special purpose computer system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that can be suitable for use with the application include personal computers, server computers, handheld or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. The application can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. The application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.
[0081] It should be noted that in each specific embodiment of the present application, when it is necessary to process relevant data related to the identity or characteristics of the user according to user information, user behavior data, user history data, and user location information, etc., the user's permission or consent will be obtained first, and the collection, use and processing of these data will comply with relevant laws, regulations and standards of the country and region. In addition, when the embodiments of the present application need to obtain sensitive personal information of the user, the separate permission or separate consent of the user will be obtained through a pop-up window or a jump to a confirmation page, and after obtaining the separate permission or separate consent of the user, the necessary user-related data for enabling the embodiments of the present application to normally operate will be obtained.
[0082] First, the implementation framework of the interface metadata processing method of the embodiments of the present application is described as follows: Figure 2The diagram illustrates the implementation framework of the interface metadata processing method provided in this embodiment of the invention. It includes a server, a client, and business projects. The client focuses on automatically parsing and obtaining metadata about the project and its interfaces from the business project's release (deployment) files. The client can be easily deployed and used by various professional companies within the group. The server is primarily responsible for integrating, processing, storing, and analyzing various types of data reported by different clients, including forming a series of call relationships and resource access topologies between interfaces. The server is centrally deployed as a cluster service. Metadata automatically discovered by the client can be saved in a relational database or a NoSQL database. The server provides a database containing tables that store project and interface metadata, as well as publicly available software security risk information. Interface call relationship topology data can be saved in a graph database. Furthermore, the client is also responsible for detecting security risks in business project release files and verifying their resolution; analyzing business access logs based on interface metadata; forming access / call topologies and interface operation quality topologies between projects (release files) based on interface call topologies; and providing management and auditing functions for abnormal information such as inactive interfaces, domains not officially enabled, domains that cannot be configured, and interface addresses with abnormal matching based on business access logs.
[0083] This invention can read extensive interface metadata from the release files of business projects, including interface address, request method, complete method signature and request parameters of the interface implementation, resources used (called) by the interface, error and exception handling mechanisms, security configuration, development framework and third-party dependency libraries (for Java projects, which JAR files are used) and their version information. It can even analyze how many times an interface accesses the database, middleware, whether sensitive data is securely stored, and whether necessary data verification and cleanup are performed. It can easily identify problems in business deployment files (especially image files), such as duplicate packaging of some files. It facilitates the integration of other programming languages for joint development based on Linux systems using Bash scripts, reducing development workload, improving development efficiency, and allowing for flexible adjustments to some details based on actual needs.
[0084] The following describes the process of client-side interface metadata collection, which is to parse the project and its interface metadata from the Docker image file of the business project.
[0085] like Figure 1 The diagram shown is a flowchart of one step of the interface metadata processing method provided in an embodiment of the present invention. (Refer to...) Figure 1 This invention provides an interface metadata processing method, which specifically includes the following steps:
[0086] S101, read the mirror file of the business project, collect the business project information according to the mirror file, and determine the project specific path of the business project in the mirror file;
[0087] S102, perform security risk detection on the content of the mirror file, and detect whether there is a repeated packaged file, and upload the detection result to the server;
[0088] S103, find the interface file path in the mirror file according to the project specific path through the decompilation technology, and decompress the corresponding interface belonging file and the configuration file to the temporary directory;
[0089] S104, find the context configuration of the business project from the configuration file, and find the corresponding interface address, request method and access resource list from the interface belonging file;
[0090] S105, upload the context configuration, interface address, request method and access resource list as the interface metadata of the business project to the server.
[0091] As shown in Figure 4 , a step flow chart of step S101 provided by the embodiment of the application is shown, with reference to Figure 4 , further as an optional implementation, the business project information is collected according to the mirror file, and the project specific path of the business project in the mirror file is determined, which specifically includes:
[0092] S1011, find a preset file name field in the first layer of the mirror file to obtain a target JSON file;
[0093] S1012, parse the target JSON file to obtain the business project information, the business project information including a project maintainer, a business project file working path, a business application file name, a mirror building time, a mirror file size, a mirror file MD5 code, a running environment requirement, an external exposure port number and basic mirror data;
[0094] S1013, read the compressed files of each folder in the mirror file layer by layer, and judge whether the compressed files contain the business project file working path and the business application file name;
[0095] S1014, if yes, determine the project specific path according to the file path of the compressed file.
[0096] As shown in Figure 5 , a step flow chart of step S103 provided by the embodiment of the application is shown, with reference to Figure 5 , further as an optional implementation, the interface file path in the mirror file is found according to the project specific path through the decompilation technology, and the corresponding interface belonging file and the configuration file are decompressed to the temporary directory, which specifically includes:
[0097] S1031, find the compiled class file in the mirror file according to the project specific path;
[0098] S1032, decompile the class file to obtain class definition information, and determine the interface file path according to the class definition information;
[0099] S1033, create a temporary directory, determine the corresponding interface belonging file and configuration file according to the interface file path, and decompress the interface belonging file and the configuration file to the temporary directory.
[0100] Specifically, the process of parsing the project and its interface metadata from the docker mirror file of the business project is as follows:
[0101] 1) Before the business project is newly put into operation or updated to the production environment, the mirror file of the business project to be deployed to the production environment for running can be obtained from the mirror warehouse or CI / CD service at any time, which is actually a file with the extension tar, and the content of the compressed file in this archive format is read through the file input stream;
[0102] 2) In the first layer of the compressed file, the file with a name similar to 8ba951be20c899046f56b0ec64d819a4d06fbc2fa5260988256198b880beeee.json is queried according to the length of the file name and the range of characters constituting the file name, and after finding, the content in the JSON format is read and parsed to obtain the corresponding project maintainer (corresponding to the maintainer field in the file), the built-in actual business project file working path (corresponding to the Working Dir field), the file name of the business application in the compressed file (corresponding to the APP_HOME and APP_NAME fields), the mirror building time (the last created), the size and md5 code of the mirror file, the running environment requirement (JDK / JRE version, language requirement), the exposed port number, the used basic mirror, etc. It can be extended according to the actual work needs and enterprise own specifications;
[0103] 3) Further, read each folder in the mirror file layer by layer to read the content in each folder, check whether the inner compressed file contains the business application path and business file name obtained in the last step, if yes, find the path of the business system compiled and packaged file (also a kind of compressed file) in the mirror, record the path, otherwise, the enterprise can check according to the regular / specified path of this kind of file;
[0104] 4) Continue to read the packaged file of the business item found from the innermost layer of the image based on memory completely according to the format of the corresponding file. The points include:
[0105] a. The actual situation after the release of the project developed according to different software platforms is also a kind of compressed file. According to the layout / distribution specification of the contents in the corresponding type file, for example, the project developed in Java language is often a file with extension jar, war or ear, and the dependent library of the project developed based on Spring Boot is often in the BOOT-INF / lib path of the jar file. The early Java web project is often in the WEB-INF / classes path, and the name of each compressed item in the directory where the project depends on in the compressed file is the file name of the corresponding dependency.
[0106] b. For the case where the software release file is not packaged and compressed but directly packaged into the docker image, it is actually a simplification compared to the method of first packaging according to the selected technical platform and framework of the business item and then packaging into the image, because the required file information can be directly read according to the same file filtering and positioning rules, and there is no need to read the compressed file of the application, and the other analysis processing logic remains unchanged. In this case, attention should be paid to the iteration and analysis of the compressed items in the folder (such as business dependencies) under some technical platforms when analyzing the compressed stream data.
[0107] c. According to the characteristics of the file path and file name and combined with the enterprise's specifications for related names, the compressed item that needs to be processed can be located, so that various business items designed according to architecture modes such as MVC mode and DDD mode can be correctly processed. In such a file, the name of each compressed item can be obtained by further searching for its content to obtain the names of all basic libraries and third-party library files that the business item depends on. The file name generally contains the file version number, if the version number is not included in the dependent library file name, continue to read the corresponding compressed file, and read the dependent version number from the MANIFEST.MF file in the META-INF directory;
[0108] 5) Query from the client to the server which software and libraries have been confirmed to have security vulnerabilities in the recent period (such information is often publicly disclosed on the network). Compare and find out whether there are security risks or vulnerabilities in the above-mentioned results of the dependencies of the business item, and if so, record the specific files that have risks and the repair suggestions obtained according to the industry public information;
[0109] 6) Continue to check other parts of the image based on memory, including the file name contained in the compressed file, and compare with the published security information in the same way as the previous step, if other files outside the project dependency are found to have vulnerabilities or security risks, the corresponding files and their paths in the image, risks and related project information are also recorded and reported to the server. The data obtained so far is uploaded to the server as project metadata for storage;
[0110] 7) For the case where the image is a compressed file inside which multiple layers of different format compressed files are nested, making it easy for the same file to be compressed by different image layers, when the size of the project image file exceeds a certain threshold (configurable), check if the remaining content of the image contains a business project or its dependent file with the same name. If found, it means that the corresponding file is packed repeatedly, and the duplicate file and its path, related project information are recorded and reported to the server;
[0111] 8) Read the contents inside the business project release file obtained in step 3), find the compiled class file, and based on memory, decompile the contents of the class file line by line until the corresponding class definition is confirmed according to the class definition information;
[0112] 9) Create a random folder in the system temporary file directory, decompile each interface class and the Service class it calls found above, and write the entire contents of the decompiled results to the folder below. Here you can control only the bytecodes of the classes or interfaces you need to decompile through black and white lists of classes or interfaces;
[0113] 10) Find the business built-in configuration according to the relative path of the class file in the business release file, and decompress all configuration files under the folder created above according to the same relative path;
[0114] 11) Use operating system commands, tools to find the value of the context-path configuration item that may exist in the properties, yml, yaml format configuration file, and use the found content as the context configuration of the business project;
[0115] 12) Check the project's configuration files according to the naming rules of the project's configuration files, such as application-dev.yml, application-prod.yml, application-test.yml, etc. (extensible) Check the naming rules of the enterprise for such files, such as application-dev.yml, application-prod.yml, application-test.yml, etc. (extensible) Check which configuration files, whether there are IP addresses written in, passwords written directly, configuration files that are unnecessary and should not be used for formal deployment, the type, instance, connection, authentication, namespace of the external service used by the project, and related configuration files, etc. Information;
[0116] 13) Check from project configuration whether some project third-party dependencies of built-in HTTP interface services have been explicitly configured to prohibit starting their HTTP services before going online or have been mistakenly packaged into project release files. These services should only be used in development, testing, and other non-production environments and should not be deployed to production environments as part of business systems. For example, JDBC driver druid, project code documentation service swagger, etc. For the former, check whether the corresponding configuration item druid.stat.http.enable exists and is set to false. For the latter, check whether the relevant jar is included (it should not be included in the production environment) or whether it is prohibited from starting the service through specific configuration. Report the problems found here to the server for processing;
[0117] 14) In view of the current situation that different programming languages and development platforms generally use annotations to define interfaces, for example, Spring Framework mainly uses annotations such as RestController, RequestMapping, GetMapping, PostMapping, PutMapping, and DeleteMapping to develop interfaces, and some annotations can be written only on methods. Therefore, it is necessary to parse the interface data corresponding to the various uses of annotations according to whether the annotations are used on classes or methods, otherwise it may lead to missing interface information or inaccurate data. Solution: Assemble the retrieved code files in the order of find, grep, and custom program through a pipeline to find the content containing any of the target annotations and the next line immediately below from the code files, so that the query results are always paired every two lines. The contents of the two lines are: ① the actual definition of the above-mentioned arbitrary annotation in the file and code where the information is found; ② the actual definition of the class or method corresponding to the annotation found in the file and the previous line, including the method, that is, all the parameters supported by the corresponding interface. Pass the query result information in this format to the next step through a pipeline;
[0118] 15) First, each two rows are taken as a processing unit, and the file path containing the file name, the annotation and whether the content below is a class definition are parsed to obtain the object list of these information. Then each element in the object list is processed in a loop: if an object does not contain a class definition (which means the object contains the definition of a class method, so the complete method signature containing the method name, method parameters and possible thrown exceptions can be obtained) and the annotation contains interface address information, it is a new interface; if the object is a class definition and its annotation contains interface address information, record the path of the class definition, if the object is not a class definition and belongs to the same file as the last processed object, a new interface is also found, the context obtained above and the path information obtained in this way are combined to obtain the interface path (the core part of the complete interface link in the production environment), and the request method can be obtained according to the annotation of each interface, so that the accurate and complete information of each interface in the code can be obtained through the scheme here;
[0119] 16) The interface method signature obtained above can be used to obtain its specific code, and then through the middleware or database client tool class information of different protocols, the information of other interfaces, databases, caches, message queues and other resources that each interface may access when executing can be found from the interface implementation code, including the actual address, port, access method, access trigger condition, and access frequency of each resource for each interface call. These information can clearly show the access and corresponding relationship between the interface and its external resources;
[0120] 17) Similarly, the interface processing exceptions and errors and their ways (such as whether to directly throw an Exception exception, whether to record logs, and whether the recorded information is complete, etc.) can be automatically found from the method code of the interface, and then whether there are IP addresses, other domain names outside the business in the implementation code of the interface are checked, whether there are passwords according to the need of accessing external resources are found, and after finding the password, the length, complexity, commonality and repetition of the password content are checked, so as to find weak password information and record the purpose of the password. Some annotations (including enterprise self-defined annotations) can also be found here to check whether the value settings are reasonable, such as whether the annotation controlling the environment applicable to swagger excludes the production environment, and whether the annotation controlling the excluded startup class is properly configured. The problems found here can be checked and compared again after the project is updated to confirm whether they have been fixed;
[0121] 18) The information obtained above is uploaded to the server as project, interface metadata, and then the temporary files and folders generated in the above process are deleted from the client.
[0122] It should be noted that if the release file of the business project is not an image, for example, a jar or war file, the technical solution in this case is actually a subset of the above solution: first obtain the uniform resource descriptor object corresponding to the file, and then analyze and process the content of the release file in a targeted compressed file manner according to the above solution.
[0123] Compared with the scheme of obtaining interface addresses and business call topology information based on logs, injecting bytecode into runtime business system processes, directly modifying development codes, etc., the present scheme is simple to implement, has low resource consumption of the corresponding client tool runtime, can be flexibly deployed on any server (including non-production servers), does not need to have any impact on the codes in the development process and the runtime business system, can obtain extensive metadata of interfaces and their belonging business projects, does not need to rely on the originally developed codes, can avoid cross-department coordination and code security issues, can discover and handle possible vulnerabilities and other security risks of the business system in time before the project goes online, and can obtain more in-depth data such as topology relationships between business functions / interfaces and their dependencies (other interfaces, middleware, databases, etc.), specific number of interface calls to each external resource, and characteristics of interface implementation, which cannot be obtained by other schemes.
[0124] The process of implementing interface metadata analysis on the server side will be described below.
[0125] The deficiencies of common business access log analysis services include that a large amount of static files (css, js, pictures, etc.) and abnormal access behavior logs are included in the actual interface access logs, it is difficult to determine whether the abnormal logs are normal business access behavior logs only by the data of the abnormal logs, and it is easy to ignore interfaces with low activity or low activity rate based on logs in a period of time, resulting in the inability to evaluate the efficiency, quality and running performance of interface development by using log data.
[0126] To solve the above problems, the present embodiment calculates the actual access logs of the business project to obtain information including interface access (normal and abnormal access) conditions, error interface link information, and further obtain real access volume after the business project is deployed online, and interfaces that are rarely or never accessed.
[0127] In addition, the related art discloses a vulnerability repair method, device and container cluster management system, which can also find the vulnerabilities in the image, and it needs to extract the project dependencies from the project deployment configuration file, or decompress the image to the disk, and then read / iterate the decompressed file to find the image operating system and the software package and version number installed therein, and then determine whether there is a vulnerability according to the information. Disadvantages of the scheme: ① needs to rely on other files outside the project deployment file; ② does not involve how to successfully image different formats of compressed files; ③ cannot detect vulnerabilities of software packages not installed in the image operating system, and cannot detect vulnerabilities of software packages whose file names do not contain version numbers. If the software vulnerability is located in the file packaged after the project, and then embedded in the image, the scheme does not explain whether it can be processed; ④ low performance, considering that the image file often has several hundred MB or even larger, and decompression processing of a large number of image files also requires disk space. The embodiments of the present application can also overcome the above problems.
[0128] As Figure 3 shown is another step flow chart of the interface metadata processing method provided by the embodiments of the present application, referring to Figure 3 , further as an optional implementation manner, the interface metadata processing method further includes the following steps:
[0129] S201, updating the software security information library of the server according to the interface metadata, and performing project early warning according to the interface metadata and the detection result;
[0130] S202, generating the function description corresponding to each interface according to the interface metadata;
[0131] S203, filtering invalid access logs according to the interface metadata, and performing abnormal access analysis, and then calculating the effective access amount and access quality of each interface, and determining the invalid / inefficient interface according to the effective access amount and access quality;
[0132] S204, classifying each interface according to the function description, obtaining a plurality of interface categories, and then determining the number of interfaces, the interface distribution position and the total effective access amount of each interface category;
[0133] S205, constructing the interface access topology according to the access resource list, and providing the interface access topology to the client through the server.
[0134] As Figure 6 shown is a step flow chart of step S201 provided by the embodiments of the present application, referring to Figure 6 , further as an optional implementation manner, the project early warning according to the interface metadata and the detection result specifically includes:
[0135] S2011, determining whether the image file has a security risk and whether there is a duplicate packaged file according to the detection result;
[0136] S2012, when the mirror file has a security risk and / or a repeated packaged file, determining a project maintainer according to the interface metadata, and issuing a project warning to the project maintainer;
[0137] The project warning is used to remind the project maintainer to formally deploy after repairing the mirror file.
[0138] As shown in Figure 7 Fig. 3 is a step flow chart of step S203 provided by the embodiment of the application, with reference to Figure 7 Further, as an optional implementation, the invalid access log is filtered according to the interface metadata, and abnormal access analysis is performed, and then the effective access amount and the access quality of each interface are calculated, the invalid / inefficient interface is determined according to the effective access amount and the access quality, and the specific process includes the following steps.
[0139] S2031, determining the interface address, the request method and the access resource list according to the interface metadata;
[0140] S2032, determining the corresponding target service according to the access resource list, and querying the access log of the target service according to the interface address and the request method to obtain the effective access log, and taking the access log not belonging to the effective access log as the invalid access log;
[0141] S2033, according to the invalid access log, the abnormal access source IP and the belonging geographical area are counted, and the interface actually accessed by the abnormal access source IP and the corresponding abnormal access amount are determined;
[0142] S2034, according to the effective access log, the effective access amount, the access error times and the access performance data of each interface are counted, and the access quality of the corresponding interface is determined according to the abnormal access amount, the access error times and the access performance data;
[0143] S2035, according to the effective access amount, the access quality and the preset threshold value, it is judged whether each interface is an invalid / inefficient interface.
[0144] As shown in Figure 8 Fig. 4 is a step flow chart of step S205 provided by the embodiment of the application, with reference to Figure 8 Further, as an optional implementation, the interface access topology is constructed according to the access resource list, and the specific process includes the following steps.
[0145] S2051, according to the access resource list, the calling relationship between each interface and the external resource instance is determined;
[0146] S2052, each interface and a plurality of external resource instances are taken as nodes, the topological connection relationship and the actual calling direction between each node are determined according to the calling relationship;
[0147] S2053, connect each node according to the topological connection relationship and the actual calling direction to obtain an interface access topology.
[0148] Specifically, the process of implementing interface metadata analysis by the server is as follows:
[0149] 1) The server stores the interface metadata of the business project obtained above, including which image files, projects and interfaces are analyzed. In addition, according to the latest security vulnerability information of industry open software and public libraries, a local software security information database is established and continuously updated;
[0150] 2) The server summarizes all the vulnerabilities and security risk information found above, and alarms the maintainer of the relevant project in units of projects, reminding that the formal deployment should be carried out after the problem is repaired. Next, after the new image is constructed, the corresponding files in the business image are automatically checked according to the above steps to see if the problem has been updated and repaired, if updated, the problem solving time is recorded according to the "modified time" field in the corresponding compressed file, otherwise, it is recorded as not repaired and an alarm is given to the user.
[0151] 3) Using the interface address and interface implementation method code obtained above, a simple introduction of the project business can also be added, using LoRA based on Qianwen or other large language model training, fine-tuning the function description of the interface. In this way, a private large language model suitable for the development specifications and habits of an enterprise can be obtained, which can accurately judge the purpose of an interface; then the new large model data is obtained by merging the trained model data and the original model data using LoRA. The new large language model is used to generate the function and purpose description of each interface found above based on the address, code and project information of the interface, as part of the metadata of each interface;
[0152] 4) According to the accurate interface address automatically found above, all request parameters supported by the interface, and the request method supported by the interface, query the access log of the corresponding service. The combination of actual access address, request method and request parameter is the same as the log of a certain interface link, which is a valid access log. Invalid access logs from public networks should be excluded (such as interface and data scanning, attacking business systems, etc.), and other access logs of project static files should also be excluded;
[0153] 5) Abnormal access judgment and analysis: according to the information obtained in the previous part, find the abnormal access source IP and the geographical region it belongs to, check the access log of each access source actually accessing the correct interface address, and calculate the abnormal access amount of the interface and the corresponding interface that needs to be paid attention to;
[0154] 6) According to the remaining valid access logs, the access volume of each interface within a certain time, the last access time, the access quality (the number of access errors and abnormal access times, access performance, etc.) data are calculated, and the average, maximum, minimum and variance of each index can be calculated;
[0155] 7) According to the interface list of actual project modules, microservices, projects, and product dimensions, support adjusting which interfaces each dimension contains according to actual work needs, calculate the access volume and access / running quality of each dimension of modules, microservices, projects, and products. Further, according to the access volume and access quality, all interfaces are divided into different levels, highlighting higher levels, lower levels, and all interfaces with no access volume or access volume below a certain threshold. According to the project release file, the corresponding interface decompiled code is provided for viewing at any time through the UI;
[0156] 8) According to the access volume and access quality, combined with the interface code volume obtained from the decompiled interface compiled file or the interface code volume calculated from the actual source code, the access volume and access quality of each category of interface and the corresponding code volume are calculated and analyzed, and the access volume and access quality of the actual developed code are highlighted. Interfaces with access volume below a certain threshold can be considered as invalid or inefficient interfaces. This data can be used to analyze and compare the application efficiency of the actual developed code and set different efficiency levels in combination with the actual situation. Through quantitative data, interfaces with different code efficiency levels, related projects, and even developers are highlighted. The data obtained from the above steps is synchronized and marked on the interface topology, and the interface address that cannot find access records is recorded as an inactive interface;
[0157] 9) Remove parameters and extract the part after the rightmost slash in all actual interface links. Next, the word embedding, text classification model or large language model finds other interfaces with the same or similar functions as the interface. In this way, the functions of all interfaces are classified according to semantics, the similarity between interfaces is recorded, the number of specific interfaces contained in each interface category, the distribution in which categories, and the total access volume of each category of interface are calculated. The historical problems of the interface can be further used as a classification standard, and the resulting category can be used as a label reflecting the characteristics of the interface. Further, the functions or function categories of interfaces with very little or very high access volume, and even code similarity are found;
[0158] 10) According to the resource accessed by an interface (including other interfaces), draw the calling topology relationship from the interface to each external resource (other interfaces called by the interface and middleware, database) instance, the business to which the topology belongs, use different shapes of nodes to represent the interface and different types of external resources, show the access address for each node, further add the topology relationship of other interfaces on the topology, and connect the interfaces with actual calling relationship on the topology graph according to the actual calling direction, which can increase the level of the topology, so as to provide a multi-level interface calling topology graph for any interface and different types of external middleware and databases called by the interface on the service side UI. According to the one-to-one correspondence between the log source, destination and the corresponding topology node and connecting line, mark the interface access quality data obtained above to the corresponding topology node and connecting line, and draw the access times of the corresponding external resource on the topology graph according to the interface access log according to the access times of the external resource corresponding to the interface and the access trigger condition;
[0159] 11) The service side can also provide a series of services with actual value to the outside by comprehensively integrating the interface metadata of all business projects, for example: ① Through the UI, intuitively show all interfaces and database and middleware resources on the interface calling chain; ② When an alarm or fault occurs in an interface, based on the calling relationship between interfaces and the external resources depended by the interface, it is convenient to find the interface at the bottom of the calling chain, or analyze the influence range of the alarm and fault of an interface and whether the runtime problem of the interface is affected by the interfaces called by it; ③ By merging the alarm data of each interface on the interface calling joint debugging, realize convergent alarm and control the number of alarms notified to the user, etc.
[0160] 12) Analyze the interface access volume that can be served by each project unit computing resource (such as 1 core CPU 1 GB memory) in a certain time (such as every day) in combination with the servers and CPU and memory configurations actually deployed by the project to which the interface belongs, calculate the project traffic that can be served by each unit of computing resource after merging the input and output traffic of all interfaces of the project, as the interface resource utilization of the project, support quantitative analysis of which functions, execution / access times use the resource in any time period and the resource usage and usage rate from the business point of view according to business and department.
[0161] The method steps of the embodiments of the application are described above, and it can be recognized that the embodiments of the application realize automatic discovery and collection and analysis of interface metadata, and improve the accuracy and comprehensiveness of collection and analysis of interface metadata. The application will be further described below in combination with a specific embodiment.
[0162] In order to collect and report a series of business public network-oriented open interface information and find out the security risks of the interface, an Internet enterprise A spent several months to mobilize employees to manually collect and summarize open interface information, and access randomly generated interface links to the business domain name. Although long-term manpower research and development and a large amount of manual work were invested, problems such as incomplete reported data, incomplete interface links, data errors and non-standard, duplication, and a large amount of garbage data were still encountered. Based on the interface metadata processing method provided by the application, the interface information facing the internal and external networks can be automatically collected, and the accurate links and request methods of all public network-oriented open interfaces can be automatically obtained without manual intervention. The result data also helps to take the interface as the basis and object for in-depth resource management and protection. The main implementation steps are as follows:
[0163] 1) From the CI / CD service or the plug-in of the packaged image using maven, gradle, after the business system is packaged into an image or a jar file, the tool analyzes the business release file automatically;
[0164] 2) The client tool can report the metadata of each project and its interface from the server side at any time, and can see which project release file has been analyzed and processed. It can also further accurately obtain all interface addresses of the project and whether the implementation conforms to the specification and whether there is a risk;
[0165] 3) Further, it can be seen whether there is any security vulnerability in any project according to the latest public software security risk information, and it can also specifically understand the specific information such as the risk existing and whether the risk has been repaired;
[0166] 4) The result of the interface metadata analysis is also helpful for analyzing the resource consumption of the business from the interface dimension, which helps to find out where the resource consumption of the business is mainly on the function and interface, so as to promote the adjustment of the function range of different projects and achieve the purpose of controlling the resource use.
[0167] It can be recognized that the embodiments of the present application can automatically collect the "extensive" metadata of the business project and its interface, including the project and its dependencies, interface address, key implementation features of the interface, from the project release files used for formal deployment after packaging, before the project goes online, further support automatic checking of security risks and repair of project dependencies and interface implementation, without manual intervention, without cross-department coordination, and also avoiding the risk of source code security. In addition, the embodiments of the present application comprehensively integrate the client and the server, realize the interface access resource and the calling relationship topology between interfaces based on the interface metadata, further analyze the business access log based on the interface metadata, evaluate and determine the actual access volume, abnormal access volume and access quality of the interface, module, microservice, project and product dimensions, synchronously provide specific interfaces of different access volume and access quality levels, corresponding code and corresponding R&D efficiency and quality quantization data, and automatically provide interface feature reflecting labels and resource utilization rate of the interface dimension of the business project based on interface function semantics.
[0168] Compared with the prior art, the embodiments of the present application also have the following advantages:
[0169] 1) The scheme development is simple and convenient to use, can be flexibly deployed, can effectively reduce unnecessary cross-department communication and cooperation, so that the operation and maintenance department can independently complete the gateway work, can accurately find out the extensive metadata information of the interface and the business project to which the interface belongs based on the release file of the business project;
[0170] 2) Support drawing the actual topology of the external middleware, database and calling relationship between interfaces from the interface metadata, and centering on the interface;
[0171] 3) Support taking the interface address as an important resource, and deepening the management of the business project and its resources to the management based on interface information, which is helpful to quickly and accurately find out the inactive or rarely accessed interfaces by combining the interface topology, and is helpful to control the use of cloud network resources by adjusting the functional range of different projects;
[0172] 4) The interface topology data is widely applied and has great practical value, including that the number of alarm notifications sent to the operation and maintenance personnel can be compressed according to the interface calling topology, and it is helpful to find out the underlying factors causing interface problems.
[0173] As Figure 9 shown is a structure schematic diagram of an interface metadata processing device provided by the embodiments of the present application, with reference to Figure 9 , the embodiments of the present application provide an interface metadata processing device, which comprises:
[0174] A project path determination module is configured to read the mirror image file of the business project, collect the business project information according to the mirror image file, and determine the specific project path of the business project in the mirror image file.
[0175] The mirror file content detection module is configured to detect the security risk of the content of the mirror file, detect whether there is a repeated packaged file, and upload the detection result to the server;
[0176] The interface file searching module is configured to search the interface file path in the mirror file according to the specific path of the project through the decompilation technology, and decompress the corresponding interface belonging file and the configuration file to a temporary directory;
[0177] The interface metadata searching module is configured to search the context configuration of the business project from the configuration file, and search the corresponding interface address, request method and access resource list from the interface belonging file;
[0178] The interface metadata uploading module is configured to upload the context configuration, the interface address, the request method and the access resource list as the interface metadata of the business project to the server.
[0179] The content in the method embodiments is applicable to the device embodiments, the device embodiments specifically implement the same functions as the method embodiments, and achieve the same beneficial effects as the method embodiments.
[0180] The embodiment of the application further provides an electronic device, which comprises a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for realizing connection and communication between the processor and the memory, and the program is executed by the processor to realize the interface metadata processing method. The electronic device can be any intelligent terminal including a tablet computer, a vehicle-mounted computer and the like.
[0181] As Figure 10 shown is a hardware structure schematic diagram of an electronic device provided by the embodiment of the application, with reference to Figure 10 , the embodiment of the application provides an electronic device, which comprises:
[0182] The processor 1001 can be realized in the mode of a general CPU (Central Processing Unit, central processor), a microprocessor, an ASIC (Application Specific Integrated Circuit, application specific integrated circuit) or one or more integrated circuits, is used for executing a related program to realize the technical scheme provided by the embodiment of the application;
[0183] The memory 1002 can be implemented in the form of a read only memory (ROM), a static storage device, a dynamic storage device or a random access memory (RAM), etc. The memory 1002 can store an operating system and other application programs, and when the technical solutions provided by the embodiments of the present specification are implemented by software or firmware, the related program codes are stored in the memory 1002 and are called and executed by the processor 1001 to implement the interface metadata processing method of the embodiments of the present application;
[0184] The input / output interface 1003 is used to realize information input and output.
[0185] The communication interface 1004 is used to realize the communication interaction between the device and other devices, which can realize communication through wired mode (such as USB, network cable, etc.) or wireless mode (such as mobile network, WIFI, Bluetooth, etc.).
[0186] The bus 1005 transmits information between various components (such as the processor 1001, the memory 1002, the input / output interface 1003 and the communication interface 1004) of the device.
[0187] The processor 1001, the memory 1002, the input / output interface 1003 and the communication interface 1004 are connected to each other through the bus 1005 for communication connection within the device.
[0188] As shown in Figure 11 The structure of the storage medium provided by the embodiments of the present application is shown in the structure diagram of the storage medium provided by the embodiments of the present application. As Figure 11 The embodiments of the present application also provide a storage medium, which is a computer readable storage medium, for computer readable storage, and the storage medium stores one or more programs 1101, which can be executed by one or more processors to implement the above interface metadata processing method.
[0189] The memory as a non-transitory computer readable storage medium can be used to store non-transitory software programs and non-transitory computer executable programs. In addition, the memory can include a high-speed random access memory and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device or other non-transitory solid-state memory device. In some embodiments, the memory can optionally include a memory remotely arranged relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.
[0190] The embodiments of the present application further disclose a computer program product or computer program, which comprises computer instructions stored in a computer readable storage medium. A processor of a computer device can read the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the computer device to perform the method shown in the embodiments. Figure 1
[0191] In some alternative embodiments, the functions / operations mentioned in the block diagrams can not occur in the order mentioned in the operation diagrams. For example, depending on the functions / operations involved, two blocks shown in succession can actually be executed substantially concurrently or the blocks can sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flow diagrams of the present application are only examples. The steps presented and described in the flow diagrams are provided by way of example in order to provide a more thorough understanding of the technology. The disclosed methods are not limited to the operations and logical flows presented in the specification. Alternative embodiments are contemplated in which the order of various steps is changed and in which sub-steps of a larger step are performed in parallel with each other.
[0192] Furthermore, although the present application is described in the context of functional modules, it is to be understood that one or more of the functions and / or features described above can be integrated in a single physical device and / or software module, or one or more functions and / or features can be implemented in separate physical devices or software modules, unless otherwise specified. It is also to be understood that detailed discussion of the actual implementation of each module is unnecessary to an understanding of the present application. Rather, the actual implementation is within the routine skill of engineers familiar with the properties, functions and internal relationships of the various functional modules disclosed in the devices herein. Accordingly, the present application is not limited to purely hardware implementations, but also encompasses software implementations, including firmware, resident software, micro-code, etc. It is further understood that the disclosed specific concepts are merely illustrative and not intended to limit the scope of the present application, which is defined by the full scope of the appended claims and equivalents thereof.
[0193] If the above functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or parts of the technical solutions that essentially contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described above in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.
[0194] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a list of executable instructions for implementing logic functions, which can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus or device, such as a computer-based system, a system including a processor or other system that can fetch the instructions from the instruction execution system, apparatus or device and execute the instructions, or in conjunction with these instructions execution systems, apparatus or devices. For the purpose of this specification, the "computer-readable medium" can be any device that can contain, store, communicate, propagate or transport programs for use by or in connection with an instruction execution system, apparatus or device, or in conjunction with these instruction execution systems, apparatus or devices.
[0195] More specific examples (a non-exhaustive list) of the computer-readable medium include the following: an electrical connection having one or more wires (electrical devices), a portable computer diskette (magnetic devices), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium can even be paper or other suitable medium on which the aforementioned programs can be printed, because the aforementioned programs can be obtained electronically, for example, by optical scanning of the paper or other medium, followed by editing, interpreting or otherwise processing, if necessary, in other suitable ways, to be stored in the computer memory.
[0196] It should be understood that various parts of the present application can be implemented in hardware, software, firmware or a combination thereof. In the above embodiments, various steps or methods can be implemented in software or firmware that is stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any of the following technologies, known in the art, or their equivalents, can be employed for implementation: discrete logic circuitry having logic gates for implementing logic functions upon data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.
[0197] In the above description of the present specification, the description of the terms "one embodiment / one example", "another embodiment / another example", or "certain embodiments / certain examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiments or examples are included in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Also, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.
[0198] Although the embodiments of the present application have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made thereto without departing from the principles and spirit of the present application, the scope of which is defined by the claims and their equivalents.
[0199] The above is a specific description of the preferred embodiments of the present application, but the present application is not limited to the above-described embodiments, and those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present application, and these equivalent modifications or substitutions are included in the scope defined by the claims of the present application.
Claims
1. An interface metadata processing method, characterized by, The method comprises the following steps: reading a mirror file of a business project, collecting business project information according to the mirror file, and determining a project specific path of the business project in the mirror file; performing security risk detection on the content of the mirror file, detecting whether there is a repeated packaged file, and uploading the detection result to a server; finding an interface file path in the mirror file according to the project specific path through a decompilation technology, and decompressing a corresponding interface belonging file and a configuration file to a temporary directory; finding a context configuration of the business project from the configuration file, and finding a corresponding interface address, a request method and an access resource list from the interface belonging file; uploading the context configuration, the interface address, the request method and the access resource list as interface metadata of the business project to the server; the collecting business project information according to the mirror file and determining the project specific path of the business project in the mirror file specifically comprises: finding a target JSON file in a first layer of the mirror file according to a preset file name field; parsing the target JSON file to obtain the business project information, wherein the business project information comprises a project maintainer, a business project file working path, a business application file name, a mirror building time, a mirror file size, a mirror file MD5 code, a running environment requirement, an external exposure port number and basic mirror data; reading compressed files in each folder inside the mirror file layer by layer, and judging whether the compressed files contain the business project file working path and the business application file name; if yes, determining the project specific path according to the file path of the compressed file.
2. The interface metadata processing method of claim 1, wherein, The interface metadata processing method further comprises the following steps: updating a software security information library of the server according to the interface metadata, and performing project early warning according to the interface metadata and the detection result; generating a function description corresponding to each interface according to the interface metadata; filtering invalid access logs according to the interface metadata, and performing abnormal access analysis, thereby calculating an effective access amount and an access quality of each interface, and determining invalid / inefficient interfaces according to the effective access amount and the access quality; classifying each interface according to the function description to obtain a plurality of interface categories, and further determining the number of interfaces, the interface distribution position and the total effective access amount of each interface category; constructing an interface access topology according to the access resource list, and providing the interface access topology to a client through the server.
3. The interface metadata processing method of claim 1, wherein, the finding an interface file path in the mirror file according to the project specific path through a decompilation technology, and decompressing a corresponding interface belonging file and a configuration file to a temporary directory specifically comprises: finding a compiled class file in the mirror file according to the project specific path; decompiling the class file to obtain class definition information, determining the interface corresponding to the class file according to the class definition information, and further determining the interface file path; create a temporary directory, determine the interface file path according to the corresponding file and the configuration file of the interface, and decompress the interface file and the configuration file to the temporary directory.
4. The interface metadata processing method of claim 2, wherein, The project warning according to the interface metadata and the detection result specifically includes: According to the detection result, determine whether the mirror file has security risks and whether there are duplicate packaged files; When the mirror file has security risks and / or duplicate packaged files, determine the project maintainer according to the interface metadata, and send the project warning to the project maintainer; The project warning is used to remind the project maintainer to formally deploy after repairing the mirror file.
5. The interface metadata processing method of claim 2, wherein, The invalid access log is filtered according to the interface metadata, and abnormal access analysis is performed, and then the effective access amount and access quality of each interface are calculated, and the invalid / inefficient interface is determined according to the effective access amount and the access quality, which specifically includes: According to the interface metadata, determine the interface address, the request method and the access resource list; According to the access resource list, determine the corresponding target service, and query the access log of the target service according to the interface address and the request method to obtain the effective access log, and the access log not belonging to the effective access log is taken as the invalid access log; According to the invalid access log, the abnormal access source IP and the corresponding geographic area are determined, and the interface actually accessed by the abnormal access source IP and the corresponding abnormal access amount are determined; According to the effective access log, the effective access amount, access error times and access performance data of each interface are counted, and the access quality of the corresponding interface is determined according to the abnormal access amount, the access error times and the access performance data; According to the effective access amount, the access quality and the preset threshold, determine whether each interface is invalid / inefficient.
6. The interface metadata processing method of claim 2, wherein, The interface access topology is constructed according to the access resource list, which specifically includes: According to the access resource list, determine the calling relationship between each interface and the external resource instance; Each interface and a plurality of external resource instances are taken as nodes, the topological connection relationship and the actual calling direction between each node are determined according to the calling relationship; According to the topological connection relationship and the actual calling direction, connect each node to obtain the interface access topology.
7. An interface metadata processing apparatus characterized by comprising: It includes: The project path determination module is used to read the mirror file of the business project, collect business project information according to the mirror file, and determine the project specific path of the business project in the mirror file; The mirror file content detection module is used for security risk detection of the content of the mirror file, and detection of whether there are duplicate packaged files, and the detection result is uploaded to the server; The interface file finding module is used to find the interface file path in the mirror file according to the project specific path through the decompilation technology, and decompress the corresponding interface file and the configuration file to the temporary directory; An interface metadata searching module is configured to search for a context configuration of the service item from the configuration file and search for a corresponding interface address, a request method and an access resource list from a file to which the interface belongs; An interface metadata uploading module is configured to upload the context configuration, the interface address, the request method and the access resource list as interface metadata of the service item to a server; The service item information is collected according to the mirror file, and a specific item path of the service item in the mirror file is determined, which specifically includes: A preset file name field is searched in a first layer of the mirror file to obtain a target JSON file; The target JSON file is parsed to obtain the service item information, which includes an item maintainer, a service item file working path, a service application file name, a mirror building time, a mirror file size, a mirror file MD5 code, a running environment requirement, an external exposure port number and basic mirror data; Compressed files in each folder inside the mirror file are read layer by layer, and it is determined whether the compressed files contain the service item file working path and the service application file name; If yes, the specific item path is determined according to a file path of the compressed file.
8. An electronic device, comprising: The electronic device includes a memory, a processor, a program stored on the memory and executable on the processor, and a data bus for realizing connection communication between the processor and the memory, and the program is executed by the processor to realize the steps of the interface metadata processing method in any one of claims 1 to 6.
9. A storage medium, the storage medium being a computer-readable storage medium for computer-readable storage, characterized in that, The storage medium stores one or more programs, and the one or more programs are executable by one or more processors to realize the steps of the interface metadata processing method in any one of claims 1 to 6.
Citation Information
Patent Citations
Mirror image construction method, server, client, storage medium and system
CN112416512A
Method and equipment for converting iso mirror image into container mirror image
CN114296864A