收发信-PHP

php  - @amazeUI  - 2016-11-17 15:01:38

收发信：做了一个基础类，里面有各种判断和对数据的处理还有当前用户的id，这里不予显示，只做总逻辑总结。只有元宝发信和免费发信，元宝发信则打通通道无限次与对方一对一的交流。免费发信则取决于对方看不看信和有没有权利看信，分为信件的两种状态。基本形成了一个闭环。只有信箱中拆信会将与此用户的所有聊天记录调出来。

先看一个拆信和发信都需要用到的一个方法，很简单但设计得很巧妙

public function checkPay($needPay,$userid,$status,$isVip){//检查用户有无权利拆信和用户付费发信的一个方法.needpay信件状态，status供支付模块使用

顺序1，根据isvip查看是否为vip，是返回true

顺序2，判断有无通道，是返回true

顺序3，如果needPay为自己支付并且调用支付模块，支付成功后返回true,就开通通道返回true,

顺序4，返回false.

}

从这里开始.

拆信：传进来与对方来往的最后一封信件id,对方id,和状态。对方id是保证数据合法性，单单只要信件id安全度是不够的。

public function showMsg($id,$userid,$boxstatus){

$meg = 根据$id查这一封信件;

$user = 根据$userid查询对方用户;

$userstatus = 根据$meg可以查出收信人和发信人，再与$userid进行对比，如果$userid既不是收信人也不是发信人，就返回false,否则返回true;

$megid = 根据$userid查看自己是否跟对方有过信件往来，如果有返回信件id，如果没有返回false;

//再就开始判断，其实上面可以做很多的if，可以减少很多不必要的查询，但是代码就会很丑了。

if(如果$meg不存在或者$user不存在或者与对方没有过信件来往或者有过信件来往但是最后一封信件和传过来的$id对应不上或者$userstatus等于false){

视为都不合法，最好是删除用户session退出登录。

}

//此时走到这里来说明数据全部合法。可以做正常流程判断.

if($meg的发送者不是自己){

之前做了一个公共函数(判断顺序为是否为会员，是否有通道，如果选择付费就走付费，并开通    通道，开通通道完成后返回true,返回false)就是上面的checkPay，拆信和发信都能公用只要一个状态，这里调用,传    入信件状态用户，是拆信还是发信，和vip标识。返回的如果是false,对于程序来说说明前三个        条件都没通过，走的是最后一个false。对于用户来讲，说明有人发了一封免费信件给自己，而    自己不是会员，跟他又没有通道，且自己不愿意付费查看此封信件，此时给用户跳到充值页面去。

}

走过了以上两个if判断，即可视为用户有权查看信件，把所有聊天记录调出来显示就可以了。

}

//发信逻辑整理

//ajax提交的信息，前台提交有两种状态，第一种为付费发信，第二种为免费发信

public function sendMsg(){

获取到前台提交的数据，做基本数组拼接。检查有没有收信者这个用户。检查发信者id是否等于收信者id。

收发信逻辑大部分取决于与当前用户来往的最后一封信件的状态，和自己发出去的信可以查看。这样对于拆信就有一个漏洞了，按照上面拆信的方法来讲最后一封信如果是自己发的话，是可以拆信的。现在假设用户1在无会员无通道的情况下，向用户2免费发了一封信件，此时最后一封信件为用户1发的，用户1可以看信，用户2如果不是会员且不愿意付费看信的话是看不了信的，但是项目中发信渠道能发信除了第一次信件的往来。这样拆信和发信完全分离开来具有原子性符合松耦合，并且在我们项目中为了用户的活跃度没做太多限制)。但是用户2可以这样做，比如说在用户列表里面打招呼，打招呼的页面是不显示用户聊天记录的，不需要拆信就能进行打招呼。此时与该用户来往的最后一封信件就成了自己所发出去的了，刚好我们基于最后一封信件来判断他是可以拆信的，所以他能看到聊天记录能看到本不该属于他看到的内容。收发信模块早在两个月前我就做完了，也经过了重重验收，但在    前两个星期，翻代码看层层逻辑的时候，发现了有可能会出现这种情况，经过测试后，真的是有这个漏洞，然后我就偷偷的修改代码。

堵住这个口子的逻辑是这样的，查出与该用户的最后一封信件id，如果这个id存在，则查出这封信，再进行判断，如果这封信需要付费，并且本次发信的状态也是免费发信，并且信件的接收者等于本次信件的发信者，并且经过会员验证通道验证没通过的话，就说明这个人想作弊，直接给退出登录。这里可能会想验证前两个就够了，为什么还要验证会员和通道，是这样的，对于发信来说，我们只有免费发信和付费发信，并没有会员发信和通道发信，避免用户看得眼花缭乱，即使是用户是会员或者有通道，他们点免费发信，这封信件的状态还是会让对方免费查看。哪怕即使用户是会员或者有通道他们点付费看信，其实程序也不会扣除他的余额，信件状态还是会让对方免费查看。当然我们会在页面上隐藏掉用户不该看到的东西。下面的代码就是这样的。

//走到这里说明所有验证都成功了，数据正常。

if(发信者选择的是免费发信){

调用checkPay看是否为会员和有通道，返回的是false,则此封信件的状态为对方需要权限看信。然后添加进数据库。如果是true则说明他是会员或者又通道。状态改为对方可以免费看信。其实在这里用户点了免费发信，且自己是会员或者有通道，对方也能免费看信，从而实现会员和通道的特权。

}

//走到了这里就说明只剩下自己付费发信了，用户选择的是付费发信

将此封信件的支付状态先置为对方需要权利查看此信件。再次调用checkPay，如果返回的是false说明支付失败余额不足，如果返回的是true,则说明是会员或者有通道，信件状态改为对方可以免费看信，添加进数据库。

}

        以上就是整个收发信的核心逻辑。若以上所述有漏洞，或可以更好的处理，望和我联系，一起学习探讨和交流。