Mobile and PHP server-side interface communication Process Design enhanced version

Previous: Mobile and PHP service-side interface Communication process design (Basic version)

For api_token Verification, the security can be further enhanced:

Reinforcement Place One:

Add 2 more tables, an interface table , an authorization table , and the design reference is as follows:

Interface table

Field name	Field type	Comments
api_id	Int	Interface ID
Api_name	varchar (120)	Interface name, with "/" as a split line, such as Blog/index/addblog
Api_domain	VARCHAR (256)	Industry
Is_enabled	tinyint (1)	Available 1: Available 0: Not available
Add_time	Int	Add Time (Stamp)

(Note: Only the core fields are listed, other extensions!!!) ）

Authorization Form

Field name	Field type	Comments
client_id	Int	Client ID
api_id	Int	API number
Api_name	varchar (120)	Interface name, with "/" as a split line, such as Blog/index/addblog
Is_enabled	tinyint (1)	Available 1: Available 0: Not available
Add_time	Int	Add Time (Stamp)
Expire_time	Int	Expiration Time (stamp)

(Note: Only the core fields are listed, other extensions!!!) ）

The execution process is as follows:

1, the mobile side and the server generated by the Api_token comparison, if not equal, then directly return the error, otherwise, go to the next step;

2, according to the interface URL, assembly Api_name, plus the client back client_id as parameters, look for "authorization table" record, if the record exists, and valid (whether available, whether expired), then the authorization pass, return interface data, otherwise return error message;

Reinforcement Place Two:

For some very special interface, how special, which is special, I do not know, in a word, is to feel the HTTP request may be robbed, passing parameters may be tampered with, or for example:

There is a direct transfer interface, the page I input is 5 yuan, I want to give each other a transfer of 5 yuan, the result in the HTTP transmission process, was robbed and changed into 10000 yuan, and the object into a "hacker" account, that is not lost Dafa, think about, there should be 2 solutions to this problem,

Scenario One: Take the HTTPS, this is not much to say, more commonly recognized security mechanisms;

Scenario Two: Walk the digital signature, the realization principle is as follows:

An HTTP request, if required to pass the following 3 parameters

Parameter Name 1 = value of parameter 1

Parameter Name 2 = value of parameter 2

Parameter name 3 = value of parameter 3

We can append a parameter with the name Identity_key (what is not important), the value of the parameter is the value of the previous parameter added sequentially, and then the result of the encryption.

That

Identity_key = MD5 (' parameter value 1 ' + ' parameter value 2 ' + ' parameter value 3 ' + ' encryption key ');

Finally, the parameters are passed:

Parameter Name 1 = value of parameter 1

Parameter Name 2 = value of parameter 2

Parameter name 3 = value of parameter 3

client_id=client_id value

IDENTITY_KEY=MD5 (' parameter value 1 ' + ' parameter value 2 ' + ' parameter value 3 ' + ' client_id value ' + ' encryption key ')

After the service is terminated with the parameters, the same encryption rules are regenerated to generate a copy of the Identity_key, and the Identity_key of the server and the Identity_key of the client are proofread, if not equal, Said to be changed, then how to operate, you look at it!

The above describes the mobile and PHP Server Interface communication process design enhancements, including aspects of the content, I hope that the PHP tutorial interested in a friend helpful.

