Meteor：SSR 是保护应用程序管理部分所必需的吗？
Meteor: SSR necessary to secure admin part of application?
我在 Meteor.users 集合中有我的扩展用户模型，我从中向客户端发布大部分字段。每个用户都有一个 isAdmin 字段，默认设置为 false。
现在我有两个问题，它们是相互关联的：
How to make sure, components meant for admins can only be rendered, if the isAdmin field in the Meteor.users collection is set to true?
How to make sure, the isAdmin field on the Meteor.users collection cannot be modified from the clients console?
关于 1.
我犹豫要不要向客户端发布这个字段，只是在客户端评估isAdmin。
我不确定是否有一些 hackish 方式通过控制台简单地更改 isAdmin 以允许呈现仅供管理员使用的组件（或其一部分） 客户。例如，我可以想象 Object.defineProperty() 可以这样做。
Should I use server-side rendering to secure the admin part of my UI?
关于 2.
请考虑此 article 中有关 个人资料编辑 的第一段关于常见错误的内容。它表明可以通过从控制台调用 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
有一个 answer，这表明只要确保 Meteor.methods 在服务器端检查 isAdmin 属性 就足够了仅限服务器。但它根本不谈论allow-deny而且它已经6岁了。
Can anyone tell, what truly is the case as of today?
Can anyone tell, what truly is the case as of today?
我不会花太多精力来保护客户端上的管理员 ui。当 isAdmin 为 false 时路由器级重定向就足够了。*
这里更重要的是保护方法和出版物，因为用户可以在这些部分乱搞您的应用程序。对于那些不够安全的人：
- 使用
mdg:validated-methods 中的 ValidatedMethod 作为方法
- 编写一个工厂函数来创建类似于
mdg:validated-method 的 Publications 以允许在 mixin-style 中进行基本检查
- 两者：检查参数是否有效
- 两者：检查用户是否存在
- 两者：检查用户是否有足够的角色 -> 我推荐
alanning:roles，因为它使权限级别检查更安全，因为它检查 id-match 是否存在于专用集合中，而不是检查用户集合中的标志（加上它将用户与角色分离！）
- 快速且大量抛出：抛出任何可疑的不一致，尝试用抛出错误覆盖任何未定义的状态。
- 使用
ddp-rate-limiter 每种方法和发布的速率限制
- 在启动时写一个简单的完整性检查，确保所有方法和发布都是 rate-limited，您可以通过
Meteor.server.method_handlers 在 Meteor.startup 的服务器上获得所有已注册的 methods/publications和 Meteor.server.publish_handlers
- 写很多测试，尤其是与管理相关的方法，并尝试任何你能想到的奇怪和疯狂的输入，看看它是否被拒绝或导致任何奇怪的行为（你想避免）
据我了解你的问题，你目前还没有集成 ssr，如果你按照上述步骤操作，你可以在不将 ssr 包含到你的应用程序中的情况下保护你的应用程序的 admin-area（这本身可能会导致由于额外的配置等，很头疼）。
*如果您决定使用推荐的 alanning:roles 包，您最好在客户端也使用它来检查用户的角色。
我在 Meteor.users 集合中有我的扩展用户模型，我从中向客户端发布大部分字段。每个用户都有一个 isAdmin 字段，默认设置为 false。
现在我有两个问题，它们是相互关联的：
How to make sure, components meant for admins can only be rendered, if the
isAdminfield in theMeteor.userscollection is set totrue?How to make sure, the
isAdminfield on theMeteor.userscollection cannot be modified from the clients console?
关于 1.
我犹豫要不要向客户端发布这个字段，只是在客户端评估isAdmin。
我不确定是否有一些 hackish 方式通过控制台简单地更改 isAdmin 以允许呈现仅供管理员使用的组件（或其一部分） 客户。例如，我可以想象 Object.defineProperty() 可以这样做。
Should I use
server-side renderingto secure the admin part of my UI?
关于 2.
请考虑此 article 中有关 个人资料编辑 的第一段关于常见错误的内容。它表明可以通过从控制台调用 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
有一个 answer，这表明只要确保 Meteor.methods 在服务器端检查 isAdmin 属性 就足够了仅限服务器。但它根本不谈论allow-deny而且它已经6岁了。
Can anyone tell, what truly is the case as of today?
Can anyone tell, what truly is the case as of today?
我不会花太多精力来保护客户端上的管理员 ui。当 isAdmin 为 false 时路由器级重定向就足够了。*
这里更重要的是保护方法和出版物，因为用户可以在这些部分乱搞您的应用程序。对于那些不够安全的人：
- 使用
mdg:validated-methods中的ValidatedMethod作为方法 - 编写一个工厂函数来创建类似于
mdg:validated-method的 Publications 以允许在 mixin-style 中进行基本检查
- 两者：检查参数是否有效
- 两者：检查用户是否存在
- 两者：检查用户是否有足够的角色 -> 我推荐
alanning:roles，因为它使权限级别检查更安全，因为它检查 id-match 是否存在于专用集合中，而不是检查用户集合中的标志（加上它将用户与角色分离！） - 快速且大量抛出：抛出任何可疑的不一致，尝试用抛出错误覆盖任何未定义的状态。
- 使用
ddp-rate-limiter每种方法和发布的速率限制 - 在启动时写一个简单的完整性检查，确保所有方法和发布都是 rate-limited，您可以通过
Meteor.server.method_handlers在Meteor.startup的服务器上获得所有已注册的 methods/publications和Meteor.server.publish_handlers - 写很多测试，尤其是与管理相关的方法，并尝试任何你能想到的奇怪和疯狂的输入，看看它是否被拒绝或导致任何奇怪的行为（你想避免）
据我了解你的问题，你目前还没有集成 ssr，如果你按照上述步骤操作，你可以在不将 ssr 包含到你的应用程序中的情况下保护你的应用程序的 admin-area（这本身可能会导致由于额外的配置等，很头疼）。
*如果您决定使用推荐的 alanning:roles 包，您最好在客户端也使用它来检查用户的角色。