Swift SDK，关于开发版的实时通信的权限管理，我总结一下请大家补充

[Rxswift]

文档中有一句话“登录认证能满足大部分安全需求”。我试了代码，发现绝大部分安全需求不能满足，请大家指点。以下是基于使用Swift SDK，开发版没有在控制台开启角色管理（收费），但是已经开启或没开启签名，权限管理只在实时通信框架内。

我先定义一下“高级权限”：查询App里全部对话、修改任意对话的属性，查询任意对话的全部聊天记录，在任意对话里发消息，删除任何对话的成员，这里说的任意对话包括不是自己创建的对话。“开启签名”：开启对话的登陆签名，对话操作签名。

1_Conversation的ACL在任何情况下不起作用，也就是说，不管如何设置_Conversation表的ACL，任何用户都有“高级权限”，比如上述查询全部对话，随意修改别人对话属性，随意查询任何对话的全部聊天记录，删除任意对话成员的功能，以下简称“高级权限功能”。开启签名后，具有签名的用户都具有高级权限，即任意一个签名用户可以随意修改任意对话属性，查询全部对话，删除别人建立的对话里面的成员、在别人建立的对话里面发消息（不请自来）等高级权限功能。

2._Conversation记录创建对话后，用户无法删除，只能开发者在控制台删除对话，这一点非常好，一个用户退出对话，不影响对话里其他成员继续正常使用。

3.对话中的消息：聊天记录，虽然任何人都能查询（开通签名后，有签名的所有用户可以查询）全部对话的全部消息，但不能删除或修改别人发的消息，只能修改或撤回自己发的消息。这一点是不错的权限管理。

4.理论上聊天记录对所有使用者透明，开发者可以在后台，非开发者可以在客户端查询App里全部对话的全部聊天消息，不是自己创建的对话也能查消息。开启签名后，所有聊天记录，包括不是自己创建的对话的聊天记录，对所有签名用户透明。

5.不是自己创建的对话，用户可以通过主动加入对话的方式拥有高级权限，主动加入某一对话不受限制。开启签名后，有签名的用户可以主动加入任意对话从而拥有高级权限（所有签名用户主动加入任意对话不受限制）。

6._Conversation里的对话记录长期有效，但对话里的消息保存期是6个月。

7_Conversation里面的对话，创建者一列永远不变，用户发消息不会改变_Conversation里的updateAt日期，只有属性的更改才会更新updateAt日期

8.能查询到对话，就能查询到对话的全部聊天记录，不是对话成员可以通过主动加入对话的方式具有这一能力，因为主动加入对话是不受限制的，查询全部对话当然也更不受限制，签名后，所有签名用户可以查询全部对话，主动加入任意对话获取全部聊天记录。登录认证并不能满足大部分安全需求，只能把没有签名的用户挡住，有签名的用户可以查询全部对话列表（不受限制），主动加入任意对话（不受限制），查看全部对话的全部聊天记录、修改对话属性（也就不受限制了）

9.签名只能挡住没签名的，有签名用户的可以拥有高级权限，包括去别人建立的任意对话里发消息等等

[Rxswift]

实现高级权限的代码 ：
1.查询全部对话 可以采用基础条件查询。为了防止用户无意间拉取到所有的对话数据，在客户端不指定任何 where 条件的时候，ConversationQuery 会默认查询包含当前用户的对话。但是如果客户端添加了任一 where 条件，那么 ConversationQuery 会忽略默认条件而严格按照指定的条件来查询。使用equalTo然后notEqualTo，即可查询App里包含和不包含当前用户的全部对话。

do {
let conversationQuery = tom.conversationQuery
try conversationQuery.where("attr.type", .equalTo("private"))
try conversationQuery.findConversations { (result) in
switch result {
case .success(value: let conversations):
print(conversations)
case .failure(error: let error):
print(error)
}
}
} catch {
print(error)
}

//然后:
do {
let conversationQuery = tom.conversationQuery
try conversationQuery.where("attr.type", . notEqualTo("private"))
try conversationQuery.findConversations { (result) in
switch result {
case .success(value: let conversations):
print(conversations)
case .failure(error: let error):
print(error)
}
}
} catch {
print(error)
}

