Business processing method and related equipment

Abstract

The invention discloses a service processing method and related equipment, and relates to the technical field of data processing, and the method comprises the steps: in the case that a client does not log in, in response to a service processing request of the client, extracting a first authorization code from the service processing request, the first authorization code being a request authorization logic of the client based on the client, the service processing request is obtained after API interface parameters corresponding to the service processing request are processed; processing the API interface parameter based on a local permission authorization logic to obtain a second authorization code; and judging whether the second authorization code is the same as the first authorization code, if so, determining that the client passes verification, and returning service data corresponding to the service processing request. According to the method and the device, the first authorization code in the service processing request is directly verified based on the local permission authorization logic of the server side, so that a tedious login and registration process in a service processing process is avoided while safety verification is realized, and the service processing response speed is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a business processing method and related equipment. Background Art

[0002] With the rapid development of the Internet of Things (IoT) and smart home technologies, the demand for real-time interaction between massive devices and servers has increased dramatically.

[0003] In the current Internet of Things or smart home scenarios, when clients such as robots need to obtain business-related data from the server, they must first log in and register. However, this increases the interaction time, resulting in slow business processing response and poor timeliness.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is related technology. Summary of the Invention

[0005] The main purpose of this application is to provide a business processing method and related equipment, aiming to solve the technical problem of slow business processing response and poor timeliness when clients such as robots need to obtain business-related data from the server.

[0006] To achieve the above objectives, the present application proposes a service processing method, which is applied to the server side. The service processing method includes:

[0007] When the client is not logged in, in response to a business processing request from the client, extracting a first authorization code from the business processing request, where the first authorization code is obtained by the client processing API interface parameters corresponding to the business processing request based on the client's request authorization logic;

[0008] Based on the local authorization logic, the API interface parameters are processed to obtain a second authorization code;

[0009] Determine whether the second authorization code is the same as the first authorization code. If they are the same, determine that the client has passed the verification and return the business data corresponding to the business processing request.

[0010] In one embodiment, the step of processing the API interface parameters based on the local authorization logic to obtain the second authorization code further includes:

[0011] Determining a request type corresponding to the business processing request;

[0012] Based on the authorization logic corresponding to the request type, the API interface parameters are processed to obtain a second authorization code.

[0013] In one embodiment, if the request type is a POST request type or a PUT request type, the step of processing the API interface parameters based on the authorization logic corresponding to the request type to obtain the second authorization code further includes:

[0014] If the request type is a POST request type or a PUT request type, determine whether there are multiple layers of JSON nesting in the API interface parameters;

[0015] If it exists, determine the non-JSON nested fields, JSON nested fields, and the first field value corresponding to each field in each layer of JSON nesting;

[0016] Based on the first sorting logic corresponding to the preset non-json nested field, the second sorting logic corresponding to the preset nested layer and the first field value, the non-json nested fields and json nested fields in the API interface parameters are sorted to obtain a second authorization code.

[0017] In one embodiment, if the request type is a GET request type or a DELETE request type, the step of processing the API interface parameters based on the authorization logic corresponding to the request type to obtain the second authorization code further includes:

[0018] If the request type is a GET request type or a DELETE request type, determining a target field having a key value in the API interface parameter, and determining a second field value corresponding to the target field;

[0019] Based on the preset third sorting method corresponding to the target field and the second field value, the target field is sorted to obtain a second authorization code.

[0020] In one embodiment, the service processing request further includes a first timestamp and a current globally unique random string, and the step of determining whether the second authorization code is the same as the first authorization code further includes:

[0021] Extracting a first timestamp and a current globally unique random string from the business processing request, and determining a second timestamp corresponding to the current moment;

[0022] Calculating the difference between the first timestamp and the second timestamp to obtain a time difference, and determining whether the time difference is less than or equal to a preset time difference threshold to obtain a first determination result; searching a local globally unique random string verification library for a historical globally unique random string that is identical to the current globally unique random string to obtain a second determination result, wherein the globally unique random string verification library is constructed based on all historical globally unique random strings;

[0023] Based on the first judgment result and the second judgment result, it is determined whether the second authorization code is the same as the first authorization code.

[0024] To achieve the above objectives, the present application proposes a service processing method, which is applied to a client. The service processing method includes:

[0025] Get API interface parameters and local request authorization logic;

[0026] Based on the request authorization logic, the API interface parameters are processed to obtain a first authorization code, and a first timestamp corresponding to the processing of the API interface parameters is determined;

[0027] A business processing request is generated based on the first authorization code, the first timestamp and the local current globally unique random character string, and the business processing request is sent to the server side for the server side to verify whether the business processing is allowed.

[0028] In one embodiment, the step of processing the API interface parameters based on the request authorization logic to obtain the first authorization code further includes:

[0029] Determine the business processing type corresponding to the API interface parameters;

[0030] Based on the request authorization logic corresponding to the business processing type, the API interface parameters are processed to obtain a first authorization code.

[0031] In one embodiment, if the business processing type is a POST request type or a PUT request type, the step of processing the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain the first authorization code further includes:

[0032] If the business processing type is a POST request type or a PUT request type, determine whether there are multiple layers of JSON nesting in the API interface parameters;

[0033] If it exists, determine the non-JSON nested fields, JSON nested fields, and the first field value corresponding to each field in each layer of JSON nesting;

[0034] Based on the first sorting logic corresponding to the preset non-json nested field, the second sorting logic corresponding to the preset nested layer and the first field value, the non-json nested fields and json nested fields in the API interface parameters are sorted to obtain a second authorization code.

[0035] In one embodiment, if the business processing type is a GET request type or a DELETE request type, the step of processing the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain the first authorization code further includes:

[0036] If the business processing type is a GET request type or a DELETE request type, determining a target field having a key value in the API interface parameter, and determining a second field value corresponding to the target field;

[0037] Based on a preset third sorting method corresponding to the target field and the second field value, the target field is sorted to obtain a first authorization code.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a service processing device, which is applied to a server side. The service processing device includes:

