breeze.js如何处理安全性并避免暴露业务逻辑。

Question

breeze.js如何处理安全性并避免暴露业务逻辑。

34

我们正在考虑使用Breeze JS来构建企业应用程序。

Breeze的优点在于我们可以直接从客户端浏览器执行查询。这允许根据用户输入构建动态查询，而不加载不必要的数据。我发现使用Breeze可以创建减少数据传输量/数据转移量1/10甚至更多的业务逻辑，尤其是在使用惰性加载策略时，例如使用像这些查询。

太棒了，Breeze！！！

但是，业务逻辑安全怎么办呢？例如，我们可以有一个仓库，可以隐藏和模糊我们的业务逻辑；然后使用MVC Web API控制器只调用那些存储库C#类。因此，Breeze JavaScript与WebAPI控制器交互，WebAPI控制器与C#存储库交互。控制器始终保持非常简单和易读，但是存储库可能会有大量面向公司使用应用程序的业务逻辑。因此，如果黑客使用例如Google Chrome开发人员控制台检查JavaScript代码，则他/她将看到的只是类似于GetCustomers()，GetProductsForThisId(54)之类的东西。那里没有太多信息可以被看到（或被盗）。因为90%的业务逻辑将位于服务器上的C#存储库中。

Breeze.js如何处理这个问题？

如果我们开始将查询和业务逻辑“从控制器的C#移动到Breeze JavaScript”，则需要考虑我们的系统是基于成员身份的。我认为，我们在JavaScript中向客户端公开的查询越多，我们的软件就越容易受到攻击，我们就越告诉黑客如何攻击我们的网站并可能窃取信息。

- Oscar Agreda

3个回答

2

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

因此，用户可能会尝试获取有关订单的数据，但除非他被授权这样做，否则他将无法获得该数据。

- user2968607

1

你可以使用breeze.js做很多事情。首先，检查这里关于安全性的答案如何使用Breeze JS处理授权？。

另外，虽然breeze.js可以像普通ORM一样在客户端使用（有时非常有用），但是应该将业务逻辑放在Web API控制器中，并仅使用OData查询公开必要的内容。如果需要任何数据操作逻辑，则应在服务器上使用特定的方法进行操作。

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

- Chriss

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ward · Accepted Answer

安全性是一个重要的问题。在客户端公开数据和逻辑时要仔细考虑。如何将这些情绪转化为适合于SO答案的具体问题？

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

但我很难理解客户端查询本身是需要保护的业务逻辑类型。查询名字以'A'开头的客户存在什么危险？

您确实应该担心净资产大于100,000美元的客户的查询。但问题不在于查询本身，而在于通过任何方式将此类客户信息暴露给未经授权的用户（无论是通过追加到查询的Breeze where子句还是调用名为GetCustomers()的服务）。

阻止未经授权的访问客户的位置是在服务器上，在Breeze控制器操作方法中返回IQueryable与GetCustomer()方法一样容易。无论哪种情况，你都有责任对你公开的控制器及其内部方法施加必要的安全约束。

你编写控制器，你编写存储库，你可以访问用户的权限。你拥有完全的控制权，能够毫不妥协地公开任意多或任意少的内容。

顺带一提，您的Breeze EntityManager可以调用不返回IQueryable<Customer>的服务方法。它可以调用Web Api控制器方法，例如IEnumerable<Customer> GetCustomers()或Product GetProductForId(int id)。在我看来，这样做会失去Breeze查询工具的灵活性，而没有获得任何安全性。但那只是我的看法。无论您的选择是什么，Breeze都会支持。

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