api服务端接口安全

api服务端接口安全性解析

http://blog.csdn.net/tenfyguo/article/details/8225279

常用的基于token的实现方案

http://blog.csdn.net/tenfyguo/article/details/8225279

token常常用在各种应用中,如下场景:

1,用户输入密码和帐号后,系统进行验证后,生成一个session,分配一个sessionid给使用者,后续服务使用者就无需每次都输入密码和验证密码了,只需把对应的帐户和sessionid带上即可,后端只需进行高效的sessionid的有效性校验即可。解决了关键接口或者敏感接口的多次调用,并且对sessionid的有效期等可以进行管理。

2,用户授权中使用,用户输入支付密码后,代表用户已经授权了,这时候系统自动生成一个长度比较长的token串返回给服务使用者,后续进行扣款的时候,则进行验证该token串的合法性即可,注意该串需要保证一定的长度,一次性有效,并且较短的有效期等特点。

3,在开放平台中,对外外部站点的授权服务,用户授权后,同样可以给外部站点发放一个token,后续访问服务的时候,带上该token即可,避免每次均需要进行授权。

4,引申出来的应用,在一个隔离的串行服务调用中,用户完成第一步需要进行一系列的接口调用,然后得出用户是否有权限或者资格进行参加某项服务,接下来,用户调用第二步,而第二步为了安全起见,仍然需要执行第一步的一系列接口调用,这种方式下,可以在第一步合格的用户系统颁发一个token,该token是一次性有效的,实现上,可以在第一次生成一条记录,以用户帐户和token一起为key,第二次进行update该记录来判断。这样的好处是防止两步的调用被隔离带来的风险。

比如我们系统随机抽奖后给用户出现一个提示,告诉他已经中奖了,这个时候用户需要领取才能拿到奖,则可以在第一次给颁发一个token,领奖的时候把token带上进行验证即可。

时间: 2024-11-03 22:51:20

api服务端接口安全的相关文章

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

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

移动端与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 添加时间(戳) (注:只列出了核心字段,其它的再扩展吧!!!) 授权表 字段名 字

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

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

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

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

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

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

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

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

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

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

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

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

POSTMAN测试SpringMVC RESTFul风格的服务端接口始终得不到值

后台接口中接收参数使用DataObject(包含一个String类型的属性data)     ServletRequestDataBinder binder = new ServletRequestDataBinder(new DataObject());     binder.bind(request); 然后再POSTMAN中使用如图的方式传参: 可以发现得到的返回值是null,而且根据后台调试,确实没有得到传入的参数.切回x-www-form-urlencoded模式下然后将此对象用如下方