[0039] a response module, the response module being configured to, in response to a business processing request from a client when the client is not logged in, extract a first authorization code from the business processing request, the first authorization code being obtained by the client processing API interface parameters corresponding to the business processing request based on the client's request authorization logic;

[0040] A data processing module, configured to process the API interface parameters based on local authorization logic to obtain a second authorization code;

[0041] A judgment module is used to judge whether the second authorization code is the same as the first authorization code. If they are the same, it is determined that the client has passed the verification and the business data corresponding to the business processing request is returned.

[0042] In one embodiment, the data processing module further includes:

[0043] A first determining unit, configured to determine a request type corresponding to the business processing request;

[0044] The first data processing unit is used to process the API interface parameters based on the authorization logic corresponding to the request type to obtain a second authorization code.

[0045] In one embodiment, if the request type is a POST request type or a PUT request type, the data processing module further includes:

[0046] The second determining unit is configured to determine whether there are multiple layers of JSON nesting in the API interface parameters if the request type is a POST request type or a PUT request type;

[0047] A third determining unit is configured to determine, if any, non-JSON nested fields, JSON nested fields, and a first field value corresponding to each field in each layer of JSON nesting;

[0048] The first sorting unit is used to sort the non-JSON nested fields and JSON nested fields in the API interface parameters based on the first sorting logic corresponding to the preset non-JSON nested fields, the second sorting logic corresponding to the preset nested layer, and the first field value to obtain a second authorization code.

[0049] In one embodiment, if the request type is a GET request type or a DELETE request type, the data processing module further includes:

[0050] a fourth determining unit, configured to, if the request type is a GET request type or a DELETE request type, determine a target field having a key value in the API interface parameter, and determine a second field value corresponding to the target field;

[0051] The second sorting unit is configured to sort the target field based on a preset third sorting method corresponding to the target field and the second field value to obtain a second authorization code.

[0052] In one embodiment, the service processing request further includes a first timestamp and a current globally unique random string, and the judgment module further includes:

[0053] a fifth determining unit, configured to extract the first timestamp and the current globally unique random string from the service processing request, and determine a second timestamp corresponding to the current moment;

[0054] a calculation unit, configured to calculate a difference between the first timestamp and the second timestamp to obtain a time difference, determine whether the time difference is less than or equal to a preset time difference threshold, and obtain a first determination result; and search a local globally unique random string verification library for a historical globally unique random string that is identical to the current globally unique random string to obtain a second determination result, wherein the globally unique random string verification library is constructed based on all historical globally unique random strings;

[0055] A judging unit is configured to judge whether the second authorization code is the same as the first authorization code based on the first judgment result and the second judgment result.

[0056] In addition, to achieve the above-mentioned purpose, the present application also proposes a service processing device, which is applied to a client, and the service processing device includes:

[0057] An acquisition module, which is used to obtain API interface parameters and local request authorization logic;

[0058] A generation module, configured to process the API interface parameters based on the request authorization logic to obtain a first authorization code and determine a first timestamp corresponding to the processing of the API interface parameters;

[0059] A sending module is used to generate a business processing request based on the first authorization code, the first timestamp and the local current globally unique random string, and send the business processing request to the server side for the server side to verify whether the business processing is allowed.

[0060] In one embodiment, the generating module further includes:

[0061] A sixth determining unit, configured to determine a business processing type corresponding to the API interface parameter;

[0062] The second data processing unit is used to process the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain a first authorization code.

[0063] In one embodiment, if the business processing type is a POST request type or a PUT request type, the generating module further includes:

[0064] A seventh determining unit is configured to determine whether there are multiple layers of JSON nesting in the API interface parameters if the business processing type is a POST request type or a PUT request type;

[0065] An eighth determining unit, configured to determine, if any, non-JSON nested fields, JSON nested fields, and a first field value corresponding to each field in each layer of JSON nesting;

[0066] The third sorting unit is used to sort the non-JSON nested fields and JSON nested fields in the API interface parameters based on the first sorting logic corresponding to the preset non-JSON nested fields, the second sorting logic corresponding to the preset nested layer, and the first field value to obtain a second authorization code.

[0067] In one embodiment, if the service processing type is a GET request type or a DELETE request type, the generating module further includes:

[0068] a ninth determining unit, configured to, if the business processing type is a GET request type or a DELETE request type, determine a target field having a key value in the API interface parameter, and determine a second field value corresponding to the target field;

[0069] The fourth sorting unit is configured to sort the target field based on a preset third sorting method corresponding to the target field and the second field value to obtain a first authorization code.

[0070] To achieve the above objectives, the present application also proposes a business processing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the business processing method described above.

[0071] The present application also proposes a storage medium, which is a computer-readable storage medium. A computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the business processing method described above are implemented.

[0072] In addition, the present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of the business processing method described above are implemented.

[0073] One or more technical solutions proposed in this application have at least the following technical effects:

[0074] The present application proposes a business processing method and related equipment, which relate to the field of business data processing technology. Compared with the related technologies, in the current Internet of Things or smart home scenarios, when clients such as robots need to obtain business-related data from the server, they need to log in and register first. However, this will increase the interaction time, resulting in slow business processing response and poor timeliness. In the present application, first, when the client is not logged in, in response to the client's business processing request, a first authorization code is extracted from the business processing request. The first authorization code is obtained by the client after processing the API interface parameters corresponding to the business processing request based on the client's request authorization logic. Then, based on the local permission authorization logic, the API interface parameters are processed to obtain a second authorization code. Finally, it is determined whether the second authorization code is the same as the first authorization code. If they are the same, it is determined that the client has passed the verification and the business data corresponding to the business processing request is returned.

[0075] It should be noted that for clients that are allowed to pass verification, the business processing device will pre-set the same authorization logic as the server side (that is, the authorization logic is allowed to be the same as the request authorization logic). For the same authorization logic (splicing logic) and the same parameters to be spliced ​​(API interface parameters), the splicing results obtained by the business processing device should be the same (that is, the first authorization code and the second authorization code should be the same).

