CN112667417A - APP interaction process safety verification method - Google Patents

Abstract

The invention discloses a method for safety check of an APP interaction process, which comprises the following steps: (1) the APP sends a request to a server; (2) the server checks the route state of the current APP front end according to the request of the APP in the step (1); (3) the server side returns the check state and the front-end routing URL to the APP front end; (4) and the APP performs page jump. The invention can solve the problem of a safety mechanism in the interactive flow transfer process of multi-end login in the same flow, and solve the problems of a newly added sub-flow and a jumping sub-flow, so that the related functions are more robust. When data interaction is added, the server side checks the current front-end APP routing state, and data MD5 encryption and anti-sequence processing are used, so that data security is enhanced, and data tampering is prevented.

Description

APP interaction process safety verification method

Technical Field

The invention particularly relates to a safety verification method for an APP interaction process.

Background

In recent years, the mobile internet has been developed in a blowout manner, and the life of people is changed from various aspects of clothes and eating houses. The technology of intelligent terminal APP (Application) is fully developed at this stage, and the kinds and the number of APPs developed by various industries are exponentially increased.

The related route processing of the front-end APP with the existing function is fixedly written according to the interface state, and is not very flexible relatively, and meanwhile, the front-end APP processing is performed on the route, so that the safety is not particularly good.

In the prior art, the interaction between the APP and the back end is only directed at the relevant data state, the jump of the relevant interaction flow is processed in the front-end APP, if the same user account is operated at multiple ends simultaneously, the flow of the relevant interaction is influenced, and if the interaction is higher in security level, the relevant security problem is caused.

Disclosure of Invention

Aiming at the situation, in order to overcome the defects of the prior art, the invention provides a method for safety verification of an APP interaction process.

In order to achieve the purpose, the invention provides the following technical scheme:

a safety verification method for an APP interaction process comprises the following steps:

(1) the APP sends a request to a server;

(2) the server checks the route state of the current APP front end according to the request of the APP in the step (1);

(3) the server side returns the check state and the front-end routing URL to the APP front end;

(4) and the APP performs page jump.

Further, the transmission data is subjected to MD5 encryption in step (1).

Further, in the step (3), after the server returns the check state and the front-end routing URL to the APP front end, the APP can perform MD5 decryption on the returned data, perform deserialization processing after checking is accurate, then read the routing URL data, perform validity check, perform secondary security check processing after the routing URL is legal by combining parameters, jump to the page corresponding to the routing URL if the security check is accurate, and jump to the corresponding specified page if the check is not passed.

Further, in the step (2), the verification includes a security verification, and the security verification is performed from the following 3 points:

a) the APP front-end requests a token,

b) the user's online status token parameter,

c) in response to the encryption rules for the data being transmitted,

if any one of the three points does not pass through, the safety problem is shown, the current login user is forced to exit the login state, and the routing URL returns to the login page.

Further, in step (2), the checking includes an authentication status check: and if the authentication state of the current user passes the authentication, the next step of processing can be carried out, otherwise, the route URL is returned, and the APP user is controlled to jump to the user authentication data submission process.

The invention has the beneficial effects that:

(1) the invention can solve the problem of a safety mechanism in the interactive flow transfer process of multi-end login in the same flow, and solve the problems of a newly added sub-flow and a jumping sub-flow, so that the related functions are more robust.

(2) When data interaction is added, the server side checks the current front-end APP routing state. Data MD5 encryption and anti-sequence processing are used, data security is enhanced, and data tampering is prevented. The server side performs synchronous control processing on the time sequence state, controls the front-end APP to synchronize the state of the same event process processed by the other side in real time, directly controls the APP to skip one or more steps, and directly controls the route to jump to the page corresponding to the latest process.

(3) In the invention, the server flexibly adjusts the flow circulation corresponding to the front-end function module according to the service; and the server controls the front-end APP route according to the interactive time sequence check by adding a front-end route configuration table.

