移动端与PHP服务端接口通信流程设计(增强版)

增强地方一:

再增加2张表,一个接口表,一个授权表,设计参考如下:

接口表

字段名 字段类型 注释
api_id int 接口ID
api_name varchar(120) 接口名,以"/"作为分割线,如 blog/Index/addBlog
api_domain varchar(256) 所属领域
is_enabled tinyint(1) 是否可用  1:可用 0:不可用
add_time int 添加时间(戳)

(注:只列出了核心字段,其它的再扩展吧!!!)

授权表

字段名 字段类型 注释
client_id int 客户端ID
api_id int api编号
api_name varchar(120) 接口名,以"/"作为分割线,如 blog/Index/addBlog
is_enabled tinyint(1) 是否可用  1:可用 0:不可用
add_time int 添加时间(戳)
expire_time int 过期时间(戳)

(注:只列出了核心字段,其它的再扩展吧!!!)

执行过程如下:

1、移动端与服务端生成的 api_token 进行对比,如果不相等,则直接返回错误,否则,进入下一步;

2、根据接口URL,组装 api_name,再加上客户端传回的 client_id 为参数,查找 “授权表”记录,如果记录存在,且有效(是否可用,是否过期),则表示权限验证通过,返回接口数据,否则返回错误信息;

增强地方二:

对于一些很特殊的接口,怎么特殊,哪些算特殊,我也不知道,总而言之,就是感觉http请求有可能被劫取,传递参数有可能被窜改等情况,还是举个例子来说吧:

有个直接转账接口,页面上 我输入的是5元,表示我要给对方某某转账5元,结果在http传递过程中,被人劫取并窜改成了 10000元,而且入账对象改成了“黑客”的账号,那不是亏大发了,思考了一下,应该有2种方案解决这个问题,

方案一:走https,这个就不多说,比较公认的安全机制;

方案二:走数字签名,实现原理如下:

一个http请求,假如需要传递如下3个参数

参数名1=参数值1

参数名2=参数值2

参数名3=参数值3

我们可以再追加一个参数,该参数的名为 identity_key (名字是什么不重要),该参数的值为 前几个参数值按顺序相加,再加密后的结果。

即:

identity_key = md5(‘参数值1‘ + ‘参数值2‘ + ‘参数值3‘ + ‘加密密钥‘);

于是,最终传递的参数有:

参数名1=参数值1

参数名2=参数值2

参数名3=参数值3

client_id=client_id值

identity_key=md5(‘参数值1‘ + ‘参数值2‘ + ‘参数值3‘+ ‘client_id值‘ + ‘加密密钥‘)

服务端接到参数后,再按相同的加密规则重新生成一份 identity_key,服务端的identity_key和客户端的identity_key 进行校对,如果不相等,表示被窜改过,接下来怎么操作,自己看着办吧!

时间: 2024-12-09 00:14:58

移动端与PHP服务端接口通信流程设计(增强版)的相关文章

移动端与服务端通信流程设计

转自:http://blog.snsgou.com/post-766.html 针对 --->非开放性平台 --->公司内部产品 接口特点汇总: 1.因为是非开放性的,所以所有的接口都是封闭的,只对公司内部的产品有效: 2.因为是非开放性的,所以OAuth那套协议是行不通的,因为没有中间用户的授权过程: 3.有点接口需要用户登录才能访问: 4.有点接口不需要用户登录就可访问: 针对以上特点,移动端与服务端的通信就需要2把钥匙,即2个token. 第一个token是针对接口的(api_token

api服务端接口安全

api服务端接口安全性解析 http://blog.csdn.net/tenfyguo/article/details/8225279 常用的基于token的实现方案 http://blog.csdn.net/tenfyguo/article/details/8225279 token常常用在各种应用中,如下场景: 1,用户输入密码和帐号后,系统进行验证后,生成一个session,分配一个sessionid给使用者,后续服务使用者就无需每次都输入密码和验证密码了,只需把对应的帐户和session

