Mobile and PHP Server Interface communication process design (enhanced version)

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 ')

Service end to the parameters, and then the same encryption rules to regenerate a copy of the Identity_key, the service side of the Identity_key and the client's identity_key to proofread, if not equal, said to be channeling, then how to operate, see for yourself!

Mobile and PHP Server Interface communication process design (enhanced version)