[0076] It can be understood that in this application, when the client is not logged in, the first authorization code in the business processing request is directly verified based on the local authorization logic on the server side. While achieving security verification, it avoids the cumbersome login and registration process in the business processing process, thereby improving the business processing response speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0078] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0079] Figure 1 A flowchart of the first embodiment of the business processing method of this application is provided;

[0080] Figure 2 A flowchart of the second embodiment of the business processing method of this application is provided;

[0081] Figure 3 A code diagram provided for Example 2 of the business processing method of this application;

[0082] Figure 4 A schematic diagram of a simplified process flow of the business processing method provided in Example 2 of this application;

[0083] Figure 5 This is a schematic diagram of the module structure of the service processing device according to an embodiment of the present application;

[0084] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the business processing method in the embodiment of the present application.

[0085] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0086] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0087] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0088] The main solutions of the embodiments of this application are:

[0089] In this embodiment, for ease of description, the following description is made with the service processing device as the execution entity.

[0090] Due to related technologies: In the current Internet of Things or smart home scenarios, when clients such as robots need to obtain business-related data from the server, they need to log in and register first. However, this increases the interaction time, resulting in slow business processing response and poor timeliness.

[0091] The present application provides a solution. First, when the client is not logged in, in response to the client's business processing request, a first authorization code is extracted from the business processing request. The first authorization code is obtained by the client after processing the API interface parameters corresponding to the business processing request based on the client's request authorization logic. Then, based on the local permission authorization logic, the API interface parameters are processed to obtain a second authorization code. Finally, it is determined whether the second authorization code is the same as the first authorization code. If they are the same, it is determined that the client has passed the verification and the business data corresponding to the business processing request is returned.

[0092] It should be noted that, for a client that is allowed to pass the verification, the service processing device will pre-set the same authorization logic as that of the server (ie, the authorization logic is the same as the authorization request logic).

[0093] It can be understood that in this application, when the client is not logged in, the first authorization code in the business processing request is directly verified based on the local authorization logic on the server side. While achieving security verification, it avoids the cumbersome login and registration process in the business processing process, thereby improving the business processing response speed.

[0094] It should be noted that the execution subject of this embodiment can be a computing service device with business request processing, network communication, and program execution capabilities, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or business processing device capable of implementing the above functions. The following uses a business processing device as an example to illustrate this embodiment and the following embodiments.

[0095] Based on this, the embodiment of the present application provides a business processing method, which is applied to the server side, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the business processing method of this application.

[0096] In this embodiment, the service processing method includes steps S10 to S30:

[0097] Step S10: In response to a business processing request from the client, extracting a first authorization code from the business processing request when the client is not logged in. The first authorization code is obtained by the client processing the API interface parameters corresponding to the business processing request based on the client's request authorization logic.

[0098] It should be noted that the execution subject of this embodiment can be a computing service device with business request processing, network communication, and program execution capabilities, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or business processing device capable of implementing the above functions. The following uses a business processing device as an example to illustrate this embodiment and the following embodiments.

[0099] It should be noted that in this application, a specific application scenario may be: in the context of the Internet of Things or smart home, a client wishes to access a server API without logging in to process related services. Furthermore, the client sends a service processing request to the server. Furthermore, the server receives the service processing request sent by the client and authenticates the first authorization code in the service processing request to determine whether the client has passed the verification.

[0100] It's important to note that a client is a program or application in a computer network that corresponds to a server and provides local services to clients. Specifically, a client refers to "the party that initiates requests and receives service responses in network communications," typically a software or hardware entity running on a terminal device. According to Baidu Encyclopedia, a client, also known as a user terminal, is "a program that provides local services to clients" and requires collaboration with a server.

[0101] The server is a core service provider in modern computer network architectures. As the "brain" of information systems, it processes client requests, executes business logic, and manages data resources. Specifically, a server is a computer system that provides services to other computers (clients) in a network environment. It can be a physical server, a virtual server, or a cloud server.

[0102] API (Application Programming Interface) is one of the core technologies of modern software development and system integration. It defines the rules and methods for interaction and communication between different software components. API is "a set of rules for communication between different parts of a software system." It defines the request format, transmission method, data structure and operation rules, enabling different software applications to interact with each other and exchange data. Simply put, API is a set of preset functions or methods that allows third-party programs to call data or provide data-based services over the network. API interface parameters are the input data passed when calling the API interface.

[0103] Authorization logic refers to the set of rules and processes a system uses to determine whether an entity (user or application) has permission to access specific resources or perform specific actions. This logic is used for both permission evaluation (evaluating whether a request should be allowed based on predefined rules) and access control (making decisions about granting or denying access).

[0104] An authorization code is a temporary credential in the OAuth 2.0 authorization framework, used to securely exchange an access token during the authorization process.

[0105] It should also be noted that, considering the security of information transmission, when the client sends a business processing request to the server, the data corresponding to the business processing request is usually encrypted before transmission. That is, after the server receives the business processing request, it will perform a decryption operation on the business processing request.

[0106] For example, the AES symmetric encryption algorithm in CBC mode can be used to encrypt / decrypt the data corresponding to the service request. The specific steps may be: based on the pre-set encryption and decryption key and initial offset IV, the AES symmetric encryption algorithm in CBC / NoPadding encryption mode is used to decrypt the service request. Since the NoPadding encrypted plaintext must be a multiple of 16, it is necessary to calculate the length of the encrypted plaintext and, if the plaintext number is less than a multiple of 16, pad it with 0 to a multiple of 16.

[0107] For example, define the secret key key = EJKD93LJK8923ACD, offset IV = 23KCSLED43DFJKDE, when the string before encryption is code200languagezh`1744258813`3aebd5615175471aa2a6e4a8973c5880, the number of bits of the string is 61, and the nearest integer that is a multiple of 16 is 64 bits, then when encrypting, it is necessary to add 0 to fill 3 bits at the end, and the result after adding 0 is code 200languagezh`1744258813`3aebd5615175471aa2a6e4a8973c5880000, further, after encryption, the final authCode=pN8trJTk7DD3VoTk6GVfNpKAmOpQ2FoGiFTfWIsHIrj8vmF77o9ZXdqKobDcfpvWE2eraHDZoTqc0iv7b1Nerw== is obtained.

