通用接口开放平台设计与实现——（26）消息服务之安全增强

场景

我们对于消息服务这块的整体设计是客户端连接服务端后，发起身份认证，携带应用编码和密钥，并对密钥进行了hash加密，服务端认证通过后，建立长连接。

对于长连接，我们认为是安全，恶意用户无法直接往长连接通道中发送一条伪造的消息，因此没有必要对每条消息进行签名和验签，从而提升了性能。但这里还有一个小漏洞，未认证的应用是防住了，已认证的应用如果进行一些越权操作如何应对呢？

例如，物流系统LMS对接了两个承运商的TMS系统，如果A承运商系统，发送了一条消息确认，但消息中携带的应用编码是B的，实际发生这种情况的可能性不大，但是还是有一定隐患的。。

方案

该问题的关键出在，我们识别应用，使用的消息中携带的应用编码，而不是登录认证成功后连接中保存的应用编码。

有两种方案，一是在使用应用编码的地方，从连接通道中获取登录成功时保存的应用标识值，二是在数据验证环节，验证下客户端消息携带的应用编码与通道中的应用编码是否一致就行了。

综合考虑下，方案1从通道中获取应用编码，在很多使用应用编码的方法中，需要额外获取到通道这个对象才行，比较麻烦；方案2比较便利，只做一点小变动就行了，因此我们采用方案2.

具体实现

相关改造如下：
因为只有服务端需要验证应用编码与消息通道是否一致，因此不能放到客户端和服务端公用的基本数据验证处理中，而是放到了服务端的MessageHandler中，在应用验证环节，比对消息中携带的应用编码与