(4) According to the invention, through the communication verification of the server, the jump and the authority control of the front-end APP interaction process are controlled and processed more safely and flexibly, and the problem of repeated flow submission caused by the same process operation of a multi-end user is solved.

Drawings

FIG. 1 is a schematic flow diagram of the process of the present invention.

FIG. 2 is a flow chart illustrating the application of the method of the present invention to item delivery.

FIG. 3 is a timing diagram of the application of the method of the present invention to item delivery.

Fig. 4 is a schematic diagram of a computer device.

Detailed Description

The technical solutions of the present invention are further described in detail below with reference to the accompanying drawings, and it should be noted that the detailed description is only for describing the present invention, and should not be construed as limiting the present invention.

Example 1

As shown in fig. 1, a method for APP interaction flow security verification includes the following steps:

(1) in order to realize a certain function of the APP, the APP sends a request to a server;

(2) the server checks the route state of the current front-end APP according to the request of the APP in the step (1);

(3) the server side returns the check state and the front-end routing URL to the APP front end;

(4) the server controls APP routing to the end page.

The sub-flows in fig. 1 are the corresponding single request data flows in fig. 2.

In some preferred manners, in any sub-process of the interaction process, if the user performs a related operation under another terminal to cause a related interaction state change, when the user performs the next data interaction in the operation process, the related state is checked, and the next interaction is correspondingly controlled.

In some preferred modes, data MD5 encryption is used in step (1), so that data security is enhanced, and data tampering is prevented.

Specifically, during the data interaction process between the APP front end and the server, MD5 encryption is performed on the transmission data, and security check is performed after the data is received. The security check comprises checking a token of the request data, token information of the user and the like.

In the step (3), the server returns the check result and the front-end route URL to the APP front-end, the APP performs MD5 decryption on the returned data, performs deserialization processing after checking is accurate, then reads the route URL data, and performs validity check (only the current route page of the front-end can perform the jump of the corresponding page). The validity check refers to: according to the comparison between the URL and the front-end routing page, if the returned URL can not be matched in the front-end routing list, the URL is illegal, and if the returned URL can be matched, the URL is legal. And after the routing URL is legal, performing secondary security check processing by combining the parameters (if the corresponding state parameters are returned). If the safety proofreading is accurate, the page corresponding to the routing URL is jumped, and if the proofreading does not pass, the page appointed by the corresponding service design is jumped. And setting a non-state parameter to return, namely, the non-sensitive page, and for the non-sensitive page, secondary proofreading processing of the state parameter is not needed.

In some preferred modes, the server controls the front-end APP route according to the interactive timing sequence check by adding a front-end route configuration table.

Figure 1 is only a simplified illustration of the solution according to the invention. In particular, the corresponding check is shown in the judgment process of the corresponding flow in fig. 2, as is also referred to in the specific single request of fig. 3.

In some preferred modes, the server flexibly adjusts the flow circulation of the corresponding front-end functional module according to the service.

In some preferred manners, in step (4), the server side performs synchronous control processing on the time sequence state, controls the front-end APP to synchronize the state of the same event process processed by the other side in real time, directly controls the APP to skip one or more steps, and directly controls the route to jump to the page corresponding to the latest process.

Example 2

The interactive sub-process in fig. 1 is illustrated as the corresponding single request data process in fig. 2, taking delivery of items in the financing investment domain as an example.

An application of an APP interaction process safety verification method in project delivery is provided.

Specifically, as shown in fig. 2:

to implement this functionality of APP delivery items, a delivery item refers to: the project side user (i.e., the person needing financing) delivers the project to the investor.

(1) Firstly, an APP initiates an interface for requesting delivery to a server, the server returns a check state and the like to an APP front end, and the front end routes to skip;

the server performs the verification, and the specific flow is shown in fig. 3. And the server side returns the check result and the like to the APP front end, and the APP can decrypt the returned data by MD5 and check the data accurately. And then, carrying out validity check on the routing URL (only the current routing page at the front end can carry out the jump of the corresponding page). And after the routing URL is legal, performing secondary security check processing by combining parameters (if corresponding state parameters are returned, some non-sensitive pages do not need secondary check processing of the state parameters). If the safety proofreading is accurate, the page corresponding to the drop URL is jumped, and if the safety proofreading is not passed, the page appointed by the corresponding business design is jumped.

