Mysql 如何处理本地客户端上的权限更改

我构建了一个SaaS系统，允许多个用户在共享的在线数据库上协作。中央服务器维护数据库。用户使用其移动设备登录和访问数据。每个移动设备都有自己的数据库本地副本，定期更新：如果用户进行了一些更改，则更新源于用户设备到服务器（提交），其他更新源于其他人提交时的服务器（推送更新）

每个数据库条目都由一个全局唯一ID标识。移动客户端可以在脱机时生成其数据库条目，因为ID是随机生成的（128位随机uuid）。不需要中心实体来分配标识符，因此移动客户端可以在完全脱机时随意生成数据库条目，而不会与其余数据发生任何ID冲突

该系统非常健壮且容错：我将底层RESTAPI设计为幂等，因此重复的POST请求只影响数据库一次

现在我面临的大问题是：

基本上，我正准备实现系统中最大的、人们期待已久的缺失功能：权限

特殊管理员用户决定哪个用户可以查看哪个数据库条目。用户和条目之间存在多对多关系，因此我添加了一个额外的表来编码可见性标志：

表格“用户条目”

例如，用户13只能访问条目“b89eaac…”，用户14只能访问条目“bfd2804…”，用户15只能访问条目“e4fa155…”，“eb368a2…”和“bfd280436…”

到目前为止还不错

问题是：在任何给定时间，用户的移动设备都会保留数据库的完整副本。如果管理员决定用户X不能再看到数据库条目Y，我如何在数据库的本地副本上反映这一点

我提出了一系列可能的解决方案，但没有一个听起来令我满意：

解决方案1-只需像往常一样在本地设备上反映数据库

基本上我做了我目前正在做的事情：在数据库的本地副本上反映更改。访问权限表“userentry”的本地副本反映在本地数据库上（毕竟，即使该表也是数据库的一部分）。界面将仅显示允许用户访问的条目

优点：实现起来再简单不过了

缺点：未经授权的条目实际上一直存储在本地副本上，即使界面没有向用户显示它们

解决方案2-与解决方案1相同，而且服务器不会推送未经授权的内容

与选项1类似，本地副本保留权限表。不过这一次，服务器不会将未经授权的内容推送到客户端

优点：实现起来仍然很简单，只需在将内容推送到客户端之前对数据库进行一次小检查

缺点：无法安全地撤销以前授权的内容（即，管理员用户决定用户X再也看不到内容Y：内容Y从界面上“消失”，但仍在数据库的本地副本上）

解决方案3-作为解决方案2，并主动删除本地副本上仍然存在的未经授权内容

+------------+------------------------------------------+
| user_id    | entry_id                                 |
+------------+------------------------------------------+
|         13 | b89eaac7e61417341b710b727768294d0e6a277b |
|         14 | bfd280436f45fa38eaacac3b00518f2961a44313 |
|         15 | e4fa1555ad877bf0ec455483371867200eee8955 |
|         15 | eb368a2dfd38b405f014118c7d9747fcc97f4f0e |
|         15 | bfd280436f45fa38eaacac3b00518f2932432443 |
+------------+------------------------------------------+

与解决方案2相同，但这次将从本地副本中硬删除任何“剩余”条目。基本上，解决方案3实现了缺少的撤销功能

优点：用户设备上不会存储未经授权的内容

缺点：听起来很混乱，因为我们必须硬删除本地副本上的条目。如果用户脱机工作很长一段时间后更改了不再允许访问的数据，该怎么办？服务器将突然推送“删除”，用户可能会丢失一些工作

编辑：

IMHO最明智的方法似乎是解决方案2（不要推未经授权的东西，也不要撤销本地的东西）。这就是理由：如果用户过去可以访问某个条目，那么该条目是否仍然存储在数据库的本地副本中（尽管不可见）真的很重要吗？在我看来，这不是一个安全问题

编辑：

我可以放弃客户端的“脱机模式”特性，完全删除本地数据库的概念，让客户端通过共享数据库上的RESTAPI进行操作。不再提交、不再推送更新、即时权限更新。但是我觉得有点晚了，因为用户很清楚他们可以在离线时使用客户端，我不能再删除这个功能了

编辑：

请注意，用户在同一组织/公司内共享数据库数据