api服务端接口安全性解析针对

针对 --->非开放性平台 --->公司内部产品 接口特点汇总: 1.因为是非开放性的,所以所有的接口都是封闭的,只对公司内部的产品有效: 2.因为是非开放性的,所以OAuth那套协议是行不通的,因为没有中间用户的授权过程: 3.有点接口需要用户登录才能访问: 4.有点接口不需要用户登录就可访问: 针对以上特点,移动端与服务端的通信就需要2把钥匙,即2个token.第一个token是针对接口的(api_token):第二个token是针对用户的(user_token): 先说第一个token(

基于CXF框架下的SOAP Webservice服务端接口开发

最近对webservice 进行入门学习,网上也是找了很多的学习资料.总得感觉就是这了解点,那了解点.感觉不够系统,不够容易入门.差不多断断续续看了一个星期了,今天小有成果,把客户端,服务端都搞定了.我先写服务端,在说客户端. 框架:服务端webservice是spring+cxf的maven工程. 环境:jdk1.7+maven3.3.9+tomcat7 新建maven工程可以参考我之前的博客:使用eclips创建Maven项目. 1.引入开发的依赖.pom.xml<project xmlns

App架构设计经验谈:服务端接口的设计

转自:http://www.jb51.net/article/60796.htm App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉. 安全机制的设计 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息.实现上,大部分都采用token的认证方式,一般流程是: 用户用密码登录成功后,服务器返回token

SpringMVC 利用HttpPost向服务端接口上传文件

现在Spring的广泛使用使得以前我们在做文件上传的不需要对数据进行转码传输,MultipartEntity内封装了各种方法,我们可以直接在客户端实例化 MultipartEntity类将需要上传的文件以参数的形式写入HttpPost的Entity,这样类似与在前端使用form表单提交来实现文件上传,区别是前端我们是在form里面设定enctype="multipart/form-data"这个参数.废话不多说,下面是代码: 首先是客户端: import java.io.File; i

API开发第四篇:定义客户端/服务端接口协议

在进行API开发的时候,需要事先定义好app与server交互的数据格式,这样前端人员与服务端人员才能够事先决定好如何获取数据.如何解析数据.如何传输协议. 在我看来目前接口协议无外乎这三种情况: 1. json数据进行交互 2. xml数据进行交互 3. 自定义数据格式交互 自定义数据格式进行前后端的数据交互,需要花费较大的精力,而且需要很有经验的人设计的协议才会确保各个平台的兼容以及良好的可阅读性.并且解析.封装都需要自己来用代码实现,很多第三方库都没办法用上.因为这里我不进行讨论.主要说说

后台服务端接口验证项目实例~~

前言: 在当前开放互联的大环境下,接口互通成了最最普通常见数据通讯与交互的一种方式:接口测试的重要性也是不言而喻,但却成了普通功能测试人员的一道屏障:特别是服务端的接口验证更是麻烦:这里抛砖引玉希望更多童鞋参与多多讨论. 场景&描述: c1->s1->s2 s1 <-s2 协议:http c端,发起c1(pay)请求,服务端处理完毕,通过s1接口把(pay)请求支付接口告诉指定s2服务地址:s2服务地址解析s1接口内容,正常返回SUCCESS,异常返回FAILURE;s1收到s2

手机app服务端接口开发启示随手记1

第一个情景,原来登录注册更新用户资料是分开的3个接口,那么容易想到的是注册之后不更新资料,但是又登录了的(修改资料当然需要登录).根据墨菲定律,凡是可能会出问题的地方则迟早出现问题.果然产品上线3个月后数据库出现了几百条仅仅注册但是没有更新资料但登录了的用户.更要命的是,这些用户的资料随着一些业务逻辑线进入了solr,污染了附近用户相关的业务的数据导致周围的人以及查询出现空白资料的用户. 第二个情景,因为用户编辑广播消息或者图文资料的时候对图文的存储没有依照惯例进行处理也就是text中插入标记,