The verification results include the following:

1-1) if the login user fails or the current environment is unsafe, the route jumps to a login page, the user is forced to log in and log out, and when the user logs in again, the user returns to a page corresponding to the delivery process;

and after the server side judges and analyzes the results, returning the analysis results to the APP front end. If the page is the page with the higher corresponding security level, the state parameter is returned, and secondary security correction is conveniently carried out on the front-end APP.

The server judges that the login user is invalid or the current environment is unsafe according to the following factors.

(a) The APP client requests a token which,

(b) the user's online status token parameter,

(c) corresponding to the encryption rules of the transmitted data.

If the token requested by the user does not have decryption error of the server side caused by abnormity (failure) of the token of the user or encryption error of transmission data, the login user is failed or the current environment is unsafe.

1-2) if the check is passed, the route returns a confirmation delivery page.

(2) And requesting to confirm the delivery interface on a confirmation delivery page (selecting an item), wherein the item refers to an item of a financing party (an item party), and a plurality of items can be selected.

The project side needs to select a project which is uploaded on the platform and passes the authentication to deliver after confirming the delivery page. Item delivery requires the selection of a valid item (i.e., an item that has been uploaded on the platform and authenticated) for delivery.

2-1) if the project is abnormal, returning a confirmed delivery page by the route; the term exception refers to:

a) the currently selected item, which is already off-shelf on the platform at the time the delivery request is submitted.

b) When the currently selected item submits the delivery request, the account of the user deletes the item at other terminals, and the item is caused to be absent.

2-2) controlling the route to jump to the talk-around page if the item was previously delivered;

specifically, if the item is delivered before, the server returns a routing URL, and the APP performs corresponding page jump after decryption and verification of the URL according to the routing URL.

2-3) if other safety keeping mechanisms are triggered, the route control jumps to deliver an initial entry page;

the server side judges whether the security maintenance mechanism is triggered according to the following factors:

a) the APP client requests a token which,

b) the user's online status token parameter,

c) corresponding to the encryption rules of the transmitted data.

If the token requested by the user does not correct the server decryption error caused by the abnormity (failure) of the user token or the encryption error of the transmission data, the method is regarded as that: the security maintenance mechanism is triggered.

2-4) if the deduction times exist, controlling the route to jump to the negotiation page;

the number of times of buckling is as follows: if the project party (i.e. the financing party) is a VIP user, the number of delivery deductions is received for several times when the VIP privilege is obtained.

2-5) if the delivery deduction ticket activity exists currently, returning to the deduction ticket purchasing page, after the deduction ticket purchasing is successful, automatically deducting, and returning to the delivery completion page.

If there is a discount coupon purchase activity currently, the user can directly purchase the discount coupon without the number of times of discount and discount coupon, and then deliver the item.

2-6) no delivery deduction activity and times deduction, and returning the route to a delivery order confirmation payment page.

The above-mentioned judgment results (such as whether the item is abnormal, whether the item was delivered before, whether there are deduction times, whether there are delivery deduction ticket activities, etc.) are judged and processed by the server when receiving the request for confirming the delivery interface.

On the delivery order confirmation payment page, the APP requests a payment interface,

a) if the server detects that other terminals have paid or processed the delivery, controlling the route to jump to the negotiation page;

b) if the server detects the trigger of other safety maintenance mechanisms, the route control jumps to the initial entry page;

c) and if the server detects that the payment is successful, the route return control jumps to a delivery completion page.

Fig. 3 is a sequence diagram corresponding to the server side response request for implementing the delivery function service, and the diagram controls the return of the front-end routing and verification status according to the time sequence of the delivery interface server side in the delivery service. Wherein the related parameter refers to a verification status or a verification result.

Specifically, fig. 3 is the interaction sub-flow described in fig. 1. FIG. 3 is a timing diagram of the response of the server to the APP request after the "request delivery interface" in the delivery service of FIG. 2.

