标签：短信接口 fastcgi 客户端 数据库 脏读 验证码 应用 生成 设置
最近被人恶意刷接口了,发现的时候一万多条短信已经被刷完,当时天真的以为第三方会帮忙搞定安全方面的事情,为了限制这个事情,加了一个很简单的逻辑:
这两点当然不够,因为完全可以一边刷图形验证码的状态(不断将可调用手机短信验证的状态设为真),再调用短信接口,同样可以恶意刷接口.
所以加上第三点:
3. 加入图形验证码的有效状态,每次生成时设为真.当验证后(不管正误)都设为假.
这样就保证了用户无法通过简单的程序来刷接口.要避免这种事情,后台验证逻辑的设计以及接口的设计都要考虑到.
websocket
大概1,2个月前,用workman实现了服务器往客户端推送的功能,最基本的应用.大概设计了一下如何往指定用户推送信息.得给每个链接到服务器的客户端设置一个唯一的key,或者说id,推送信息时可以根据这个id来推送.
大概是做了一大堆业务吧,没啥时间系统的学新技术.
大概了解了一下数据库的底层,mysql的四个隔离级别,读未提交,读已提交,可重复读,最后一个忘了,貌似是解决了幻读的问题.脏读是存在第一个隔离级别的问题,现在mysql的默认是可重复读这个级别.牵涉到的锁还没深入去了解.
fpm,web服务容器,fastcgi,cgi协议也只是懂个大概,sad.
标签：短信接口 fastcgi 客户端 数据库 脏读 验证码 应用 生成 设置
原文地址：http://www.cnblogs.com/josefa/p/7216857.html
