三,安全与签名、玩转聊天室和临时对话
本章导读
在前一篇消息收发的更多方式,离线推送与消息同步,多设备登录中,我们演示了与消息相关的更多特殊需求的实现方法,现在,我们会更进一步,从系统安全和成员权限管理的角度,给大家详细说明:
- 如何通过第三方鉴权来控制客户端登录与操作
- 如何对成员权限进行限制,以保证聊天流程能被运营人员很好管理起来
- 如何实现一个不限人数的直播聊天室
- 如何对大型群聊中的消息进行实时内容过滤
- 如何使用临时对话
安全与签名
即时通讯服务有一大特色就是让应用账户系统和聊天服务解耦,终端用户只需要登录应用账户系统就可以直接使用即时通讯服务,同时从系统安全角度出发,我们还提供了第三方操作签名的机制来保证聊天通道的安全性。
该机制的工作架构是,在客户端和即时通讯云端之间,增加应用自己的鉴权服务器(也就是即时通讯服务之外的「第三方」),在客户端开始一些有安全风险的操作命令(如登录聊天服务、建立对话、加入群组、邀请他人等)之前,先通过鉴权服务器获取签名,之后即时通讯云端会依据它和第三方鉴权服务之间的协议来验证该签名,只有附带有效签名的请求才会被执行,非法请求全部会被阻止下来。
使用操作签名可以保证聊天通道的安全,这一功能默认是关闭的,可以在 开发者中心 > 你的游戏 > 游戏服务 > 云服务 > 即时通讯 > 设置 > 即时通讯设置 中进行开启:
- 登录启用签名认证,用于控制所有的用户登录
- 对话操作启用签名认证,用于控制新建或加入对话、邀请/踢出对话成员等操作
- 聊天记录查询启用签名认证,用于控制聊天记录查询操作
开发者可根据实际需要进行选择。一般来说,登录认证 是最基本的安全机制,我们强烈建议开发者开启登录认证。
- 客户端进行登录或新建对话等操作,SDK 会调用
SignatureFactory
的实现,并携带用户信息和用户行为(登录、新建对话或群组操作)请求签名; - 应用自有的权限系统,或应用在云引擎上的签名程序收到请求,进行权限验证,如果通过则利用下文所述的 签名算法 生成时间戳、随机字符串和签名返回给客户端;
- 客户端获得签名后,编码到请求中,发给即时通讯服务器;
- 即时通讯服务器对请求的内容和签名做一遍验证,确认这个操作是被应用服务器允许的,进而执行后续的实际操作。
签名采用 HMAC-SHA1 算法,输出字节流的十六进制字符串(hex dump)。针对不同的请求,开发者需要拼装不同组合的字符串,加上 UTC timestamp 以及随机字符串作为签名的消息(参见后续格式说明)。总体上,签名就是使用特定的密钥(在这里我们使用应用的 Master Key
),对输入的消息(即「签名的消息」)进行哈希计算,得到一串十六进制的字符串,这就是最终的「签名」。
对于使用 LCUser
的应用,可使用 REST API 获取登录签名进行登录认证。
签名格式说明
下面我们详细说明一下不同操作的签名消息格式。
用户登录签名
签名的消息格式如下,注意 clientid
与 timestamp
之间是两个冒号:
appid:clientid::timestamp:nonce
参数 | 说明 |
---|---|
appid | 应用的 ID。 |
clientid | 登录时使用的 clientId 。 |
timestamp | 当前的 UTC 时间距离 Unix epoch 的 毫秒数。 |
nonce | 随机字符串。 |
注意:签名的 key 必须 是应用的
Master Key
,你可以在 开发者中心 > 你的游戏 > 游戏服务 > 应用配置 里找到。请保护好 Master Key,不要泄露给任何无关人员。
开发者可以实现自己的 SignatureFactory
,调用远程服务器的签名接口获得签名。如果你没有自己的服务器,可以直接在云引擎上通过 网站托管 来实现自己的签名接口。在移动应用中直接进行签名的做法 非常危险,它可能导致你的 Master Key 泄漏。
签名的有效期是 6 个小时,强制下线后签名立即失效。 签名失效不影响当前在线的 client。