The project side (user) sends a delivery interface request through the APP side,

(1) the delivery micro-service of the server (the server is a micro-service architecture) firstly responds to the request interface to obtain the request data,

(2) then, calling a 'safety micro service' to perform safety verification, wherein the safety verification is mainly performed from the following 3 points:

a) the APP client requests a token which,

b) the user's online status token parameter,

c) corresponding to the encryption rules of the transmitted data.

If any one of the three points does not pass (if the token requested by the client is not right, the security check is not passed; if the online state token of the user is abnormal (invalid), the security check is not passed; or if the server side decryption error caused by the data encryption error is transmitted, the security check is not passed), the parameters (namely, the check state) and the route (URL) are returned, { namely, the security problem exists, the current login user is forced to exit the login state, and the route URL is returned to the login page }.

The user can continue the operation of the process after logging in again.

(3) After the safety micro-service processing is passed, the authentication micro-service is called to check the authentication state of the current user, and the next logic processing can be carried out only if the authentication state of the current user passes the authentication,

otherwise, returning to the route (URL) to control the APP user to jump to the user authentication data submission process. (only after the user is authenticated, the delivery item can be processed, so that the investor is ensured not to be interfered by a fake item party).

(4) And after the authentication micro-service processing is passed, processing other micro-service flows.

(5) Whether the current project side and the investor to be delivered currently have delivery history orders. If not, a route is returned to the delivery confirmation page. If so, the delivery process is directly skipped to the next process page (end page). This avoids repeated deliveries.

Example 3

A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor is capable of implementing the steps of the interactive process security verification method as described above when executing the computer program.

Example 4

A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the APP interaction flow security check method described above.

In this embodiment, the computer program may be the computer program in embodiment 3.

In this embodiment, the computer-readable storage medium can be executed by the computer apparatus in embodiment 3.

It will be understood by those skilled in the art that all or part of the processes of the above embodiments may be implemented by hardware instructions of a computer program, which may be stored in a non-volatile computer-readable storage medium, and when executed, may include the processes of the above embodiments of the methods. Any reference to memory, storage, databases, or other media used in embodiments provided herein may include non-volatile and/or volatile memory. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

The features of the above-mentioned embodiments may be arbitrarily combined, and for the sake of brevity, all possible combinations of the above-mentioned embodiments are not described, but should be construed as being within the scope of the present specification as long as there is no contradiction between the combinations of the features.

The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of protection. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention.

Claims (5)

1. A safety verification method for an APP interaction process is characterized by comprising the following steps:

(1) the APP sends a request to a server;

(2) the server checks the route state of the current APP front end according to the request of the APP in the step (1);

(3) the server side returns the check state and the front-end routing URL to the APP front end;

(4) and the APP performs page jump.

2. The method for APP interaction process security verification as claimed in claim 1, wherein in step (1), the transmitted data is encrypted by MD 5.

3. The method for safety check of APP interaction process as claimed in claim 1, wherein in step (3), after the server returns the check state and the front-end routing URL to the APP front-end, the APP performs MD5 decryption on the returned data, performs deserialization after the check is accurate, then reads the routing URL data, performs validity check, performs secondary safety check processing after the routing URL is legal by combining with the parameters, jumps to the page corresponding to the routing URL if the safety check is accurate, and jumps to the corresponding designated page if the check is not successful.

4. The method of claim 1, wherein in the step (2), the verification includes a security verification, and the security verification is performed from the following 3 points:

a) the APP front-end requests a token,

b) the user's online status token parameter,

c) in response to the encryption rules for the data being transmitted,

if any one of the three points does not pass through, the safety problem is shown, the current login user is forced to exit the login state, and the routing URL returns to the login page.

5. The method of claim 1, wherein in step (2), the checking includes authentication status checking: and if the authentication state of the current user passes the authentication, the next step of processing can be carried out, otherwise, the route URL is returned, and the APP user is controlled to jump to the user authentication data submission process.

Images