34

我们正在考虑用微风js来构建企业应用程序。

微风的美妙之处在于我们可以直接从客户端浏览器执行查询。这允许基于用户输入构建动态查询，而无需加载不必要的数据。我发现，使用 Breeze，我们可以创建业务逻辑，在使用延迟加载策略时将数据传输/传输减少 1/10 甚至更多。使用这样的查询

微风万岁！！！

但是业务逻辑安全呢？例如，我们可以有一个存储库，我们可以在其中隐藏、隐藏和模糊我们的业务逻辑；然后使用 MVC Web API 控制器来调用那些存储库 C# 类。所以 Breeze JavaScript 与 WebAPi 控制器对话，而 WebApi 控制器与 C# 存储库对话。控制器将始终保持非常简单易读，但存储库最终可能会为使用该应用程序的公司提供大量业务逻辑。因此，例如，如果黑客使用 Google Chrome 开发人员的控制台检查 JavaScript 代码，他/她将看到的只有 GetCustomers()、GetProductsForThisId(54) 之类的内容。那里没有太多可以看到（或被盗）的信息。因为 90% 的业务逻辑将存在于服务器上的 C# 存储库中。

微风.js 是如何处理的？

如果我们开始将查询和业务逻辑“从控制器的 C# 转移到轻量级的 JavaScript”，我们必须考虑到我们的系统是基于成员资格的。我认为我们在 JavaScript 中向客户端公开的查询越多，我们的软件就越容易受到攻击，我们就越会告诉黑客如何破解我们的网站并可能窃取信息。

4

3 回答 3

44

安全是一个至关重要的问题。仔细考虑客户端上暴露的数据和逻辑是明智的。我们如何将这些情绪提炼成一个适合 SO 答案的具体问题？

Breeze 不会导致您将业务逻辑暴露给 JavaScript 客户端。您可以（并且应该）在存储库和/或控制器方法中安全地锁定此类逻辑。

但我很难理解客户端查询本身是如何需要保护的业务逻辑。查询名称以“A”开头的客户的危险在哪里？

您可能会担心查询净资产 > 100,000 美元的客户。但问题不在查询中。错误在于以任何方式将此类客户信息暴露给未经授权的用户，无论是通过附加到查询的 Breeze where子句还是调用名为GetCustomers()的服务。

阻止未经授权访问客户的位置在服务器上，您可以在返回IQueryable的 Breeze 控制器操作方法中轻松地做到这一点，就像在GetCustomer()方法中一样。无论哪种情况，您都有责任在您的控制器和您公开的方法中施加必要的安全约束。

你写控制器。您编写存储库。您有权访问用户的权限。您可以完全控制自己，并且拥有不折不扣的暴露能力，可以随心所欲地暴露。

FWIW，您的 BreezeEntityManager可以调用不返回的服务方法IQueryable<Customer>。它可以调用 Web Api 控制器方法，例如IEnumerable<Customer> GetCustomers()或Product GetProductForId(int id)。在我看来，您将失去 Breeze 查询工具的灵活性，而不会获得任何安全性。但那只是我的个人意见。Breeze 将支持您的选择，无论它是什么。

我很乐意尝试回答更具体的“如何”问题。

于 2012-12-03T03:46:39.803 回答
2

想补充一点，如果您从服务器返回 401 代码，您可以使用 webapi 中的属性限制未授权的用户进行查询，只需弹出登录屏幕并在用户登录后重做所需的工作

因此用户可能会尝试获取有关订单的数据，但除非获得授权，否则他不会得到它

于 2014-01-02T15:51:00.340 回答
1

你可以使用微风.js 做很多事情首先在这里检查我关于安全性的回答

如何使用 Breeze JS 处理授权？

此外，尽管可以像在客户端上使用普通 ORM 一样使用微风.js（这有时非常有用），但您应该将业务逻辑保留在 Web api 控制器中，并使用 OData 查询仅公开必要的内容。如果您需要任何数据操作逻辑，那么您应该使用特定方法在服务器上执行此操作。

客户端上应该只存在 UI 逻辑，如果您直接从客户端开始执行多个查询，还要考虑到有几个性能影响。要么扩展实体图以加载更多结果，要么使用返回对象的更专业的方法。Breeze 将自省结果并愉快地消费实体而不会产生影响。

于 2016-06-02T11:35:02.917 回答