[0108] It is understandable that for clients allowed to perform business processing, the encryption method corresponding to the server will be set in advance. If the business processing device cannot decrypt the business processing request received by the server, it can be directly determined that the client corresponding to the business processing request cannot execute the business processing steps.

[0109] Step S20: Process the API interface parameters based on the local authorization logic to obtain a second authorization code;

[0110] It's important to note that Allow Authorization Logic (ALL) is a core component of an access control system. It defines the decision-making rules for allowing or denying user / system (client) access to resources under specific conditions. In other words, Allow Authorization Logic is a verification mechanism. Unlike the traditional "deny first" security model, Allow Authorization Logic adopts a "whitelist" approach, explicitly specifying which operations are permitted and disallowing others by default.

[0111] Local-based authorization logic means that the authorization decision is made through a locally running program or script. In this application, the authorization logic can be a customized parameter splicing logic.

[0112] It should be noted that the second authorization code is obtained by splicing the API interface parameters based on the customized parameter splicing logic corresponding to the authorization logic.

[0113] It should also be noted that in this application, the permission authorization logic and the request authorization logic are custom parameter splicing logic. The business processing device performs parameter splicing on the same parameter (API interface parameter) based on the permission authorization logic and the request authorization logic to obtain two parameter splicing results (the first authorization code and the second authorization code). Then, the business processing device performs verification based on these two parameter splicing results.

[0114] Step S30: determine whether the second authorization code is the same as the first authorization code. If they are the same, determine that the client has passed the verification and return the business data corresponding to the business processing request.

[0115] It should be noted that the method for determining whether the second authorization code is the same as the first authorization code can be: determining whether the character string corresponding to the second authorization code is exactly the same as the character string corresponding to the first authorization code; if the character strings are exactly the same, the second authorization code is the same as the first authorization code; if the character strings are not exactly the same, the second authorization code is different from the first authorization code.

[0116] Specifically, the service processing request also includes a first timestamp and a current globally unique random string. The step of determining whether the second authorization code is the same as the first authorization code further includes steps S31 to S33:

[0117] Step S31, extracting a first timestamp and a current globally unique random string from the business processing request, and determining a second timestamp corresponding to the current moment;

[0118] It should be noted that the first timestamp refers to the time corresponding to when the client generates the service processing request.

[0119] The current globally unique random string is a unique string generated by the device according to specific rules and is used to determine whether the same request is executed repeatedly.

[0120] The second timestamp refers to the time corresponding to when the server receives the service processing request.

[0121] Step S32: Calculate the difference between the first timestamp and the second timestamp to obtain a time difference, determine whether the time difference is less than or equal to a preset time difference threshold, and obtain a first determination result; search a local globally unique random string verification library for a historical globally unique random string that is identical to the current globally unique random string, and obtain a second determination result. The globally unique random string verification library is constructed based on all historical globally unique random strings.

[0122] It should be noted that the preset time difference threshold is set in advance and is used to verify the access time.

[0123] It should be noted that the judgment process corresponding to the first judgment result is: judging whether the time difference is less than or equal to the preset time difference threshold. If the time difference is less than or equal to the preset time difference threshold, it is confirmed that the server side responds to the client's business processing request in a timely manner. Conversely, if the time difference is greater than the preset time difference threshold, it is confirmed that the server side does not respond to the client's business processing request in a timely manner.

[0124] It should be noted that the globally unique random string verification library is constructed from multiple current globally unique random strings. Furthermore, the judgment process corresponding to the second judgment result is to check whether the local globally unique random string verification library contains a historical globally unique random string identical to the current globally unique random string. If so, the service processing request is confirmed to have appeared before and processed accordingly. Conversely, if not, the service processing request is confirmed to have not appeared before, thereby preventing the duplicate processing of the same service processing request.

[0125] It can be understood that in this embodiment, response timeouts are avoided by verifying the timestamp, and repeated processing of consent requests is avoided by verifying the globally unique random string, thereby improving the efficiency of business processing and the user experience.

[0126] Step S33: Based on the first judgment result and the second judgment result, determine whether the second authorization code is the same as the first authorization code.

[0127] It should be noted that if the time difference is less than or equal to the preset time difference threshold, and there is no historical globally unique random string identical to the current globally unique random string in the local globally unique random string verification library, then it is determined whether the string of the second authorization code is exactly the same as the string of the first authorization code. If they are the same, the second authorization code is the same as the first authorization code. If the time difference is greater than the preset time difference threshold, or if there is a historical globally unique random string identical to the current globally unique random string in the local globally unique random string verification library, at least one of the two conditions is met, then the second authorization code is different from the first authorization code (even if the string of the second authorization code is exactly the same as the string of the first authorization code, the corresponding judgment result is different).

[0128] It can be understood that in this embodiment, if the first judgment result and the second judgment result are the same, it indicates that the business processing device responds to the client's business processing request in a timely manner on the server side, and only performs one operation on the business processing request to avoid repeated operations.

[0129] The present application proposes a business processing method and related equipment, which relate to the field of business data processing technology. Compared with the related technologies, in the current Internet of Things or smart home scenarios, when clients such as robots need to obtain business-related data from the server, they need to log in and register first. However, this will increase the interaction time, resulting in slow business processing response and poor timeliness. In the present application, first, when the client is not logged in, in response to the client's business processing request, a first authorization code is extracted from the business processing request. The first authorization code is obtained by the client after processing the API interface parameters corresponding to the business processing request based on the client's request authorization logic. Then, based on the local permission authorization logic, the API interface parameters are processed to obtain a second authorization code. Finally, it is determined whether the second authorization code is the same as the first authorization code. If they are the same, it is determined that the client has passed the verification and the business data corresponding to the business processing request is returned.

