我觉得我错过了什么。我正在尝试定制我的产品 UI，以便某些项目仅向管理员显示。此外，限制对路由器中某些"页面"的访问需要同步呼叫保护。我当然更愿意保持异步，但这似乎不符合要求。
在其他环境中，我会创建一个布尔函数，如isAdmin()来检查用户授权/角色。但是，由于出于安全原因，用户不应看到该功能的实现，因此最好使用仅限服务器的 Meteor 方法。尽管该方法可以在客户端上同步(如果未指定回调)，但获取返回值的唯一方法是使用 Meteor.call() 的异步回调形式。
似乎有三种方法可以解决这个问题，没有一种像布尔函数那么简单：
- 从 isAdmin() 返回一个可观察量，但这会把问题推出来 到调用 isAdmin() 的任何地方。它不能解决路由器防护问题。
- 在需要 isAdmin() 的地方做一个 Meteor.call()，丢弃 isAdmin() 函数。这也将问题推到了所有调用 站点，并且不寻址路由器防护。
- 根本不返回值，但让服务器端方法抛出 如果用户不是管理员，则为例外。但是，这不会更改方法调用的异步性质。
我见过使用 Meteor.wrapAsync 或 Future 的例子，但这些示例在服务器上使用 Fibers，而不是客户端。
对其他模式的任何其他建议，也许使用 rxjs？谢谢。
我想我不了解您的整体安全策略，但这里有几件事需要考虑。
安全性发生在服务器上，看起来您很清楚这一点。
在我当前的项目中，我们使用角色(alanning：roles)，并有几个管理员角色。 这些角色是与 Meteor.user 对象一起发布的，因此在客户端上，我们可以通过检查来启用/禁用指向页面的链接。
所以我们同意这样做并不是真正的安全，因为用户可以简单地导航到该链接或更改他们的客户端 Meteor.user 对象以公开它。
但是在该页面上，我们可能会访问仅限管理员的数据。 由于我们在服务器上处理发布，我们可以在其中实际检查这些管理员角色，因此我们可以检测非管理员用户访问权限并引发错误。
同样，如果我们向用户发布数据，并且他们获得的项目基于角色，我们可以在发布中检查这一点，并仅发布允许他们查看的项目。 限制这些已发布项目的字段的想法相同。
对于您关于"检查角色的客户端代码是什么样子的？"的问题，它实际上只不过是查询 Meteor.user 上"角色"字段的内容。 因此，虽然它确实给了他们一个关于存在哪些角色以及应用程序如何使用它们以获得可见性的提示，但恕我直言，它并没有提供恶作剧的途径。 只要他们无法访问任何受限制的数据， 或成功执行任何受限制的调用，它是安全的。
因此，对于我们的每个发布者和 Meteor 方法，我们都有大量的错误检查，包括角色(管理员和其他)。 如果有任何不对齐的内容，我们会抛出错误。