[Rxswift]

2 获取对话列表后，用户主动加入对话（不受限制），获取最高权限

把 Mary 踢走之后，Tom 嫌人少不好玩，所以他找到了 William，说他和 Jerry 有一个很好玩的聊天群，并且把群的 ID（或名称）告知给了 William。William 也很想进入这个群看看他们究竟在聊什么，他自己主动加入了对话：

do {
let conversationQuery = client.conversationQuery
try conversationQuery.getConversation(by: "CONVERSATION_ID") { (result) in
switch result {
case .success(value: let conversation):
do {
try conversation.join(completion: { (result) in
switch result {
case .success:
break
case .failure(error: let error):
print(error)
}
})
} catch {
print(error)
}
case .failure(error: let error):
print(error)
}
}
} catch {
print(error)
}

[Rxswift]

3.主动加入对话后，修改任意对话属性（开通签名后，则所有签名用户可以主动加入任一对话）
在 Conversation 对象中，系统默认提供的属性，例如对话的名字（name），如果业务层没有限制（只使用实时通信范围的功能，无法限制）的话，所有成员都是可以修改的，示例代码如下：

do {
try conversation.update(attribution: ["name": "聪明的喵星人"], completion: { (result) in
switch result {
case .success:
break
case .failure(error: let error):
print(error)
}
})
} catch {
print(error)
}

[Rxswift]

4.主动加入对话后，拉取全部聊天记录（开通签名后，有签名的用户可以主动进入任意对话（这一点不受限制）从而拉取全部聊天记录）
do {
try conversation.queryMessage(limit: 10) { (result) in
switch result {
case .success(value: let messages):
print(messages)
case .failure(error: let error):
print(error)
}
}
} catch {
print(error)
}

[Rxswift]

5.任何人主动加入对话后，删除对话的成员，启动签名后，有签名的用户可以随意加入任何对话从而删除对话的成员：

三个好友的群其乐融融不久，后来 Mary 出言不逊，惹恼了群主 Tom，Tom 直接把 Mary 踢出了对话群。Tom 端想要踢人，该怎么实现呢？
+

do {
try conversation.remove(members: ["Mary"], completion: { (result) in
switch result {
case .allSucceeded:
break
case .failure(error: let error):
print(error)
case let .slicing(success: succeededIDs, failure: failures):
if let succeededIDs = succeededIDs {
print(succeededIDs)
}
for (failedIDs, error) in failures {
print(failedIDs)
print(error)
}
}
})
} catch {
print(error)
}

[ylgrgyq]

辛苦总结这么多。首先需要说明一下的是，说登录签名能解决大部分安全问题确实不太严谨。应该说是登录签名能解决基本的安全问题，配合对话签名、Hook 后才能解决大部分安全问题。我们会将描述修改一下。

您总结出来的很多权限相关问题实际均需要对话签名来解决。对话相关签名是将对话内权限管理交给用户来做，修改对话属性、踢人、加人等操作均有独立的签名，用户需要在颁发签名时判断申请签名的 client 是否有权限做某个操作，有权限则颁发签名，没权限则不颁发签名。从而实现对话权限管理机制。比如对话内用户 Tom 想要删除一个对话内成员，如果对话签名开启了，则 Tom 需要先申请签名，用户用于颁发签名的逻辑那里需要去判断 Tom 是否有权限去在这个对话内删除成员，有权限则允许，否则不允许。

如果认为通过签名机制来管理对话权限过于复杂，则可以考虑使用付费的角色管理机制。

如果前提是只开启登录签名，则您总结的很全面了。

[Hahn]

呵呵，关于第三点，有什么好的？
本来还有些需求就是要修改别人的消息来实现，就因为这个限制导致做不了。
例如我这边本来想实现一个单方删除消息功能，类似qq微信一样，删除某条消息相当于自己不想看，但别人那边还是能看，打算写到消息里的属性中的，就因为这所谓的限制。。。。而官方竟然也不提供这个这么常见的功能的解决方案。。。。。