[0130] It should be noted that for clients that are allowed to pass verification, the business processing device will pre-set the same authorization logic as the server side (that is, the authorization logic is allowed to be the same as the request authorization logic). For the same authorization logic (splicing logic) and the same parameters to be spliced ​​(API interface parameters), the splicing results obtained by the business processing device should be the same (that is, the first authorization code and the second authorization code should be the same).

[0131] It can be understood that in this application, when the client is not logged in, the first authorization code in the business processing request is directly verified based on the local authorization logic on the server side. While achieving security verification, it avoids the cumbersome login and registration process in the business processing process, thereby improving the business processing response speed.

[0132] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 2 The step of processing the API interface parameters based on the local authorization logic to obtain the second authorization code further includes steps S21 to S22:

[0133] Step S21, determining the request type corresponding to the business processing request;

[0134] It should be noted that the business processing process mainly involves the HTTP protocol, that is, the business processing request is actually an HTTP request. The request types corresponding to the business processing request include POST (add) request, GET (query) request, DELETE (delete) request, and PUT (modify) request. Business processing requests are not limited to other types of requests. Different request types correspond to different data volume categories.

[0135] It should be noted that an HTTP request consists of three parts: a request line, request headers, and a request body. The request header is used to store metadata (such as authentication information, cache control, client information, etc.) and is suitable for small data volumes, high frequencies, and critical control information. The request body is used to store actual data (such as forms, JSON, files, etc.) and is suitable for large data volumes, complex structures, and sensitive data.

[0136] It can be understood that in this application, the corresponding data volume is not the same for different request types. Combined with the size of the data stored in each part of the HTTP request, the data corresponding to the POST (add) request and the data corresponding to the PUT (modify) request are stored in the request body, and the data corresponding to the GET (query) request and the data corresponding to the DELETE (delete) request are stored in the request header.

[0137] Step S22: Based on the authorization logic corresponding to the request type, the API interface parameters are processed to obtain a second authorization code.

[0138] It is understandable that, since different request types correspond to different storage locations and different storage locations correspond to different data storage capacities, different authorization logics are used to process API interface parameters for different request types.

[0139] Specifically, if the request type is a POST request type or a PUT request type, the step of processing the API interface parameters based on the authorization logic corresponding to the request type to obtain the second authorization code further includes steps A1 to A3:

[0140] Step A1: If the request type is a POST request type or a PUT request type, determine whether there are multiple layers of JSON nesting in the API interface parameters;

[0141] It's important to note that JSON (JavaScript Object Notation), as a lightweight data exchange format, plays a crucial role in modern software development. JSON nesting refers to the structure in which a JSON object or array contains other JSON objects or arrays. This feature enables JSON to represent complex data relationships and hierarchical structures. Specifically, JSON nesting involves a JSON value (object or array) containing another JSON value, forming a hierarchical data representation.

[0142] Step A2: If it exists, determine the non-JSON nested fields, JSON nested fields, and the first field value corresponding to each field in each layer of JSON nesting;

[0143] It's important to note that in data processing and system interactions, "non-JSON nested fields" refer to simple fields that remain flat within the JSON structure and don't contain nested objects or arrays. These fields, in stark contrast to nested structures, offer unique advantages and application value in specific scenarios. These fields reside at the top level of the JSON structure, forming no hierarchical relationship and typically exist as simple key-value pairs.

[0144] It should be noted that the first field value refers to the "key value" corresponding to each field.

[0145] Step A3, based on the first sorting logic corresponding to the preset non-json nested field, the second sorting logic corresponding to the preset nested layer and the first field value, sort the non-json nested fields and json nested fields in the API interface parameters to obtain a second authorization code.

[0146] It should be noted that the first sorting logic may be to sort the non-json nested fields in ascending order of "key value", and the second sorting logic may be to sort the nested layers in order from shallow to deep nesting.

[0147] For example, Figure 3 Take the code in as an example:

[0148] The first layer is data (row 2), and order, pageNum, pageSize, sortColumn ( Figure 3 ), data is a JSON nested field, and order, pageNum, pageSize, and sortColumn are non-JSON nested fields.

[0149] The specific sorting process is:

[0150] First, step 1, the non-json nested fields in the first layer of json are order, pageNum, pageSize, sortColumn ( Figure 3 ), sorted in ascending order by key value, and non-JSON nested fields with "value" are sorted after non-JSON nested fields with only "key". The corresponding splicing result of the first layer is: orderpageNum1pageSize10sortColumn.

[0151] Among them, "order" includes a key value, followed by a content value of "", indicating that it is empty, that is, "order" has no "value"; "pageNum" includes a key value, followed by a content value of 1; "pageSize" includes a key value, followed by a content value of 10; "sortColumn" contains a key value, followed by a content value of "", indicating that it is empty.

