Home >Backend Development >PHP Tutorial >Enhanced version of communication process design between mobile terminal and PHP server interface

Enhanced version of communication process design between mobile terminal and PHP server interface

WBOY
WBOYOriginal
2016-07-29 09:04:011230browse

As mentioned before: Mobile terminal and PHP server interface communication process design (basic version)

For the verification of api_token, its security can be further enhanced:

Enhancement 1:

Add 2 more There are two tables, one interface table and one authorization table. The design reference is as follows:

interface table

field name field type note
api_id int Interface ID
api_name varchar(120) Interface name, with "/" as the dividing line, such as blog/Index/addBlog
api_domain varchar(256) Domain
is_enabled tinyint(1) is available 1: Available 0: Not available
add_time int Add time (stamp)

(Note: Only core fields are listed, others Expand it again! ! )

Authorization table

Field nameintintvarchar(120)tinyint(1)intint (Note: only core fields are listed, other Let’s expand it! ! )The execution process is as follows:
Comment client_id
Client ID api_id
api number api_name
Interface name, with "/" as the dividing line, such as blog/Index/addBlog is_enabled
is available 1: Available 0: Not available add_time
Add time (stamp) expire_time
Expiration time (stamp)

1. Compare the api_token generated by the mobile terminal and the server. If they are not equal, an error will be returned directly. Otherwise, go to the next step;

2. According to the interface URL, assemble api_name, plus the client_id returned by the client as a parameter, search for the "authorization table" record, if the record exists and is valid (whether it is available, whether it has expired), it means that the permission verification is passed, and the interface data is returned, otherwise it is returned Error message;

Enhancement Part 2:

For some very special interfaces, I don’t know how they are special and which ones are special. In short, I feel that the http request may be hijacked and the parameters passed may be tampered with. Let me give you an example: There is a direct transfer interface. I entered 5 yuan on the page, which means that I want to transfer 5 yuan to the other party. As a result, someone hijacked it during the HTTP transfer process. And changed it to 10,000 yuan, and the account was changed to the account of a "hacker". That's not a big loss. After thinking about it, there should be two solutions to this problem.

Option 1: Use https, this is not the case More to say, it is a relatively recognized security mechanism;

Option 2: Use digital signature, the implementation principle is as follows:

An http request, if you need to pass the following 3 parameters

Parameter name 1=Parameter value 1

Parameter name 2= Parameter value 2

Parameter name 3 = Parameter value 3

We can add another parameter, the parameter’s name is

identity_key

(the name is not important), the value of this parameter is

The first few parameter values ​​are in order The result is added and then encrypted.

That is:

identity_key

= md5('parameter value 1' + 'parameter value 2' + 'parameter value 3' + '

encryption key

');So, the final parameters passed are: Parameter name 1=Parameter value 1

Parameter name 2=Parameter value 2

Parameter name 3=Parameter value 3

client_id=client_id value

identity_key=md5('Parameter value 1' + 'Parameter value 2' + 'Parameter value 3' + 'client_id value' + '

Encryption key

')

After receiving the parameters, the server regenerates an identity_key according to the same encryption rules, the server's

identity_key

and the client Check the identity_key on the terminal. If they are not equal, it means it has been tampered with. You can figure out what to do next! The above introduces the enhanced version of the communication process design between the mobile terminal and the PHP server interface, including various aspects. I hope it will be helpful to friends who are interested in PHP tutorials.

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn