我在Meteor.users集合中具有扩展用户模型，我将大多数字段发布到客户端。每个用户都有一个isAdmin字段，默认情况下设置为false。
现在我有两个担忧，它们是相互关联的：
-
如何确保，如果
Meteor.users集合中的isAdmin字段设置为true，则只能呈现用于管理员的组件？ -
如何确保无法从客户端控制台修改
Meteor.users集合上的isAdmin字段？
关于1.
我犹豫是否要将此字段发布给客户端，只需在客户端评估isAdmin。
我不确定是否有一些通过控制台的黑客方式简单地更改isAdmin，以允许渲染仅适用于客户端管理员的组件(或部分组件)。例如，我可以想象Object.defineProperty()可以这样做。
我应该使用
server-side rendering来保护 UI 的管理部分吗？
关于2.
考虑本文中关于常见错误的配置文件编辑的第一段。它表明可以通过从控制台调用Meteor.users.update(Meteor.userId(), {$set: {'isAdmin': true}})轻松地从客户端更改isAdmin。
当我运行它时，登录到我的应用程序，我得到了update failed: Access denied。
但即使是官方文档仍然建议添加
// Deny all client-side updates on the Lists collection
Lists.deny({
insert() { return true; },
update() { return true; },
remove() { return true; },
});
在 https://guide.meteor.com/security.html#allow-deny
有一个答案，建议在服务器端简单地检查isAdmin属性就足够了，如果你确保Meteor.methods是仅限服务器的。但它根本不谈论allow-deny，而且它已经 6 岁了。
谁能说出，今天到底是什么情况？
谁能说出，今天到底是什么情况？
我不会花太多精力来保护客户端上的管理员 UI。当isAdmin为 false 时，路由器级别重定向就足够了。
这里更重要的是保护方法和发布，因为这些是用户可以弄乱应用程序的部分。对于那些不够安全的人来说：
- 将
mdg:validated-methods中的ValidatedMethod用于方法 - 编写一个工厂函数来创建类似于
mdg:validated-method的发布，以允许以 mixin 样式进行基本检查 - 两者：检查参数是否有效
- 两者：检查用户是否存在
- 两者：检查用户是否有足够的角色 ->我重新评论
alanning:roles因为它使权限级别检查更安全，因为它检查专用集合中是否存在 id-match，而不是检查用户集合中的标志(此外，它将用户与角色分离！ - 快速和大量投掷：抛出任何可疑的不一致，尝试用投掷错误覆盖任何未定义的状态。
- 使用
ddp-rate-limiter每种方法和出版物的速率限制 - 在启动时编写一个简单的健全性检查，以确保所有方法和发布都受到速率限制，您可以通过
Meteor.server.method_handlers和Meteor.server.publish_handlersMeteor.startup服务器上获取所有注册的方法/发布 - 编写大量测试，特别是对于与管理员相关的方法，并尝试您能想到的任何奇怪和疯狂的输入，看看它是否被拒绝或导致任何奇怪的行为(您想要避免)
据我了解您的问题，您目前尚未集成 ssr，如果您按照上述步骤操作，您可以在很大程度上保护您的应用程序管理区域，而无需将 ssr 包含在您的应用程序中(由于额外的配置等，这本身会引起很多头痛)。
*如果您决定使用推荐的alanning:roles包，则最好在客户端上使用它来检查用户的角色。