[0152] Further, in step 2, the first layer data field ( Figure 3 The second row identified in the figure is a JSON nested field. Code and language are non-JSON nested fields and are arranged after the concatenation result corresponding to step 1. The concatenation result is: orderpageNum1pageSize10sortColumncode200languagezh (Note: multiple JSON attribute fields at the same level are sorted in ascending order of the key).

[0153] Furthermore, in step 3, the second-layer JSON field is a JSON nested field, and abc is a non-JSON nested field, which is arranged after the corresponding splicing result in step 2. The splicing result is: orderpageNum1pageSize10sortColumncode200languagezha123b456c789.

[0154] Specifically, if the request type is a GET request type or a DELETE request type, the step of processing the API interface parameters based on the authorization logic corresponding to the request type to obtain the second authorization code further includes steps B1 to B2:

[0155] Step B1: If the request type is a GET request type or a DELETE request type, determine a target field having a key value in the API interface parameter, and determine a second field value corresponding to the target field;

[0156] It should be noted that the key value refers to the "value value" in the above content. That is, based on the above example, the target fields are: "code":200 and "language":"zh", and the second field values ​​corresponding to the target fields are "code" and "language" respectively.

[0157] Step B2: sorting the target field based on the preset third sorting method corresponding to the target field and the second field value to obtain a second authorization code.

[0158] It should be noted that the third sorting method may be: sorting the target fields in ascending order of key values.

[0159] Furthermore, if the request type is a GET request type or a DELETE request type, the corresponding splicing result is: code200languagezh.

[0160] It can be understood that in this embodiment, the API interface parameters are spliced ​​and processed through the authorization logic corresponding to different request types to obtain the spliced ​​second authorization code, which provides a data basis for subsequent judgment steps.

[0161] Based on the first and second embodiments of the present application, in the third embodiment of the present application, the same or similar contents as those in the first and second embodiments can be referred to above and will not be described in detail. Figure 4 , Figure 4 This is a flowchart of the third embodiment of the business processing method of this application.

[0162] In this embodiment, the service processing method includes steps C10 to C30:

[0163] Step C10: Obtain API interface parameters and local request authorization logic;

[0164] It should be noted that, in this embodiment, specific application scenarios may be:

[0165] Before performing this business processing, the client and server have set the corresponding request authorization logic and allow authorization logic respectively; or the client has obtained authorization from the server (the client has logged in to the server), and set the corresponding request authorization logic and allow authorization logic respectively during authorization, which are used for authentication of subsequent business processing requests.

[0166] It is understandable that, because before this business processing, both the client and the server have set the request authorization logic and the allow authorization logic respectively, therefore, during this business processing, the local authorization logic will be called separately to splice the API interface parameters to verify whether the request authorization logic and the allow authorization logic are the same, and then determine whether the client has the authority to process the business.

[0167] Step C20: Based on the request authorization logic, the API interface parameters are processed to obtain a first authorization code, and a first timestamp corresponding to the processing of the API interface parameters is determined;

[0168] Specifically, the step of processing the API interface parameters based on the request authorization logic to obtain the first authorization code further includes steps C21 to C22:

[0169] Step C21, determining the business processing type corresponding to the API interface parameter;

[0170] It should be noted that the API interface parameters include the address corresponding to the API interface and the instructions from the client to the server. Furthermore, the business processing device can determine the business processing type through the instructions.

[0171] Step C22: Based on the request authorization logic corresponding to the business processing type, the API interface parameters are processed to obtain a first authorization code.

[0172] Specifically, if the business processing type is a POST request type or a PUT request type, the step of processing the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain the first authorization code also includes steps D1 to D3:

[0173] Step D1: If the business processing type is a POST request type or a PUT request type, determine whether there are multiple layers of JSON nesting in the API interface parameters;

[0174] Step D2: If it exists, determine the non-JSON nested fields, JSON nested fields, and the first field value corresponding to each field in each layer of JSON nesting;

[0175] Step D3, based on the first sorting logic corresponding to the preset non-json nested field, the second sorting logic corresponding to the preset nested layer and the first field value, sort the non-json nested fields and json nested fields in the API interface parameters to obtain a second authorization code.

[0176] For example, Figure 3 Take the code in as an example:

[0177] The first layer is data (row 2), and order, pageNum, pageSize, sortColumn ( Figure 3 ), data is a JSON nested field, and order, pageNum, pageSize, and sortColumn are non-JSON nested fields.

[0178] The specific sorting process is:

[0179] First, step 1, the non-json nested fields in the first layer of json are order, pageNum, pageSize, sortColumn ( Figure 3 ), sorted in ascending order by key value, and non-JSON nested fields with "value" are sorted after non-JSON nested fields with only "key". The corresponding splicing result of the first layer is: orderpageNum1pageSize10sortColumn.

[0180] Among them, "order" includes a key value, followed by a content value of "", indicating that it is empty, that is, "order" has no "value"; "pageNum" includes a key value, followed by a content value of 1; "pageSize" includes a key value, followed by a content value of 10; "sortColumn" contains a key value, followed by a content value of "", indicating that it is empty.

[0181] Further, in step 2, the first layer data field ( Figure 3 The second row identified in the figure is a JSON nested field. Code and language are non-JSON nested fields and are arranged after the concatenation result corresponding to step 1. The concatenation result is: orderpageNum1pageSize10sortColumncode200languagezh (Note: multiple JSON attribute fields at the same level are sorted in ascending order of the key).

[0182] Furthermore, in step 3, the second-layer JSON field is a JSON nested field, and abc is a non-JSON nested field, which is arranged after the corresponding splicing result in step 2. The splicing result is: orderpageNum1pageSize10sortColumncode200languagezha123b456c789.

[0183] Specifically, if the business processing type is a GET request type or a DELETE request type, the step of processing the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain the first authorization code further includes steps E1 to E2:

[0184] Step E1: If the business processing type is a GET request type or a DELETE request type, determine a target field having a key value in the API interface parameter, and determine a second field value corresponding to the target field;

[0185] Combine Figure 3, the target fields are: "code":200 and "language":"zh", and the second field values ​​corresponding to the target fields are "code" and "language" respectively.

[0186] Step E2: sorting the target field based on the preset third sorting method corresponding to the target field and the second field value to obtain a first authorization code.

[0187] It should be noted that the third sorting method may be: sorting the target fields in ascending order of key values.

[0188] Furthermore, if the request type is a GET request type or a DELETE request type, the corresponding splicing result is: code200languagezh.

[0189] Step C30: Generate a service processing request based on the first authorization code, the first timestamp and the local current globally unique random string, and send the service processing request to the server for the server to verify whether the service processing is allowed.

[0190] It should be noted that the business processing request contains a string (first authorization code) that is spliced ​​together with the API interface parameters according to the request authorization logic, a first timestamp, and a current globally unique random string. The three parts are connected by preset special symbols to form a complete string (for example, the string is code200languagezhˋ1744258813ˋ3aebd5615175471aa2a6e4a8973c5880, where "code200languagezh" is the "string that is spliced ​​together with the API interface parameters according to the request authorization logic", "1744258813" is the "first timestamp", "3aebd5615175471aa2a6e4a8973c5880" is the "current globally unique random string", and the special symbol is "ˋ").

[0191] It can be understood that for clients that are allowed access, their request authorization logic and permission authorization logic should be the same and are set in advance. Assuming that the client is a client that is allowed access, the parameter splicing logic of the client and its corresponding server is the same, and thus, the splicing steps corresponding to the client and its corresponding server are also the same.

[0192] It can be understood that in this embodiment, the API interface parameters are spliced ​​and processed through the request authorization logic corresponding to different request types to obtain the spliced ​​first authorization code, which provides a data basis for subsequent judgment steps.

[0193] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the business processing method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0194] This application also provides a business processing device, please refer to Figure 5 , the service processing device includes:

[0195] A response module 10 is configured to, when the client is not logged in, respond to a business processing request from the client and extract a first authorization code from the business processing request, where the first authorization code is obtained by the client processing the API interface parameters corresponding to the business processing request based on the client's request authorization logic;

[0196] A data processing module 20 is configured to process the API interface parameters based on local authorization logic to obtain a second authorization code;

[0197] The judgment module 30 is used to judge whether the second authorization code is the same as the first authorization code. If they are the same, it is determined that the client has passed the verification and the business data corresponding to the business processing request is returned.

[0198] In one embodiment, the data processing module further includes:

[0199] A first determining unit, configured to determine a request type corresponding to the business processing request;

[0200] The first data processing unit is used to process the API interface parameters based on the authorization logic corresponding to the request type to obtain a second authorization code.

[0201] In one embodiment, if the request type is a POST request type or a PUT request type, the data processing module further includes:

[0202] The second determining unit is configured to determine whether there are multiple layers of JSON nesting in the API interface parameters if the request type is a POST request type or a PUT request type;

[0203] A third determining unit is configured to determine, if any, non-JSON nested fields, JSON nested fields, and a first field value corresponding to each field in each layer of JSON nesting;

[0204] The first sorting unit is used to sort the non-JSON nested fields and JSON nested fields in the API interface parameters based on the first sorting logic corresponding to the preset non-JSON nested fields, the second sorting logic corresponding to the preset nested layer, and the first field value to obtain a second authorization code.

[0205] In one embodiment, if the request type is a GET request type or a DELETE request type, the data processing module further includes:

[0206] a fourth determining unit, configured to, if the request type is a GET request type or a DELETE request type, determine a target field having a key value in the API interface parameter, and determine a second field value corresponding to the target field;

[0207] The second sorting unit is configured to sort the target field based on a preset third sorting method corresponding to the target field and the second field value to obtain a second authorization code.

[0208] In one embodiment, the service processing request further includes a first timestamp and a current globally unique random string, and the judgment module further includes:

[0209] a fifth determining unit, configured to extract the first timestamp and the current globally unique random string from the service processing request, and determine a second timestamp corresponding to the current moment;

[0210] a calculation unit, configured to calculate a difference between the first timestamp and the second timestamp to obtain a time difference, determine whether the time difference is less than or equal to a preset time difference threshold, and obtain a first determination result; and search a local globally unique random string verification library for a historical globally unique random string that is identical to the current globally unique random string to obtain a second determination result, wherein the globally unique random string verification library is constructed based on all historical globally unique random strings;

[0211] A judging unit is configured to judge whether the second authorization code is the same as the first authorization code based on the first judgment result and the second judgment result.

[0212] In addition, to achieve the above-mentioned purpose, the present application also proposes a service processing device, which is applied to a client, and the service processing device includes:

[0213] An acquisition module, which is used to obtain API interface parameters and local request authorization logic;

[0214] A generation module, configured to process the API interface parameters based on the request authorization logic to obtain a first authorization code and determine a first timestamp corresponding to the processing of the API interface parameters;

[0215] A sending module is used to generate a business processing request based on the first authorization code, the first timestamp and the local current globally unique random string, and send the business processing request to the server side for the server side to verify whether the business processing is allowed.

[0216] In one embodiment, the generating module further includes:

[0217] A sixth determining unit, configured to determine a business processing type corresponding to the API interface parameter;

[0218] The second data processing unit is used to process the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain a first authorization code.

[0219] In one embodiment, if the business processing type is a POST request type or a PUT request type, the generating module further includes:

[0220] A seventh determining unit, configured to determine whether there are multiple layers of JSON nesting in the API interface parameters if the business processing type is a POST request type or a PUT request type;

[0221] An eighth determining unit, configured to determine, if any, non-JSON nested fields, JSON nested fields, and a first field value corresponding to each field in each layer of JSON nesting;

[0222] The third sorting unit is used to sort the non-JSON nested fields and JSON nested fields in the API interface parameters based on the first sorting logic corresponding to the preset non-JSON nested fields, the second sorting logic corresponding to the preset nested layer, and the first field value to obtain a second authorization code.

[0223] In one embodiment, if the service processing type is a GET request type or a DELETE request type, the generating module further includes:

[0224] a ninth determining unit, configured to, if the business processing type is a GET request type or a DELETE request type, determine a target field having a key value in the API interface parameter, and determine a second field value corresponding to the target field;

[0225] The fourth sorting unit is configured to sort the target field based on a preset third sorting method corresponding to the target field and the second field value to obtain a first authorization code.

[0226] The service processing device provided in this application utilizes the service processing method described in the aforementioned embodiments to resolve technical issues related to service processing. Compared to related technologies, the service processing device provided in this application achieves the same beneficial effects as the service processing method described in the aforementioned embodiments. Other technical features of the service processing device are the same as those disclosed in the aforementioned embodiments and are not further detailed here.

[0227] The present application provides a business processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the business processing methods in the above-mentioned embodiments one, two, and three.

[0228] Reference below Figure 6 , which shows a schematic diagram of the structure of a service processing device suitable for implementing the embodiments of the present application. The service processing device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The business processing device shown is only an example and should not limit the functions and scope of use of the embodiments of the present application.

[0229] like Figure 6As shown, the business processing device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the business processing device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the business processing device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a business processing device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have alternatively.

[0230] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0231] The service processing device provided in this application employs the service processing method described in the above-mentioned embodiments to solve the technical problems. Compared to related technologies, the beneficial effects of the service processing device provided in this application are the same as those of the service processing method described in the above-mentioned embodiments. Other technical features of the service processing device are the same as those disclosed in the above-mentioned embodiments and are not further elaborated here.

