CN116627657A - Method, device, equipment and storage medium for preventing repeated submission of data request - Google Patents
Method, device, equipment and storage medium for preventing repeated submission of data request Download PDFInfo
- Publication number
- CN116627657A CN116627657A CN202310755117.XA CN202310755117A CN116627657A CN 116627657 A CN116627657 A CN 116627657A CN 202310755117 A CN202310755117 A CN 202310755117A CN 116627657 A CN116627657 A CN 116627657A
- Authority
- CN
- China
- Prior art keywords
- signature
- target
- request
- data request
- target data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 98
- 238000004364 calculation method Methods 0.000 claims abstract description 62
- 230000008569 process Effects 0.000 claims abstract description 22
- 238000004422 calculation algorithm Methods 0.000 claims description 22
- 238000012545 processing Methods 0.000 claims description 20
- 238000004590 computer program Methods 0.000 claims description 16
- 230000032683 aging Effects 0.000 claims description 5
- 238000001514 detection method Methods 0.000 claims description 3
- 241000508269 Psidium Species 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 230000018109 developmental process Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000013473 artificial intelligence Methods 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000011800 void material Substances 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5033—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering data affinity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a method, a device, equipment and a storage medium for preventing repeated submission of data requests, which relate to the technical field of computers and comprise the following steps: when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request; if yes, performing abstract calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature; executing the digest calculation process on the second signature to obtain a target signature; detecting whether the target signature is consistent with the cache signature stored in the preset cache container, and if so, prompting the target data request to be a repeated submitting request and throwing out an exception. By intercepting the target data request, judging whether the target data request is a POST or PUT request, and performing abstract calculation on the target data request judged to be positive, the method is simpler when the rear end judges whether the target data request is a repeated request.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a storage medium for preventing repeated submission of a data request.
Background
In the front-end and back-end interaction process, repeated submission of data is easy to occur due to network blocking or user operation, so that the problem of data repetition is caused. To solve this problem, a way to submit forms to add tokens is often used. The token is issued to the front end when the form is generated, and the back end detects whether the token is used or not when the form is submitted, so that the anti-replay attack is realized. Specifically, in the existing scheme, a back-end generation token is generally adopted and stored in a Session, and the token is acquired during page initialization. The front end attaches the token when initiating the request to the back end, and the back end verifies the token after receiving the request. If the token exists in the Session, the request is judged to be a valid request, and the token is deleted after the processing is completed. If this token does not exist in the Session, then this request is either invalid or a repeat request. When judging whether the data is repeatedly submitted, the back end is required to generate a token in advance, and the front end is required to call an additional request to acquire the token. Each form is submitted with the additional addition of this token field, which is relatively labor intensive to develop.
In summary, how to realize the verification process of completing repeated submission of the data request only by the back end without any change of the front end, and reducing the workload of development is a technical problem to be solved in the field.
Disclosure of Invention
Accordingly, the present application aims to provide a method, apparatus, device, and storage medium for preventing repeated submission of data requests, which can realize verification process of repeated submission of data requests by means of back end without any change of front end, and reduce development workload. The specific scheme is as follows:
in a first aspect, the present application discloses a method for preventing repeated submission of a data request, applied to a backend, comprising:
when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request;
if yes, performing abstract calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature;
executing the digest calculation process on the second signature to obtain a target signature;
and detecting whether the target signature is consistent with the cache signature stored in the preset cache container, if so, prompting the target data request to repeatedly submit the request and throwing out an exception.
Optionally, in the process of performing digest calculation on the user information in the target data request and the first signature including the target parameter of the AOP facet class to obtain the second signature, the method further includes:
traversing request parameters of the target data request to screen out target request parameters except the general parameters;
sorting and combining the parameter values of the target request parameters to generate corresponding target character strings, and performing Url coding on the target character strings to generate target codes;
performing hash operation on the target code according to a preset message digest algorithm to generate a target message digest;
and performing Base64 coding operation on the target message digest to acquire a corresponding target message signature.
Optionally, before performing the digest calculation on the user information in the target data request and the first signature including the target parameter of the AOP facet class, the method further includes:
and splicing the target message signature with the package name, the class name and the method name of the AOP section class to obtain a first signature.
Optionally, the performing digest calculation on the user information in the target data request and the first signature including the target parameter of the AOP slice class to obtain a second signature includes:
acquiring a user name of a login user generating a target data request from a back-end Session, and if the user name is acquired, combining the user name with the first signature to be used as a second signature;
correspondingly, the performing the foregoing digest calculation procedure on the second signature to obtain a target signature includes:
and performing preset message digest algorithm calculation and Base64 coding operation on the user name and the first signature to acquire a target signature.
Optionally, after the user name of the login user generating the target data request is obtained from the back-end Session, the method further includes:
if the user name is obtained to be empty, the IP address of the target data request is obtained and is used as a target IP;
combining the target IP with the first signature to obtain a second signature;
correspondingly, the performing the foregoing digest calculation procedure on the second signature to obtain a target signature includes:
and performing preset message digest algorithm calculation and Base64 coding operation on the target IP and the first signature to acquire the target signature.
Optionally, after detecting whether the target signature is consistent with the cache signature stored in the preset cache container, the method further includes:
if the target data requests are inconsistent, the target data requests are the first data requests, corresponding business logic is executed, and after the business logic processing is executed, the corresponding target signatures are stored in a preset cache container.
Optionally, the method for preventing repeated submission of data request further includes:
creating a cache constructor for constructing a cache container, and setting cache aging time;
and constructing a preset cache container according to the cache constructor.
In a second aspect, the present application discloses a device for preventing repeated submission of data requests, applied to a backend, comprising:
the request detection module is used for intercepting a target data request and judging whether the target data request is a POST or PUT request when detecting that the front end sends the target data request;
the first abstract calculation module is used for carrying out abstract calculation on the user information in the target data request and a first signature containing the target parameters of the AOP section class if yes so as to acquire a second signature;
the second digest calculation module is used for executing the digest calculation process on the second signature so as to acquire a target signature;
and the request judging module is used for detecting whether the target signature is consistent with the cache signature stored in the preset cache container, and if so, prompting the target data request to repeatedly submit the request and throwing out an exception.
In a third aspect, the present application discloses an electronic device, comprising:
a memory for storing a computer program;
a processor for executing the computer program to implement the steps of the previously disclosed method for preventing repeated submission of data requests.
In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program when executed by a processor implements the steps of the previously disclosed method of preventing repeated submission of data requests.
The application discloses a method for preventing repeated submission of data requests, which is applied to a back end and comprises the following steps: when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request; if yes, performing abstract calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature; executing the digest calculation process on the second signature to obtain a target signature; and detecting whether the target signature is consistent with the cache signature stored in the preset cache container, if so, prompting the target data request to repeatedly submit the request and throwing out an exception. Therefore, the target data request is intercepted through an AOP interception technology, whether the target data request is a POST or PUT request is judged, if yes, abstract calculation is conducted on the target data request, whether the target data request is a repeated submitting request is judged according to a target signature obtained after the abstract calculation, and in addition, the mode of comparing the cache signatures stored in the preset cache container is adopted, so that the method is simpler when judging whether the target data request is a repeated request.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of a method for preventing repeated submission of data requests according to the present disclosure;
FIG. 2 is a flow chart of a method for preventing repeated submission of data requests in accordance with the present disclosure;
FIG. 3 is a flowchart of another embodiment of a method for preventing repeated submission of data requests disclosed herein;
FIG. 4 is a schematic diagram of a device for preventing repeated submission of data requests according to the present application;
fig. 5 is a block diagram of an electronic device according to the present disclosure.
Detailed Description
The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
In the front-end and back-end interaction process, repeated submission of data is easy to occur due to network blocking or user operation, so that the problem of data repetition is caused. To solve this problem, a way to submit forms to add tokens is often used. The token is issued to the front end when the form is generated, and the back end detects whether the token is used or not when the form is submitted, so that the anti-replay attack is realized. Specifically, in the existing scheme, a back-end generation token is generally adopted and stored in a Session, and the token is acquired during page initialization. The front end attaches the token when initiating the request to the back end, and the back end verifies the token after receiving the request. If the token exists in the Session, the request is judged to be a valid request, and the token is deleted after the processing is completed. If this token does not exist in the Session, then this request is either invalid or a repeat request. When judging whether the data is repeatedly submitted, the back end is required to generate a token in advance, and the front end is required to call an additional request to acquire the token. Each form is submitted with the additional addition of this token field, which is relatively labor intensive to develop.
Therefore, the scheme for preventing repeated submission of the data request can realize the verification process of completing repeated submission of the data request only by the back end, does not need any change of the front end, and reduces the workload of development.
Referring to fig. 1, an embodiment of the present application discloses a method for preventing repeated submission of data requests, which is applied to a backend, and includes:
step S11: when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request.
In this embodiment, when it is detected that each interface of the front end sends a target data request, the rear end intercepts the target data request by using an AOP technology, detects whether the target data request is a POST request, and directly intercepts the target data request detected as a non-POST or PUT request, which indicates that the non-POST or PUT request is a cached and stored repeated request, so that the intercepted condition is met and the target data request is directly intercepted. All POST or PUT requests are intercepted by AOP, and additional development for each interface is not needed.
Step S12: if yes, performing summary calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature.
In this embodiment, if the target data request is a POST or PUT request, the summary calculation operation is further performed on the target data request, specifically, summary calculation needs to be performed on the user information in the target data request and the first signature including the target parameters of the AOP facet class, where the target parameters of the AOP facet class specifically include, but are not limited to: package name, class name, method name, etc. of AOP cut class.
In this embodiment, the performing summary calculation on the user information in the target data request and the first signature including the target parameter of the AOP slice class to obtain the second signature further includes: traversing request parameters of the target data request to screen out target request parameters except the general parameters; sorting and combining the parameter values of the target request parameters to generate corresponding target character strings, and performing Url coding on the target character strings to generate target codes; performing hash operation on the target code according to a preset message digest algorithm to generate a target message digest; and performing Base64 coding operation on the target message digest to acquire a corresponding target message signature. It can be understood that the step of obtaining the target message signature in the process of performing the digest calculation on the first signature and obtaining the second signature is as follows:
1. and acquiring all target request parameter names of the interface, and traversing the parameter names. Parameters of the ServletRequest type need to be excluded, and the parameters are Spring general parameters, so that abstract calculation is not needed.
String[]params＝signature.getParameterNames()；
2. Acquiring values paramValue of all called parameters;
Object[]paramValues＝joinPoint.getArgs()；
3. ordering all request parameters according to the dictionary sequence of the paramName;
4. combining all parameters paramname=paramvalue pairs to generate a character string mergeStr, format "paramValue1" + "paramValue2" + "paramValue3" + ".
5. Performing Url coding on the generated mergeStr to generate a target coding encodStr;
6. performing hash operation on the encodst by utilizing an HmacSHA256 algorithm to generate a target message digest;
7. encoding the target message digest with Base 64;
8. and obtaining a final target message signature (SignStr).
In this embodiment, before performing the digest calculation on the user information in the target data request and the first signature including the target parameter of the AOP facet class, the method further includes: and splicing the target message signature with the package name, the class name and the method name of the AOP section class to obtain a first signature. It can be understood that, the target message signature sign str is spliced with the packet name, the class name and the method name of the AOP slice class to obtain the first signature, specifically, because the AOP slice technology is used, after the target data request is intercepted and judged, the digest calculation operation of the target data request conforming to the POST or PUT request is immediately started, specifically, the packet name, the class name and the method name of the corresponding AOP slice class are required to be spliced with the target message signature to obtain the first signature. Specifically, an AOP facet class is defined, and a Duplex SubmitCheckAOP is added with an annotation @ Aspect note on this class, indicating that this class is an AOP facet. An AOP notification (address) method, i.e., enhancement processing, is defined. The code is completed in this method according to the enhanced processing code that needs to be executed, i.e., interception and repeated verification of the request, completed at the access point.
An entry point (Pointcut) is defined in the AOP processing class,
@Pointcut("@annotation(org.springframework.web.bind.annotation.PostMap ping)")
public void postMapping(){}
@Pointcut("@annotation(org.springframework.web.bind.annotation.PutMapp ing)")
public void putMapping(){}
an annotation entry point annotation is added to this doCheck method. Indicating the method of intercepting all notes with PostMapping, putMapping. Since the prior verification is required before the intercepted method starts and the caching operation is performed after the ending, the surround notification is required here. The code is expressed as follows:
@Around("(execution(*xx.*.controller.*.*(..)))&&(postMapping()||
putMapping())")
public Object doCheck(ProceedingJoinPoint joinPoint)；
in the doCheck method, the digest value sign str is calculated for all parameters according to the digest algorithm described above.
Acquiring the package name, the class name and the method name of the class where the method is located, and splicing the package name, the class name, the method name and the sign Str into key1, namely splicing into a first signature, wherein the code is expressed as follows:
signature of the method of/(acquisition)
MethodSignature signature＝(MethodSignature)joinPoint.getSignature()；
The name of the packet is obtained
String packageName＝signature.getClass().getPackage().getName()；
Class name/acquisition
String className＝signature.getClass().getSimpleName()；
Method name for obtaining/obtaining
Method method＝signature.getMethod()；
String methodName＝method.getName()；
Composition key1
String key1＝packageName+"."+className+"."+methodName+"-"+signStr；
Step S13: and executing the digest calculation process on the second signature to acquire a target signature.
In this embodiment, after performing summary calculation on the spliced first signature, a second signature is obtained, and then the foregoing summary calculation process is performed again on the information including the second signature, so as to obtain the target signature.
Step S14: and detecting whether the target signature is consistent with the cache signature stored in the preset cache container, if so, prompting the target data request to repeatedly submit the request and throwing out an exception.
In this embodiment, whether the target signature subjected to the two times of summary calculation is consistent with the cache signature stored in the preset cache container is detected, and it should be noted that the cache signature is stored after the logic processing is completed, that is, the cache signature must be the corresponding signature after the corresponding target data request is executed. And comparing the calculated target signature with all the cache signatures, detecting whether the cache signatures are consistent, if so, indicating that the target data request corresponding to the target signature is executed, and if the current target data request is a repeated request, throwing an exception and directly prompting that the request is repeated submission, and ending the flow.
The application discloses a method for preventing repeated submission of data requests, which is applied to a back end and comprises the following steps: when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request; if yes, performing abstract calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature; executing the digest calculation process on the second signature to obtain a target signature; and detecting whether the target signature is consistent with the cache signature stored in the preset cache container, if so, prompting the target data request to repeatedly submit the request and throwing out an exception. Therefore, the target data request is intercepted through an AOP interception technology, whether the target data request is a POST or PUT request is judged, if yes, abstract calculation is conducted on the target data request, whether the target data request is a repeated submitting request is judged according to a target signature obtained after the abstract calculation, and in addition, the mode of comparing the cache signatures stored in the preset cache container is adopted, so that the method is simpler when judging whether the target data request is a repeated request.
Referring to fig. 2, an embodiment of the present application discloses a specific method for preventing repeated submission of data requests, and compared with the previous embodiment, the present embodiment further describes and optimizes a technical solution. Specific:
step S21: creating a cache constructor for constructing a cache container, and setting cache aging time; and constructing a preset cache container according to the cache constructor.
In this embodiment, the Guava Cache is used as a preset Cache container, and the Cache initialization mainly includes the following parts:
a// instantiation cache builder;
CacheBuilder cacheBuilder＝CacheBuilder.newBuilder()；
setting buffer aging time to 10 seconds;
cacheBuilder.expireAfterWrite(10,TimeUnit.SECONDS)
constructing a cache container;
Cache<String,String>cache＝cacheBuilder.build()；
it will be appreciated that by instantiating the cache constructor, setting the corresponding cache aging time, typically 10 seconds, may be set according to the actual situation, and is not limited thereto. Then a preset Cache container is constructed, and the Guava Cache is a set of very perfect local Cache mechanism in the Guava. The Guava Cache is realized based on the JVM memory, supports various Cache cleaning strategies, and has very high read-write concurrency performance. The Guava Cache is different from a universal Redis Cache, is based on JVM Cache, and does not need an additional server and network communication.
Step S22: when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request.
Step S23: if yes, performing summary calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature.
Step S24: and executing the digest calculation process on the second signature to acquire a target signature.
Step S25: and detecting whether the target signature is consistent with the cache signature stored in the preset cache container.
Step S25: and if the target data requests are consistent, prompting the target data requests to repeatedly submit the requests and throwing out the exception.
The more detailed processing procedures in steps S22, S23, S24, and S25 refer to the content of the foregoing disclosed embodiments, and are not described herein.
Step S26: if the target data requests are inconsistent, the target data requests are the first data requests, corresponding business logic is executed, and after the business logic processing is executed, the corresponding target signature is stored in the preset cache container.
In this embodiment, if the comparison result of the comparison target signature and the cache signature of the preset cache container is inconsistent, that is, the cache signature completely consistent with the target signature cannot be found in all the cache signatures in the preset cache container, so that it is indicated that the target data request corresponding to the current target signature is the first data request, never occurs before, and is a non-repeated request, then the target data request is executed correspondingly, and after the execution of the business logic processing is completed, the target signature is put into the preset cache container and is used as the cache signature to compare the target tags of other data requests, so as to further determine whether the corresponding data request is a repeated request.
Therefore, the whole process of the application is realized by the back end without any change of the front end. And calculating a target signature of the data request by utilizing an AOP interception technology and utilizing a summary algorithm, and judging whether the request is a repeated request or not according to the target signature when the front end sends the submitted request. In addition, in order to achieve convenience, the target signature is stored in a local Guava Cache, and the used target signature is stored by utilizing the Guava Cache to judge whether the generated data request is a repeated request or not, so that the running efficiency is improved, and dependence on Redis or a data server and the like is avoided. And by utilizing a summary algorithm, the Cache signature is stored in the Guava Cache, all data requests do not need to be stored, and the storage quantity is reduced.
Referring to fig. 3, an embodiment of the present application discloses another specific method for preventing repeated submission of data requests, and the present embodiment further describes and optimizes the technical solution with respect to the previous embodiment.
Specific:
step S31: when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request.
Step S32: if so, acquiring the user name of the login user generating the target data request from the back-end Session, and if the user name is acquired, combining the user name with the first signature to be used as a second signature; and performing preset message digest algorithm calculation and Base64 coding operation on the user name and the first signature to acquire a target signature.
In this embodiment, if the target data request is a POST or PUT request, the user name of the login user is obtained from the Session, and if the user name of the target data request is obtained, the second signature is obtained by means of the user name+the first signature, for example: the key 2=username+ "-" +key1, then the HmacSHA256 algorithm and the Base64 algorithm are executed on the key2, so that the data length required to be cached is reduced, and the final cacheKey, namely the target signature, is obtained.
Step S33: if yes, acquiring the IP address of the target data request as a target IP if the user name is acquired to be empty; combining the target IP with the first signature to obtain a second signature; and performing preset message digest algorithm calculation and Base64 coding operation on the target IP and the first signature to acquire the target signature.
In this embodiment, if the target data request is a POST or PUT request and the user name of the login user in the target data request is obtained from the session is null, the IP of the target data request is obtained, because part of the target data request does not have a user name, in order to reduce the collision of different users, the additional obtaining request IP is denoted as IP, and the second signature is obtained in a manner that ip+the user name is null+the first signature, for example: key2=ip+ "-" +username+ "-" +key1, where username is null. And then executing the HmacSHA256 algorithm and the Base64 algorithm on the key2 to reduce the data length to be cached and obtain the final cacheKey, namely the target signature.
Step S34: and detecting whether the target signature is consistent with the cache signature stored in the preset cache container, if so, prompting the target data request to repeatedly submit the request and throwing out an exception.
In the more detailed processing in steps S31 and S34, please refer to the above disclosed embodiment, and the detailed description is omitted here.
Therefore, the unique target signature is formed through the user IP, the user name, the package name, the class name, the method name and the parameter calculation abstract for repeated judgment, and the login user information is added in the signature algorithm in consideration of the fact that different users submit the same request parameters; considering that part of requests possibly do not need to log in and user information does not exist, the requests which do not need to be sent by a user login port are compatible, IP address information is added in a signature algorithm, and collision possibility is reduced; considering different requests of the same user, the same parameters may be present, and the package name, class name and method name are added in the signature algorithm. And signing the user information, the method information and the parameters twice, so that the cached data volume is reduced, and the target signature is shortened.
Referring to fig. 4, the embodiment of the application also correspondingly discloses a device for preventing repeated submission of data requests, which is applied to a back end and comprises:
the request detection module 11 is configured to intercept a target data request and determine whether the target data request is a POST or PUT request when detecting that the front end sends the target data request;
a first digest calculation module 12, configured to perform digest calculation on the user information in the target data request and a first signature including the target parameter of the AOP facet class if yes, so as to obtain a second signature;
a second digest calculation module 13, configured to perform the foregoing digest calculation procedure on the second signature, so as to obtain a target signature;
the request judging module 14 is configured to detect whether the target signature is consistent with a cache signature stored in a preset cache container, and if so, prompt the target data request to repeatedly submit the request and throw an exception.
Therefore, when the front end sending target data request is detected, the application intercepts the target data request and judges whether the target data request is a POST or PUT request; if yes, performing abstract calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature; executing the digest calculation process on the second signature to obtain a target signature; and detecting whether the target signature is consistent with the cache signature stored in the preset cache container, if so, prompting the target data request to repeatedly submit the request and throwing out an exception. Therefore, the target data request is intercepted through an AOP interception technology, whether the target data request is a POST or PUT request is judged, if yes, abstract calculation is conducted on the target data request, whether the target data request is a repeated submitting request is judged according to a target signature obtained after the abstract calculation, and in addition, the mode of comparing the cache signatures stored in the preset cache container is adopted, so that the method is simpler when judging whether the target data request is a repeated request.
Further, the embodiment of the present application further discloses an electronic device, and fig. 5 is a block diagram of an electronic device 20 according to an exemplary embodiment, where the content of the figure is not to be considered as any limitation on the scope of use of the present application.
Fig. 5 is a schematic structural diagram of an electronic device 20 according to an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input output interface 25, and a communication bus 26. Wherein the memory 22 is configured to store a computer program that is loaded and executed by the processor 21 to implement the relevant steps of the method for preventing repeated submission of data requests disclosed in any of the foregoing embodiments. In addition, the electronic device 20 in the present embodiment may be specifically an electronic computer.
In this embodiment, the power supply 23 is configured to provide an operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and an external device, and the communication protocol to be followed is any communication protocol applicable to the technical solution of the present application, which is not specifically limited herein; the input/output interface 25 is used for acquiring external input data or outputting external output data, and the specific interface type thereof may be selected according to the specific application requirement, which is not limited herein.
Processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 may be implemented in at least one hardware form of DSP (Digital Signal Processing ), FPGA (Field-Programmable Gate Array, field programmable gate array), PLA (Programmable Logic Array ). The processor 21 may also comprise a main processor, which is a processor for processing data in an awake state, also called CPU (Central Processing Unit ); a coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit, image processor) for rendering and drawing of content required to be displayed by the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence ) processor for processing computing operations related to machine learning.
The memory 22 may be a carrier for storing resources, such as a read-only memory, a random access memory, a magnetic disk, or an optical disk, and the resources stored thereon may include an operating system 221, a computer program 222, and the like, and the storage may be temporary storage or permanent storage.
The operating system 221 is used for managing and controlling various hardware devices on the electronic device 20 and the computer program 222, so as to implement the operation and processing of the processor 21 on the mass data 223 in the memory 22, which may be Windows Server, netware, unix, linux, etc. The computer program 222 may further include a computer program that can be used to perform other specific tasks in addition to the computer program that can be used to perform the data request resubmission prevention method performed by the electronic device 20 disclosed in any of the previous embodiments. The data 223 may include, in addition to data received by the electronic device and transmitted by the external device, data collected by the input/output interface 25 itself, and so on.
Further, the application also discloses a computer readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the previously disclosed method of preventing data request resubmission. For specific steps of the method, reference may be made to the corresponding contents disclosed in the foregoing embodiments, and no further description is given here.
In this specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, so that the same or similar parts between the embodiments are referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant points refer to the description of the method section.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application. The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
Finally, it is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The method, the device, the equipment and the storage medium for preventing repeated submission of the data request provided by the application are described in detail, and specific examples are applied to the principle and the implementation mode of the application, and the description of the above examples is only used for helping to understand the method and the core idea of the application; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in accordance with the ideas of the present application, the present description should not be construed as limiting the present application in view of the above.
Claims (10)
1. A method for preventing repeated submission of data requests, characterized by being applied to a back end, comprising:
when detecting that the front end sends a target data request, intercepting the target data request and judging whether the target data request is a POST or PUT request;
if yes, performing abstract calculation on the user information in the target data request and the first signature containing the target parameters of the AOP section class to obtain a second signature;
executing the digest calculation process on the second signature to obtain a target signature;
and detecting whether the target signature is consistent with the cache signature stored in the preset cache container, if so, prompting the target data request to repeatedly submit the request and throwing out an exception.
2. The method for preventing repeated submission of data requests according to claim 1, wherein the performing a digest calculation on the user information in the target data request and the first signature including the target parameter of the AOP facet class to obtain the second signature further comprises:
traversing request parameters of the target data request to screen out target request parameters except the general parameters;
sorting and combining the parameter values of the target request parameters to generate corresponding target character strings, and performing Url coding on the target character strings to generate target codes;
performing hash operation on the target code according to a preset message digest algorithm to generate a target message digest;
and performing Base64 coding operation on the target message digest to acquire a corresponding target message signature.
3. The method for preventing resubmitting of a data request of claim 2, wherein before performing the digest calculation on the user information in the target data request and the first signature containing the target parameter of the AOP slice class, further comprising:
and splicing the target message signature with the package name, the class name and the method name of the AOP section class to obtain a first signature.
4. The method of claim 1, wherein performing a digest calculation on the user information in the target data request and the first signature including the target parameter of the AOP cut class to obtain the second signature comprises:
acquiring a user name of a login user generating a target data request from a back-end Session, and if the user name is acquired, combining the user name with the first signature to be used as a second signature;
correspondingly, the performing the foregoing digest calculation procedure on the second signature to obtain a target signature includes:
and performing preset message digest algorithm calculation and Base64 coding operation on the user name and the first signature to acquire a target signature.
5. The method for preventing repeated submission of data requests according to claim 4, further comprising, after the user name of the logged-in user who generated the target data request is obtained from the back-end Session:
if the user name is obtained to be empty, the IP address of the target data request is obtained and is used as a target IP;
combining the target IP with the first signature to obtain a second signature;
correspondingly, the performing the foregoing digest calculation procedure on the second signature to obtain a target signature includes:
and performing preset message digest algorithm calculation and Base64 coding operation on the target IP and the first signature to acquire the target signature.
6. The method for preventing repeated submission of data requests according to claim 1, further comprising, after said detecting whether the target signature is consistent with a cache signature stored in a preset cache container:
if the target data requests are inconsistent, the target data requests are the first data requests, corresponding business logic is executed, and after the business logic processing is executed, the corresponding target signatures are stored in a preset cache container.
7. The method for preventing repeated submission of data requests according to any of claims 1-6, further comprising:
creating a cache constructor for constructing a cache container, and setting cache aging time;
and constructing a preset cache container according to the cache constructor.
8. A device for preventing repeated submission of data requests, characterized by being applied to a back end, comprising:
the request detection module is used for intercepting a target data request and judging whether the target data request is a POST or PUT request when detecting that the front end sends the target data request;
the first abstract calculation module is used for carrying out abstract calculation on the user information in the target data request and a first signature containing the target parameters of the AOP section class if yes so as to acquire a second signature;
the second digest calculation module is used for executing the digest calculation process on the second signature so as to acquire a target signature;
and the request judging module is used for detecting whether the target signature is consistent with the cache signature stored in the preset cache container, and if so, prompting the target data request to repeatedly submit the request and throwing out an exception.
9. An electronic device, comprising:
a memory for storing a computer program;
a processor for executing the computer program to implement the steps of the method of preventing repeated submission of data requests as claimed in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program; wherein the computer program when executed by a processor implements the steps of the method of preventing data request resubmission as claimed in any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310755117.XA CN116627657A (en) | 2023-06-25 | 2023-06-25 | Method, device, equipment and storage medium for preventing repeated submission of data request |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310755117.XA CN116627657A (en) | 2023-06-25 | 2023-06-25 | Method, device, equipment and storage medium for preventing repeated submission of data request |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116627657A true CN116627657A (en) | 2023-08-22 |
Family
ID=87602629
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310755117.XA Withdrawn CN116627657A (en) | 2023-06-25 | 2023-06-25 | Method, device, equipment and storage medium for preventing repeated submission of data request |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116627657A (en) |
-
2023
- 2023-06-25 CN CN202310755117.XA patent/CN116627657A/en not_active Withdrawn
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2018177124A1 (en) | Service processing method and device, data sharing system and storage medium | |
| US9282088B2 (en) | Request authentication token | |
| US8984593B2 (en) | Securing asynchronous client server transactions | |
| US20200410796A1 (en) | Secure smart unlocking | |
| WO2021047193A1 (en) | Voice processing method and apparatus, device, and computer storage medium | |
| CN101622587B (en) | Centralized service for awakening a computing device | |
| US20080289025A1 (en) | Method and an apparatus to validate a web session in a proxy server | |
| CN109951546B (en) | Transaction request processing method, device, equipment and medium based on intelligent contract | |
| CN113239308B (en) | Page access method, device, equipment and storage medium | |
| JP2006072970A (en) | Information processing method and device | |
| US7974956B2 (en) | Authenticating a site while protecting against security holes by handling common web server configurations | |
| CN109218389A (en) | The method, apparatus and storage medium and electronic equipment of processing business request | |
| WO2021047197A1 (en) | Speech processing method, apparatus and device, and computer storage medium | |
| WO2022062478A1 (en) | Method and apparatus for detecting arbitrary account password reset logic vulnerability, and medium | |
| CN111010379A (en) | Data login method and device based on block chain network | |
| CN116627657A (en) | Method, device, equipment and storage medium for preventing repeated submission of data request | |
| WO2013098925A1 (en) | Information processing apparatus, information processing system, information processing method, and program | |
| CN113225348B (en) | Request anti-replay verification method and device | |
| CN111614676B (en) | Login method, device, equipment and medium | |
| CN111858100A (en) | BMC message transmission method and related device | |
| CN112187786A (en) | Service processing method, device, server and storage medium of network service | |
| US9736256B2 (en) | Implementing server push at server stack | |
| CN114500031B (en) | System, method, electronic equipment and medium for acquiring BI report based on single sign-on | |
| WO2023230797A1 (en) | Cross-system test method and apparatus | |
| JP5840796B2 (en) | Establishing a client-host connection |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WW01 | Invention patent application withdrawn after publication | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20230822 |