[0232] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0233] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0234] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer program) stored thereon, wherein the computer-readable program instructions are used to execute the business processing method in the above-mentioned embodiment.

[0235] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0236] The computer-readable storage medium may be included in the business processing device, or may exist independently without being incorporated into the business processing device.

[0237] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by a service processing device, the service processing device:

[0238] When the client is not logged in, in response to a business processing request from the client, extracting a first authorization code from the business processing request, where the first authorization code is obtained by the client processing API interface parameters corresponding to the business processing request based on the client's request authorization logic;

[0239] Based on the local authorization logic, the API interface parameters are processed to obtain a second authorization code;

[0240] Determine whether the second authorization code is the same as the first authorization code. If they are the same, determine that the client has passed the verification and return the business data corresponding to the business processing request.

[0241] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0242] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0243] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0244] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned business processing method, thereby resolving the technical issues surrounding business processing requests. Compared to related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the business processing method provided in the aforementioned embodiments, and are not further elaborated here.

[0245] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned business processing method when executed by a processor.

[0246] The computer program product provided in this application can solve the technical problem of business processing requests. Compared with the relevant technology, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the business processing method provided in the above embodiment, which will not be repeated here.

[0247] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A business processing method, characterized in that: Applied to the server side, the business processing method includes: When the client is not logged in, in response to a business processing request from the client, extracting a first authorization code from the business processing request, where the first authorization code is obtained by the client processing API interface parameters corresponding to the business processing request based on the client's request authorization logic; Based on the local authorization logic, the API interface parameters are processed to obtain a second authorization code; Determine whether the second authorization code is the same as the first authorization code. If they are the same, determine that the client has passed the verification and return the business data corresponding to the business processing request.

2. The service processing method according to claim 1, wherein: The step of processing the API interface parameters based on the local authorization logic to obtain the second authorization code further includes: Determining a request type corresponding to the business processing request; Based on the authorization logic corresponding to the request type, the API interface parameters are processed to obtain a second authorization code.

3. The service processing method according to claim 2, wherein: If the request type is a POST request type or a PUT request type, the step of processing the API interface parameters based on the authorization logic corresponding to the request type to obtain a second authorization code further includes: If the request type is a POST request type or a PUT request type, determine whether there are multiple layers of JSON nesting in the API interface parameters; If it exists, determine the non-JSON nested fields, JSON nested fields, and the first field value corresponding to each field in each layer of JSON nesting; Based on the first sorting logic corresponding to the preset non-json nested field, the second sorting logic corresponding to the preset nested layer and the first field value, the non-json nested fields and json nested fields in the API interface parameters are sorted to obtain a second authorization code.

4. The service processing method according to claim 2, wherein: If the request type is a GET request type or a DELETE request type, the step of processing the API interface parameters based on the authorization logic corresponding to the request type to obtain a second authorization code further includes: If the request type is a GET request type or a DELETE request type, determining a target field having a key value in the API interface parameter, and determining a second field value corresponding to the target field; Based on the preset third sorting method corresponding to the target field and the second field value, the target field is sorted to obtain a second authorization code.

5. The service processing method according to any one of claims 1 to 4, characterized in that: The service processing request also includes a first timestamp and a current globally unique random string, and the step of determining whether the second authorization code is the same as the first authorization code further includes: Extracting a first timestamp and a current globally unique random string from the business processing request, and determining a second timestamp corresponding to the current moment; Calculating the difference between the first timestamp and the second timestamp to obtain a time difference, and determining whether the time difference is less than or equal to a preset time difference threshold to obtain a first determination result; searching a local globally unique random string verification library for a historical globally unique random string that is identical to the current globally unique random string to obtain a second determination result, wherein the globally unique random string verification library is constructed based on all historical globally unique random strings; Based on the first judgment result and the second judgment result, it is determined whether the second authorization code is the same as the first authorization code.

6. A business processing method, characterized in that: Applied to the client, the business processing method includes: Get API interface parameters and local request authorization logic; Based on the request authorization logic, the API interface parameters are processed to obtain a first authorization code, and a first timestamp corresponding to the processing of the API interface parameters is determined; A business processing request is generated based on the first authorization code, the first timestamp and the local current globally unique random character string, and the business processing request is sent to the server side for the server side to verify whether the business processing is allowed.

7. The service processing method according to claim 6, wherein: The step of processing the API interface parameters based on the request authorization logic to obtain a first authorization code further includes: Determine the business processing type corresponding to the API interface parameters; Based on the request authorization logic corresponding to the business processing type, the API interface parameters are processed to obtain a first authorization code.

8. The service processing method according to claim 7, wherein: If the business processing type is a POST request type or a PUT request type, the step of processing the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain the first authorization code further includes: If the business processing type is a POST request type or a PUT request type, determine whether there are multiple layers of JSON nesting in the API interface parameters; If it exists, determine the non-JSON nested fields, JSON nested fields, and the first field value corresponding to each field in each layer of JSON nesting; Based on the first sorting logic corresponding to the preset non-json nested field, the second sorting logic corresponding to the preset nested layer and the first field value, the non-json nested fields and json nested fields in the API interface parameters are sorted to obtain a second authorization code.

9. The service processing method according to claim 7, wherein: If the business processing type is a GET request type or a DELETE request type, the step of processing the API interface parameters based on the request authorization logic corresponding to the business processing type to obtain the first authorization code further includes: If the business processing type is a GET request type or a DELETE request type, determining a target field having a key value in the API interface parameter, and determining a second field value corresponding to the target field; Based on a preset third sorting method corresponding to the target field and the second field value, the target field is sorted to obtain a first authorization code.

10. A business processing device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the business processing method as claimed in any one of claims 1 to 5 or any one of claims 6 to 9.

Images